When inherit is specified in the data registry it is stored as a
string and we cannot perform a strict comparison with it.
We should still compare strict comparison checks against null, or false,
but not for the NOTSET (0) or INHERIT values (-1).
This includes the following:
1) Replace $ADMIN->id by get_admin()->id. The former doesn't exist.
2) Only change the notify parameter when it has not been specified
at creation time (null). If specified, observe it.
3) Set the current user in tests to admin, able to create those
requests.
It now checks the system context has been defined, since that is
required for data privacy to be set up correctly, and the check
to be valid. This also fixes an error being thrown when checking
pending delete requests in cron.
When checking the expiry and protected state of a context, we need to do
so knowing what kind of use that context has.
If it is used in the user context, then only the user context matters.
If it is used within a course, then that child context must be checked
in relation to the course.
Inheritance should behave such that all contexts inherit from their
parent context.
Prior to this fix, if the value was not set on a context, then it was
getting a default of 'Inherit', but instead of inheritting from the
parent context, it was inheritting from its parent context _level_ which
is just wrong.
This change rewrites the way in which expiry is calculated and addresses
a number of closely related issues:
Users can customise, and add blocks with data to, their dashboard. When
a user had done so, the user could be flagged for deletion, but the
blocks in their Dashboard were subject to the default block retention
policy. In addition there is no way to override the retention policy for
user blocks.
This change modifies the structure of the expiry mechanism:
- to consider any subcontext of the user context to be a part of the user
context during calculation. User child contexts are not the property
of the system, and should not be treated separately.
- the way in which the context expiry mechanism worked was to select
use a multiple different managers based solely on the context level.
Because of the use of user blocks, this proved to be unreliable as
blocks has been attributed purely to courses.
This has been changed to a single manager which is aware of hierarchy
and deletions as a whole.
- to prepare for upcoming work relating to more detailed expiry
mechanisms, a new expiry_info class is introduced and used to
merge the expiry of child contexts into a working in-memory view.
This changeset includes extensive unit tests.
