Difference between revisions of "MediaWiki:Development of SAR service"

From Wikibase Personal data
Jump to navigation Jump to search
Line 14: Line 14:
  
 
= To do =
 
= 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]]
 
* Read and constantly document [[architecture of SAR service]]
* Make sure the SAR popup only shows up for "instance of" {{Q|96}}
+
* **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)
* Look at [https://www.mediawiki.org/wiki/OOUI OOUI]
+
 
* Create a [[SAR test page]], with a OOUI button tied to the mailto, generated through a [[Template:ButtonMailtoAccess]].  
+
Specific instructions:
* Modify the SAR popup so that this button appears instead.
+
* Modify the [[MediaWiki:Access.js]] code to follow the convention above.
* (needs clarification:) Add an OOUI entry field for first name and last name, dynamically affecting what is launched when clicking the button.  
+
* Make sure the SAR popup only shows up selectively, for those items that are "instance of" "data controller" (here: [http://wiki.personaldata.io/wiki/Property:P3 P3]--{{Q|96}})
* (needs clarification:) Separate stream of work: at the top of {{Q|119}}, add an entry field to store the phone number locally (using LocalStorage?)
+
* Have a look at [https://www.mediawiki.org/wiki/OOUI 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 {{Q|119}} (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)
  
 
= Done =
 
= Done =

Revision as of 00:17, 20 April 2019

General information

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" ** (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)

Done