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

From Wikibase Personal data
Jump to navigation Jump to search
m (Mailto url limits (mainly affected chrome on Windows), see How to send emails)
 
(14 intermediate revisions by 3 users not shown)
Line 13: Line 13:
  
 
= Blockers =  
 
= Blockers =  
*  
+
* Mailto url limits (mainly affected chrome on Windows), see [[How to send emails]]
 +
 
 
= Removed blockers =  
 
= Removed blockers =  
 
* (solved) [https://www.mediawiki.org/wiki/Manual:$wgAllowUserJs user JS] not currently activated on wiki.personaldata.io (but this system can be tested on Wikidata)
 
* (solved) [https://www.mediawiki.org/wiki/Manual:$wgAllowUserJs user JS] not currently activated on wiki.personaldata.io (but this system can be tested on Wikidata)
Line 21: Line 22:
  
 
Specific instructions:
 
Specific instructions:
* 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: [http://wiki.personaldata.io/wiki/Property:P3 P3]--{{Q|96}})
 
* 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]].  
 
* 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.
 
* 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:) 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 [https://www.mediawiki.org/wiki/ResourceLoader/Core_modules#mediawiki.storage LocalStorage])
 
* (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 [https://www.mediawiki.org/wiki/ResourceLoader/Core_modules#mediawiki.storage LocalStorage])
 +
* Implement an [[MediaWiki:InterfaceButton.js]] script, displaying a button based on data contained in an item (for instance: {{Q|488}}), 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 =
 
= 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: [http://wiki.personaldata.io/wiki/Property:P3 P3]--{{Q|96}})
 +
* Have a look at [https://www.mediawiki.org/wiki/OOUI OOUI]
 +
 +
= To be tested =
 +
* On any page on "instance of" "interface button" ( e.g. [http://wiki.personaldata.io/wiki/Item:Q488 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:
 +
** [[ User:Abel/experimental.js ]] Main thread creating instances of:
 +
** [[ User:Abel/WbProcessor.js ]] Wikibase Entity Checker and Retriever
 +
** [[ User:Abel/PersonalData.js ]] Indexed Database Queueryer Facility
 +
** [[ User:Abel/OOInterface.js ]] Interfacing UI elements with IDXB functions

Latest revision as of 14:06, 3 January 2020

General information

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

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

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 Deliveroo (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: