We have some plugins that do not store personal data in side themselves, but do cause it to be stored in Moodle sub-systems, for example by creating log events.

When making a provider for one of these we cannot use the null_provider because we should be declaring that we add data into the sub-system, however all the methods that are used to find contexts where the data is stored and to delete it need to be implemented in a way that does nothing.

It seems like it would be useful for Moodle to have an abstract class that had the empty implementations of:

• get_contexts_for_userid
• export_user_data
• delete_data_for_all_users_in_context
• delete_data_for_user

but still requires the user to implement:

• get_metadata

I think this would have additional benefits in that the documentation could be updated to include references to it, which would make it much clearer that a null_provider was not appropriate in this case.

It would also mean that people would not try and write an implementation that tried to get data from those sub systems, since they will handle that themselves.