GDPR for plugin developers - Revision history

Tsala: content moved to Privacy API and redirect added

2018-03-28T05:21:07Z

content moved to Privacy API and redirect added

Dmonllao: /* Delete personal information for a specific user and context(s) */

2018-03-26T10:37:37Z

Delete personal information for a specific user and context(s)

← Older revision		Revision as of 10:37, 26 March 2018
Line 716:		Line 716:

	<code php>		<code php>
	public static function ~~delete_userdata_for_contexts~~(approved_contextlist $contextlist) {		public static function delete_data_for_user(approved_contextlist $contextlist) {
	global $DB;		global $DB;

Dmonllao: /* Delete for a context */

2018-03-26T09:41:11Z

Delete for a context

← Older revision		Revision as of 09:41, 26 March 2018
Line 698:		Line 698:

	<code php>		<code php>
	public static function ~~delete_for_context~~(deletion_criteria $criteria) {		public static function delete_data_for_all_users_in_context(deletion_criteria $criteria) {
	global $DB;		global $DB;
	$context = $criteria->get_context();		$context = $criteria->get_context();

Tsala: Subject Access Request FAQ, removing template, category

2018-03-26T06:56:28Z

Subject Access Request FAQ, removing template, category

← Older revision		Revision as of 06:56, 26 March 2018
Line 1:		Line 1:
	~~{{GDPR}}~~
	The General Data Protection Regulation (GDPR) is an EU directive that looks at providing users with more control over their data and how it is processed. This regulation will come into effect on 25th of May 2018 and covers any citizen or permanent resident of the European Union. The directive will be respected by a number of other countries outside of the European Union.		The General Data Protection Regulation (GDPR) is an EU directive that looks at providing users with more control over their data and how it is processed. This regulation will come into effect on 25th of May 2018 and covers any citizen or permanent resident of the European Union. The directive will be respected by a number of other countries outside of the European Union.

Line 733:		Line 732:
	==See also==		==See also==

			* [[Subject Access Request FAQ]]
	* [[Privacy API]]		* [[Privacy API]]
	* [[:en:GDPR\|GDPR]] in the user documentation		* [[:en:GDPR\|GDPR]] in the user documentation

			[[Category:GDPR]]

Tsala: content moved from https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?usp=sharing

2018-03-26T06:11:43Z

content moved from https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?usp=sharing

Show changes

Tsala: content moved from https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?usp=sharing - wip

2018-03-26T05:45:41Z

content moved from https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?usp=sharing - wip

Show changes

Tsala: content moved from https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?usp=sharing - wip

2018-03-26T05:35:15Z

content moved from https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?usp=sharing - wip

Show changes

Tsala: content moved from https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?usp=sharing - wip

2018-03-26T05:27:24Z

content moved from https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?usp=sharing - wip

← Older revision		Revision as of 05:27, 26 March 2018
Line 263:		Line 263:
	</code>		</code>

			===Indicating that you export data to an external location===

			Many plugins will interact with external systems - for example cloud-based services. Often this external location is configurable within the plugin either at the site or the instance level.

			As a plugin developer you will need to describe each ''type'' of target destination, alongside a list of each exported field which includes user data.
			The ''actual'' destination does not need to be described as this can change based on configuration.

			You can indicate this by calling the ''link_external_location()'' method on the collection.

			====Example====

			''mod/lti/classes/privacy/provider.php''

			<code php>
			public static function get_metadata(collection $collection) : collection {

			$collection->link_external_location('lti_client', [
			'userid' => 'privacy:metadata:lti_client:userid',
			'fullname' => 'privacy:metadata:lti_client:fullname',
			], 'privacy:metadata:lti_client');

			return $collection;
			}
			</code>

			''admin/tool/usertours/lang/en/tool_usertours.php''

			<code php>
			<?php

			$string['privacy:metadata:lti_client'] = 'In order to integrate with a remote LTI service, user data needs to be exchanged with that service.';
			$string['privacy:metadata:lti_client:userid'] = 'The userid is sent from Moodle to allow you to access your data on the remote system.';
			$string['privacy:metadata:lti_client:fullname'] = 'Your full name is sent to the remote system to allow a better user experience.';
			</code>

			==Providing a way to export user data==

			In order to export the user data that you store, you must implement the relevant request provider.

			We have named these request providers because they are called in response to a specific request from a user to access their information.

			There are several different types of request provider, and you may need to implement several of these, depending on the type and nature of your plugin.

			Broadly speaking plugins will fit into one of the following categories:

			* Plugins which are a subplugin of another plugin. Examples include ''assignsubmission'', ''atto'', and ''datafield'';
			* Plugins which are typically called by a Moodle subsystem. Examples include ''qtype'', and ''profilefield'';
			* All other plugins which store data.

			Most plugins will fit into this final category, whilst other plugins may fall into several categories.
			Plugins which ''define'' a subplugin will also be responsible for collecting this data from their subplugins.

			A final category exists - plugins which store user preferences. In some cases this may be the ''only'' provider implemented.

			===Standard plugins which store data===

			A majority of Moodle plugins will fit into this category and will be required to implement the ''\core_privacy\local\request\plugin\provider'' interface. This interface requires that you define two functions:

			* ''get_contexts_for_userid'' - to explain where data is held within Moodle for your plugin; and
			* ''export_user_data'' - to export a user’s personal data from your plugin.

			These APIs make use of the Moodle ''context'' system to hierarchically store this data.

			===Retrieving the list of contexts===

			Contexts are retrieved using the ''get_contexts_for_userid'' function which takes the ID of the user being fetched, and returns a list of contexts in which the user has any data.

			''mod/forum/classes/privacy/provider.php''

			<code php>
			/**
			* Get the list of contexts that contain user information for the specified user.
			*
			* @param int $userid The user to search.
			* @return contextlist $contextlist The list of contexts used in this plugin.
			*/
			public static function get_contexts_for_userid(int $userid) : contextlist {}
			</code>

			The function returns a ''\core_privacy\local\request\contextlist'' which is used to keep a set of contexts together in a fixed fashion.

			Because a Subject Access Request covers ''every'' piece of data that is held for a user within Moodle, efficiency and performance is highly important. As a result, contexts are added to the ''contextlist'' by defining one or more SQL queries which return just the contextid. Multiple SQL queries can be added as required.

			Many plugins will interact with specific subsystems and store data within them.
			These subsystems will also provide a way in which to link the data that you have stored with your own database tables.
			At present these are still a work in progress and only the ''core_ratings'' subsystem includes this.

Tsala: content moved from https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?usp=sharing - wip

2018-03-26T05:19:09Z

content moved from https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?usp=sharing - wip

← Older revision		Revision as of 05:19, 26 March 2018
Line 182:		Line 182:
	$string['privacy:metadata:core_files'] = 'The forum stores files which have been uploaded by the user to form part of a forum post.';		$string['privacy:metadata:core_files'] = 'The forum stores files which have been uploaded by the user to form part of a forum post.';
	</code>		</code>

			===Describing data stored in database tables===

			Most Moodle plugins will store some form of user data in their own database tables.

			As a plugin developer you will need to describe each database table, and each field which includes user data.

			====Example====

			''mod/forum/classes/privacy/provider.php''

			<code php>
			public static function get_metadata(collection $collection) : collection {

			$collection->add_database_table(
			'forum_discussion_subs',
			[
			'userid' => 'privacy:metadata:forum_discussion_subs:userid',
			'discussionid' => 'privacy:metadata:forum_discussion_subs:discussionid',
			'preference' => 'privacy:metadata:forum_discussion_subs:preference',

			],
			'privacy:metadata:forum_discussion_subs'
			);

			return $collection;
			}
			</code>

			''mod/forum/lang/en/forum.php''

			<code php>
			<?php

			$string['privacy:metadata:forum_discussion_subs'] = 'Information about the subscriptions to individual forum discussions. This includes when a user has chosen to subscribe to a discussion, or to unsubscribe from one where they would otherwise be subscribed.';
			$string['privacy:metadata:forum_discussion_subs:userid'] = 'The ID of the user with this subscription preference.';
			$string['privacy:metadata:forum_discussion_subs:discussionid'] = 'The ID of the discussion that was subscribed to.';
			$string['privacy:metadata:forum_discussion_subs:preference'] = 'The start time of the subscription.';
			</code>

			===Indicating that you store site-wide user preferences===

			Many plugins will include one or more user preferences. Unfortunately this is one of Moodle’s older components and many of the values stored are not pure user preferences. Each plugin should be aware of how it handles its own preferences and is best placed to determine whether they are site-wide preferences, or per-instance preferences.

			Whilst most of these will have a fixed name (e.g. ''filepicker_recentrepository''), some will include a variable of some kind (e.g. ''tool_usertours_tour_completion_time_2''). Only the general name needs to be indicated rather than one copy for each preference.

			Also, these should only be ''site-wide'' user preferences which do not belong to a specific Moodle context.

			In the above examples:

			* Preference ''filepicker_recentrepository'' belongs to the file subsystem, and is a site-wide preference affecting the user anywhere that they view the filepicker.
			* Preference ''tool_usertours_tour_completion_time_2'' belongs to user tours. User tours are a site-wide feature which can affect many parts of Moodle and cross multiple contexts.

			In some cases a value may be stored in the preferences table but is known to belong to a specific context within Moodle. In these cases they should be stored as metadata against that context rather than as a site-wide user preference.

			You can indicate this by calling the ''add_user_preference()'' method on the ''collection''.

			Any plugin providing user preferences must also implement the ''\core_privacy\local\request\preference_provider''.

			====Example====

			''admin/tool/usertours/classes/privacy/provider.php''

			<code php>
			public static function get_metadata(collection $collection) : collection {

			$collection->add_user_preference('tool_usertours_tour_completion_time,
			'privacy:metadata:preference:tool_usertours_tour_completion_time');

			return $collection;
			}
			</code>

			''admin/tool/usertours/lang/en/tool_usertours.php''

			<code php>
			<?php

			$string['privacy:metadata:tool_usertours_tour_completion_time'] = 'The time that a specific user tour was last completed by a user.';
			</code>

Tsala: content moved from https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?usp=sharing - wip

2018-03-26T04:55:14Z

content moved from https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?usp=sharing - wip

Show changes