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.