Privacy API: Difference between revisions
No edit summary |
No edit summary |
||
| Line 15: | Line 15: | ||
==Plugins that do not hold personal data== | ==Plugins that do not hold personal data== | ||
If a plugin does not hold any personal data it should implement a provider class that implements the | If a plugin does not hold any personal data it should implement a provider class that implements the ''core_privacy\local\metadata\null_provider''. | ||
===get_reason(): string=== | ===get_reason(): string=== | ||
This function should return a string that explains why the plugin is asserting that it holds no personal data. | This function should return a string that explains why the plugin is asserting that it holds no personal data. | ||
==Using Privacy API== | |||
Every plugin should define a privacy provider class. | Every plugin should define a privacy provider class. At minimum this will describe the data held in the plugin, and it may implement means for servicing Subject Access Requests and Deletion of User Data | ||
This ''must'': | This ''must'': | ||
| Line 26: | Line 26: | ||
* be located in the '''classes\privacy\''' directory for the plugin | * be located in the '''classes\privacy\''' directory for the plugin | ||
* be in the "<pluginname>\privacy" namespace | * be in the "<pluginname>\privacy" namespace | ||
* implement | * implement '''core_privacy\local\metadata\provider'' *or* ''core_privacy\local\metadata\null_provider'' | ||
<code php> | <code php> | ||
| Line 38: | Line 38: | ||
} | } | ||
</code> | </code> | ||
===Exporting User Data=== | |||
To support the export of user data for Subject Access Requests, the plugin '''provider''' class should implement ''''\core_privacy\local\request\plugin\provider'''' | |||
===Deleting User Data=== | |||
==Helpers== | ==Helpers== | ||
Revision as of 16:53, 21 March 2018
Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.
Overview
The Privacy API has been implemented to help report the use of data within Moodle Plugins as part of General Data Protection Regulations.
It shall be expected that *all* plugins will require to report their use of and storing of personal data.
All plugins will be expected to implement a privacy provider class. This class will provide details on:
- personal data being held by the plugin in:
- database tables
- subsystems
- user preferences
- external locations
Plugins that do not hold personal data
If a plugin does not hold any personal data it should implement a provider class that implements the core_privacy\local\metadata\null_provider.
get_reason(): string
This function should return a string that explains why the plugin is asserting that it holds no personal data.
Using Privacy API
Every plugin should define a privacy provider class. At minimum this will describe the data held in the plugin, and it may implement means for servicing Subject Access Requests and Deletion of User Data
This must:
- be named provider,
- be located in the classes\privacy\ directory for the plugin
- be in the "<pluginname>\privacy" namespace
- implement 'core_privacy\local\metadata\provider *or* core_privacy\local\metadata\null_provider
namespace mod_peerassessment\privacy;
class provider implements
\core_privacy\local\metadata\provider,
\core_privacy\local\request\plugin\provider
{
...
}
Exporting User Data
To support the export of user data for Subject Access Requests, the plugin provider class should implement '\core_privacy\local\request\plugin\provider'
