Difference between revisions of "MediaWiki:Development of SAR service"
Jump to navigation
Jump to search
(→To do) |
(→To do) |
||
| Line 18: | Line 18: | ||
Ongoing instructions: | Ongoing instructions: | ||
* Read and constantly document [[architecture of SAR service]] | * Read and constantly document [[architecture of SAR service]] | ||
| − | * '''Whenever using property or item numbers in code, define a new variable early in the code with that <name>_id locally, for example "instance_property_id = 3"''' (this makes the code produced less dependent on each instance) | + | * '''Whenever using property or item numbers in code, define a new variable early in the code with that <name>_id locally, for example "instance_property_id = 3" (see [http://wiki.personaldata.io/wiki/Property:P3 P3])''' (this makes the code produced less dependent on each instance) |
Specific instructions: | Specific instructions: | ||
Revision as of 00:18, 20 April 2019
General information
- Contractor: User:Abel
- Reference: architecture of SAR service
- Logged hours (request access)
General instructions
- Always document extensively (comments in code, for instance)
- Make sure you watch pages that are relevant (star)
Blockers
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.
Ongoing instructions:
- Read and constantly document architecture of SAR service
- Whenever using property or item numbers in code, define a new variable early in the code with that <name>_id locally, for example "instance_property_id = 3" (see P3) (this makes the code produced less dependent on each instance)
Specific instructions:
- Modify the MediaWiki:Access.js code to follow the convention 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
- 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? -- preliminary research on this needed)