Development of SAR service
- Read and constantly document architecture of SAR service
- Always document extensively (comments in code, for instance)
- Make sure you watch pages that are relevant (star)
- Whenever using property or item numbers in code, define a new variable early in the code with that <name>_id locally, for example "controller_item_id = 96" (see GDPR data controller (Q96)) (this makes the code produced less dependent on which Wikibase instance we are using, as the numbers will change)
- Mailto url limits (mainly affected chrome on Windows), see How to send emails
- (solved) user JS not currently activated on wiki.personaldata.io (but this system can be tested on Wikidata)
The goal is to streamline the SAR process. There are many ways this could be made easier. If one looks at the generated requests, they miss some of the information, particularly identifiers for the individual requesting the data. We want to enable filling some data (like name or telephone number) only once, and then be able to make multiple requests. One way to do this is by using LocalStorage, but which data attributes to collect and where should be stored in the database itself.
- Create a SAR tool testing page, with a OOUI button tied to the mailto, generated through a new Template:ButtonMailtoAccess.
- Modify the SAR user script MediaWiki:Access.js so that this button appears instead.
- (needs clarification:) Above this button, add an OOUI entry field for first name and last name, dynamically affecting what is launched when clicking the button. If nothing is entered, have some code making explicit what should be entered.
- (needs clarification:) Starting a separate stream of work, at the top of telephone number (Q119) (or rather all "instance of" "personal attribute"), add an entry field to store the phone number --or that attribute-- locally (using LocalStorage)
- Implement an MediaWiki:InterfaceButton.js script, displaying a button based on data contained in an item (for instance: telephone number interface button (Q488)), and interacting with client-side storage (data stored in a key given by "concerns" field)
- Based on selector on "instance of" "interface button", implemented in MediaWiki:Common.js, make this button appear at the top of the "interface button" pages (by reusing MediaWiki:InterfaceButton.js of course).
- Modify the MediaWiki:Access.js code to follow the conventions above.
- Make sure the SAR popup only shows up selectively, for those items that are "instance of" "data controller" (here: P3--GDPR data controller (Q96))
- Have a look at OOUI
To be tested
- On any page on "instance of" "interface button" ( e.g. Telephone number interface button ) , test whether the save function to localstorage works ( whether input data persists after page reload / browser restart ). Cross platform/browser compatibility should include Firefox, Chrome under Android, Firefox, Chrome under Windows 10, Safari, Firefox, Chrome under MacOS and as well as under iOS.
Needs to be tested logged in/not logged in, http/https, desktop/mobile Tested on:
- Safari/MacOS: works
- Chrome/MacOS: does not work (not saved on reload)
- Firefox/MacOS: does not work (not saved on reload)
- Safari/iOS: works on desktop mode
- Firefox/iOS: works on desktop mode
- Cross browser transfer of data should be available on page Item:Q102 ( or any instance of data controller as of current setup ). Current import mechanism will overwrite original data with the imported where they overlap, hopefully leave other original data intact
- want to test cross browser, but it is not working on enough browsers at the moment to test
- Script files to be revised: