From fbad9d8d06a7947ec097fad11059df353c916d26 Mon Sep 17 00:00:00 2001 From: Neill Magill Date: Fri, 23 Aug 2024 09:57:36 +0100 Subject: [PATCH] How to handle privacy providers that only store data in a sub-system It appears that this is not clear to everyone who reads the documentation at the moment that a plugin that sends data to a subsystem, for example the logs should not use the null_provider and that the sub-system will do the retrieval and deletion of the personal data. This has been the case in all versions of Moodle supported by the dev docs. --- docs/apis/subsystems/privacy/faq.md | 6 ++++++ versioned_docs/version-4.1/apis/subsystems/privacy/faq.md | 6 ++++++ versioned_docs/version-4.2/apis/subsystems/privacy/faq.md | 6 ++++++ versioned_docs/version-4.3/apis/subsystems/privacy/faq.md | 6 ++++++ versioned_docs/version-4.4/apis/subsystems/privacy/faq.md | 6 ++++++ 5 files changed, 30 insertions(+) diff --git a/docs/apis/subsystems/privacy/faq.md b/docs/apis/subsystems/privacy/faq.md index afa57c2d1d..887a5a95f9 100644 --- a/docs/apis/subsystems/privacy/faq.md +++ b/docs/apis/subsystems/privacy/faq.md @@ -61,3 +61,9 @@ Any context-specific preference should: 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. + +## My plugin does not store any personal data itself, but does send personal data into the Moodle logs or another subsystem. What should I do? + +You need to implement `\core_privacy\local\metadata\provider` so that you can describe the sub-systems used by your plugin in the `get_metadata()` method of your provider. + +The exporting and deleting of the user data in the subsystem will be handled by that subsystem and the plugins inside it, so you do not need to implement any of the request interfaces which are used to export data from the plugin. diff --git a/versioned_docs/version-4.1/apis/subsystems/privacy/faq.md b/versioned_docs/version-4.1/apis/subsystems/privacy/faq.md index afa57c2d1d..887a5a95f9 100644 --- a/versioned_docs/version-4.1/apis/subsystems/privacy/faq.md +++ b/versioned_docs/version-4.1/apis/subsystems/privacy/faq.md @@ -61,3 +61,9 @@ Any context-specific preference should: 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. + +## My plugin does not store any personal data itself, but does send personal data into the Moodle logs or another subsystem. What should I do? + +You need to implement `\core_privacy\local\metadata\provider` so that you can describe the sub-systems used by your plugin in the `get_metadata()` method of your provider. + +The exporting and deleting of the user data in the subsystem will be handled by that subsystem and the plugins inside it, so you do not need to implement any of the request interfaces which are used to export data from the plugin. diff --git a/versioned_docs/version-4.2/apis/subsystems/privacy/faq.md b/versioned_docs/version-4.2/apis/subsystems/privacy/faq.md index afa57c2d1d..887a5a95f9 100644 --- a/versioned_docs/version-4.2/apis/subsystems/privacy/faq.md +++ b/versioned_docs/version-4.2/apis/subsystems/privacy/faq.md @@ -61,3 +61,9 @@ Any context-specific preference should: 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. + +## My plugin does not store any personal data itself, but does send personal data into the Moodle logs or another subsystem. What should I do? + +You need to implement `\core_privacy\local\metadata\provider` so that you can describe the sub-systems used by your plugin in the `get_metadata()` method of your provider. + +The exporting and deleting of the user data in the subsystem will be handled by that subsystem and the plugins inside it, so you do not need to implement any of the request interfaces which are used to export data from the plugin. diff --git a/versioned_docs/version-4.3/apis/subsystems/privacy/faq.md b/versioned_docs/version-4.3/apis/subsystems/privacy/faq.md index afa57c2d1d..887a5a95f9 100644 --- a/versioned_docs/version-4.3/apis/subsystems/privacy/faq.md +++ b/versioned_docs/version-4.3/apis/subsystems/privacy/faq.md @@ -61,3 +61,9 @@ Any context-specific preference should: 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. + +## My plugin does not store any personal data itself, but does send personal data into the Moodle logs or another subsystem. What should I do? + +You need to implement `\core_privacy\local\metadata\provider` so that you can describe the sub-systems used by your plugin in the `get_metadata()` method of your provider. + +The exporting and deleting of the user data in the subsystem will be handled by that subsystem and the plugins inside it, so you do not need to implement any of the request interfaces which are used to export data from the plugin. diff --git a/versioned_docs/version-4.4/apis/subsystems/privacy/faq.md b/versioned_docs/version-4.4/apis/subsystems/privacy/faq.md index afa57c2d1d..887a5a95f9 100644 --- a/versioned_docs/version-4.4/apis/subsystems/privacy/faq.md +++ b/versioned_docs/version-4.4/apis/subsystems/privacy/faq.md @@ -61,3 +61,9 @@ Any context-specific preference should: 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. + +## My plugin does not store any personal data itself, but does send personal data into the Moodle logs or another subsystem. What should I do? + +You need to implement `\core_privacy\local\metadata\provider` so that you can describe the sub-systems used by your plugin in the `get_metadata()` method of your provider. + +The exporting and deleting of the user data in the subsystem will be handled by that subsystem and the plugins inside it, so you do not need to implement any of the request interfaces which are used to export data from the plugin.