MediaWiki:Development of SAR service

General information

• Contractor: User:Abel
• Reference: architecture of SAR service
• Logged hours (request access)

General instructions

• 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)
• Be mindful of Javascript conventions (within reason)
• 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 data controller (Q96)) (this makes the code produced less dependent on which Wikibase instance we are using, as the numbers will change)

Blockers

• Mailto url limits (mainly affected chrome on Windows), see How to send emails

Removed blockers

• (solved) user JS not currently activated on wiki.personaldata.io (but this system can be tested on Wikidata)

To do

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.

Specific instructions:

• 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).

Done

• 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--data controller (Q96))
• Have a look at OOUI