Search moodle.org's
Developer Documentation

See Release Notes

  • Bug fixes for general core bugs in 3.11.x will end 14 Nov 2022 (12 months plus 6 months extension).
  • Bug fixes for security issues in 3.11.x will end 13 Nov 2023 (18 months plus 12 months extension).
  • PHP version: minimum PHP 7.3.0 Note: minimum PHP version has increased since Moodle 3.10. PHP 7.4.x is supported too.

This file contains the core_privacy\manager class.

Copyright: 2018 Jake Dallimore <jrhdallimore@gmail.com>
License: http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later
File Size: 635 lines (29 kb)
Included or required:0 times
Referenced: 0 times
Includes or requires: 0 files

Defines 1 class


Class: manager  - X-Ref

The core_privacy\manager class, providing a facade to describe, export and delete personal data across Moodle and its components.

This class is responsible for communicating with and collating privacy data from all relevant components, where relevance is
determined through implementations of specific marker interfaces. These marker interfaces describe the responsibilities (in terms
of personal data storage) as well as the relationship between the component and the core_privacy subsystem.

The interface hierarchy is as follows:
├── local\metadata\null_provider
├── local\metadata\provider
├── local\request\data_provider
└── local\request\core_data_provider
└── local\request\core_user_data_provider
└── local\request\plugin\provider
└── local\request\subsystem\provider
└── local\request\user_preference_provider
└── local\request\shared_data_provider
└── local\request\plugin\subsystem_provider
└── local\request\plugin\subplugin_provider
└── local\request\subsystem\plugin_provider

Describing personal data:
-------------------------
All components must state whether they store personal data (and DESCRIBE it) by implementing one of the metadata providers:
- local\metadata\null_provider (indicating they don't store personal data)
- local\metadata\provider (indicating they do store personal data, and describing it)

The manager requests metadata for all Moodle components implementing the local\metadata\provider interface.

Export and deletion of personal data:
-------------------------------------
Those components storing personal data need to provide EXPORT and DELETION of this data by implementing a request provider.
Which provider implementation depends on the nature of the component; whether it's a sub-component and which components it
stores data for.

Export and deletion for sub-components (or any component storing data on behalf of another component) is managed by the parent
component. If a component contains sub-components, it must ask those sub-components to provide the relevant data. Only certain
'core provider' components are called directly from the manager and these must provide the personal data stored by both
themselves, and by all sub-components. Because of this hierarchical structure, the core_privacy\manager needs to know which
components are to be called directly by core: these are called core data providers. The providers implemented by sub-components
are called shared data providers.

The following are interfaces are not implemented directly, but are marker interfaces uses to classify components by nature:
- local\request\data_provider:
Not implemented directly. Used to classify components storing personal data of some kind. Includes both components storing
personal data for themselves and on behalf of other components.
Include: local\request\core_data_provider and local\request\shared_data_provider.
- local\request\core_data_provider:
Not implemented directly. Used to classify components storing personal data for themselves and which are to be called by the
core_privacy subsystem directly.
Includes: local\request\core_user_data_provider and local\request\user_preference_provider.
- local\request\core_user_data_provider:
Not implemented directly. Used to classify components storing personal data for themselves, which are either a plugin or
subsystem and which are to be called by the core_privacy subsystem directly.
Includes: local\request\plugin\provider and local\request\subsystem\provider.
- local\request\shared_data_provider:
Not implemented directly. Used to classify components storing personal data on behalf of other components and which are
called by the owning component directly.
Includes: local\request\plugin\subsystem_provider, local\request\plugin\subplugin_provider and local\request\subsystem\plugin_provider

The manager only requests the export or deletion of personal data for components implementing the local\request\core_data_provider
interface or one of its descendants; local\request\plugin\provider, local\request\subsystem\provider or local\request\user_preference_provider.
Implementing one of these signals to the core_privacy subsystem that the component must be queried directly from the manager.

Any component using another component to store personal data on its behalf, is responsible for making the relevant call to
that component's relevant shared_data_provider class.

For example:
The manager calls a core_data_provider component (e.g. mod_assign) which, in turn, calls relevant subplugins or subsystems
(which assign uses to store personal data) to get that data. All data for assign and its sub-components is aggregated by assign
and returned to the core_privacy subsystem.

set_observer(manager_observer $observer)   X-Ref
Set the failure handler.

param: manager_observer $observer

component_is_compliant(string $component)   X-Ref
Checks whether the given component is compliant with the core_privacy API.
To be considered compliant, a component must declare whether (and where) it stores personal data.

Components which do store personal data must:
- Have implemented the core_privacy\local\metadata\provider interface (to describe the data it stores) and;
- Have implemented the core_privacy\local\request\data_provider interface (to facilitate export of personal data)
- Have implemented the core_privacy\local\request\deleter interface

Components which do not store personal data must:
- Have implemented the core_privacy\local\metadata\null_provider interface to signal that they don't store personal data.

param: string $component frankenstyle component name, e.g. 'mod_assign'
return: bool true if the component is compliant, false otherwise.

get_null_provider_reason(string $component)   X-Ref
Retrieve the reason for implementing the null provider interface.

param: string $component Frankenstyle component name.
return: string The key to retrieve the language string for the null provider reason.

is_empty_subsystem($component)   X-Ref
Return whether this is an 'empty' subsystem - that is, a subsystem without a directory.

param: string $component Frankenstyle component name.
return: string The key to retrieve the language string for the null provider reason.

get_metadata_for_components()   X-Ref
Get the privacy metadata for all components.

return: collection[] The array of collection objects, indexed by frankenstyle component name.

get_contexts_for_userid(int $userid)   X-Ref
Gets a collection of resultset objects for all components.

param: int $userid the id of the user we're fetching contexts for.
return: contextlist_collection the collection of contextlist items for the respective components.

get_users_in_context(\context $context)   X-Ref
Gets a collection of users for all components in the specified context.

param: \context    $context The context to search
return: userlist_collection the collection of userlist items for the respective components.

export_user_data(contextlist_collection $contextlistcollection)   X-Ref
Export all user data for the specified approved_contextlist items.

Note: userid and component are stored in each respective approved_contextlist.

param: contextlist_collection $contextlistcollection the collection of contextlists for all components.
return: string the location of the exported data.

delete_data_for_user(contextlist_collection $contextlistcollection)   X-Ref
Delete all user data for approved contexts lists provided in the collection.

This call relates to the forgetting of an entire user.

Note: userid and component are stored in each respective approved_contextlist.

param: contextlist_collection $contextlistcollection the collections of approved_contextlist items on which to call deletion.

delete_data_for_users_in_context(\core_privacy\local\request\userlist_collection $collection)   X-Ref
Delete all user data for all specified users in a context.

param: \core_privacy\local\request\userlist_collection $collection

delete_data_for_all_users_in_context(\context $context)   X-Ref
Delete all use data which matches the specified deletion criteria.

param: \context $context The specific context to delete data for.

get_component_list()   X-Ref
Returns a list of frankenstyle names of core components (plugins and subsystems).

return: array the array of frankenstyle component names.

get_provider_classname($component)   X-Ref
Return the fully qualified provider classname for the component.

param: string $component the frankenstyle component name.
return: string the fully qualified provider classname.

get_provider_classname_for_component(string $component)   X-Ref
Return the fully qualified provider classname for the component.

param: string $component the frankenstyle component name.
return: string the fully qualified provider classname.

component_implements(string $component, string $interface)   X-Ref
Checks whether the component's provider class implements the specified interface.
This can either be implemented directly, or by implementing a descendant (extension) of the specified interface.

param: string $component the frankenstyle component name.
param: string $interface the name of the interface we want to check.
return: bool True if an implementation was found, false otherwise.

plugintype_class_callback(string $plugintype, string $interface, string $methodname, array $params)   X-Ref
Call the named method with the specified params on any plugintype implementing the relevant interface.

param: string  $plugintype The plugingtype to check
param: string  $interface The interface to implement
param: string  $methodname The method to call
param: array   $params The params to call

component_class_callback(string $component, string $interface, string $methodname, array $params)   X-Ref
Call the named method with the specified params on the supplied component if it implements the relevant interface on its provider.

param: string  $component The component to call
param: string  $interface The interface to implement
param: string  $methodname The method to call
param: array   $params The params to call
return: mixed

get_log_tracer()   X-Ref
Get the tracer used for logging.

The text tracer is used except for unit tests.

return: \progress_trace

handled_component_class_callback(string $component, string $interface, string $methodname, array $params)   X-Ref
Call the named method with the specified params on the supplied component if it implements the relevant interface
on its provider.

param: string  $component The component to call
param: string  $interface The interface to implement
param: string  $methodname The method to call
param: array   $params The params to call
return: mixed

component_class_callback_failed(\Throwable $e, string $component, string $interface,string $methodname, array $params)   X-Ref
Notifies the observer of any failure.

param: \Throwable $e
param: string $component
param: string $interface
param: string $methodname
param: array $params