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.

Author: NeillM

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.

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.

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.

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.

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.