Subject Access Request FAQ - Revision history

Devdocsbot: Protected "Subject Access Request FAQ": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))

2022-06-23T23:58:15Z

Protected "Subject Access Request FAQ": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))

← Older revision	Revision as of 23:58, 23 June 2022
(No difference)

Devdocsbot: Update migration status and path

2022-06-23T23:56:38Z

Update migration status and path

← Older revision		Revision as of 23:56, 23 June 2022
Line 1:		Line 1:
			{{Template:Migrated\|newDocId=/docs/apis/subsystems/privacy/faq}}
	==My plugin sends notifications or messages to the user - do I need to return this user data?==		==My plugin sends notifications or messages to the user - do I need to return this user data?==

Sarjona: Add core_enrol question and answer

2018-04-27T11:38:35Z

Add core_enrol question and answer

← Older revision		Revision as of 11:38, 27 April 2018
Line 48:		Line 48:
	* Be exported from within the ''export_user_data'' function; and		* Be exported from within the ''export_user_data'' function; and
	* be deleted in both the ''delete_data_for_all_users_in_context'' and ''delete_data_for_user'' functions for those contexts specified.		* be deleted in both the ''delete_data_for_all_users_in_context'' and ''delete_data_for_user'' functions for those contexts specified.

			==Why almost all the enrol_xxx plugins implements the null provider instead linking to the core_enrol subsystem?==

			The core_enrol subsystem just uses the enrol_xxx components to display the UI to manage the enrolments. The process as a whole is managed by core_enrol, and enrol_xxx are just a way of bringing two concepts together. The data is stored consistently within core_enrol and the enrol_xxx components are essentially a conduit to store the data en the core_enrol subsystem.

			You can ultimately work out which enrol plugin a user is enrolled with, but the UI is largely provided by core_enrol, and the calling code is actually core_enrol. Besides, you don't create an enrolment plugin instance in isolation: core_enrol is central to the experience.


	==See also==		==See also==

Sarjona: /* My plugin stores user preferences for a specific context. What should I do? */

2018-04-27T11:27:05Z

My plugin stores user preferences for a specific context. What should I do?

← Older revision		Revision as of 11:27, 27 April 2018
Line 43:		Line 43:
	Any system-wide preference should be exported from within the ''export_user_preference'' function.		Any system-wide preference should be exported from within the ''export_user_preference'' function.

	Any context-specific preference should be:		Any context-specific preference should:

	* Have the context it resides in identified in the ''get_contexts_for_userid'' function		* Have the context it resides in identified in the ''get_contexts_for_userid'' function

Mudrd8mz: /* See also */

2018-03-29T16:02:38Z

Tsala: see also, Category:GDPR

2018-03-26T06:57:14Z

Tsala: Content moved from https://docs.google.com/document/d/10IwrcMTUXNYhnOqb2E9gJgkgrAUIKUEXyF2PscmjLkA/edit#

2018-03-23T14:05:06Z

Content moved from https://docs.google.com/document/d/10IwrcMTUXNYhnOqb2E9gJgkgrAUIKUEXyF2PscmjLkA/edit#

New page

{{GDPR}}
==My plugin sends notifications or messages to the user - do I need to return this user data?==

No - messages and notifications do not need to be declared or exported.

Messages within the Moodle UI are only shown within the messages component, and are not viewed from within the sending component. Messages are designed to be read in isolation and to make sense outside of the component which generated them.

It would be unexpected for a plugin to fetch the messages that it has previously sent out, and when a plugin is uninstalled and its data removed, the messages and notifications it has previously sent are left in place.

Therefore the ''core_messages'' subsystem is considered to own the data once it has been sent.

Plugins which send messages and notifications do not need to declare the subsystem link, or to export these messages.

==My plugin is a repository - does that mean it is responsible for the files fetched?==

No.

The repository does not store data itself. It’s part of the channel between the requesting component (e.g. the Assignment module) and the file that is stored.

The repository may integrate with an external system, and this information needs to be declared, but the repository itself does not store the data, and is not responsible for how it is stored in the file system.

Unless the repository keeps a track of user credentials, user preferences, or some other kind of user information, you likely do not store any user data.

==My plugin stores data in the session - do I need to declare it?==

No.

Data stored in the user session is not stored permanently, and cannot be reported (the export process runs in a different thread).

Although the data is stored, and can be set, updated, and retrieved, it is time limited and the export process does not have access to return it.

==My plugin only sends data to an external location, but doesn’t store it locally in Moodle - what should I do?==

You need to describe the data exported in the metadata provider and implement the request plugin provider.

Your plugin must still report that it processes data via the metadata provider. More specifically, it should do this by linking the external location using link_external_location().

In most cases, plugins of this nature won’t be able to retrieve the data sent externally, so should implement a request/plugin/provider with empty methods. They must do this for compliance reasons; they must implement a request provider, but cannot not return any data, so should just return nothing. If your plugin can return data from external sources, then you may choose to do so.

==My plugin stores user preferences for a specific context. What should I do?==

You need to implement the ''user_preference_provider'' provider, and the ''plugin/provider'' provider.

Any system-wide preference should be exported from within the ''export_user_preference'' function.

Any context-specific preference should be:

* Have the context it resides in identified in the ''get_contexts_for_userid'' function
* Be exported from within the ''export_user_data'' function; and
* be deleted in both the ''delete_data_for_all_users_in_context'' and ''delete_data_for_user'' functions for those contexts specified.

← Older revision		Revision as of 16:02, 29 March 2018
Line 51:		Line 51:
	==See also==		==See also==

	* [[~~GDPR for plugin developers~~]]		* [[Privacy API]]

	[[Category:GDPR]]		[[Category:GDPR]]

@@ Line 1: / Line 1: @@
 ==My plugin sends notifications or messages to the user - do I need to return this user data?==
@@ Line 49: / Line 48: @@
 * Be exported from within the ''export_user_data'' function; and
 * be deleted in both the ''delete_data_for_all_users_in_context'' and ''delete_data_for_user'' functions for those contexts specified.