There was an accessibility issue with the previous icons that we used
the same "checked" shape just in different colours for different
meanings. New icons added for the new statuses:
* partial - a warning icon for the overall status column that the user
has only some policies accepted, not all.
* pending - that we did not hear yet from the user - whcih is different
from a declined policy.
For optional policies, we provide a radio selector to let the user
choose the acceptance status on the consent page. For policies displayed
on their own page, we display a link to decline the policy.
The way how we pass the list of policy version ids to index.php has
changed so that we can now not only pass the list of ids, but also the
actual acceptance status (accepted / declined).
This method allows to quickly check if the given policy version is
marked as optional or compulsory. This will be needed in other places
such as permissions check.
The method now returns three-state logic. A bool value true/false is
returned if the user has accepted/rejected the policy, respectively. A
null value is returned if the user did not express their agreement in
either way yet.
This allows to distinguish between "rejected the policy" and "did not
say anything about it yet" cases.
The patch adds a new column to the database table to hold the
information if giving agreement to the policy is compulsory or optional.
The flag can be defined via the policy editing form and is displayed at
the policies management screen.
The last modified time merged with the version column at the policies
management screen to save a bit of horizontal space - needed as we
display more information now at the first column.
During a CLI upgrade when there are new settings in core or in
a plugin, the settings are set to the defined defaults
automatically. There is no ouput shown on the CLI about which
new settings have been introduced or what default values the
setting are set to.
This patch outputs the name of the new setting and what the
default value being is set is to the CLI during an upgrade.
Objects and arrays are expanded into a human readable format.
This plugin also makes the function that sets the defaults to
be more robust so it isno longer required to be called multiple
times to ensure all settings are set.
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.
* Use standard Bootstrap4 table classes for the categories and purposes
tables.
* Set w-25 for the name and description columns of the purposes table.
* Set w-50 for the description column of the categories table.
* Set a minimum width for the actions column of these tables.
Thanks to MDL-49398, we can separate the combined user session and role
definition cache clearing function into two separate functions. At the
same time, we want to identify and remove mark_dirty() calls that were
added for role definition changes but were incorrectly left behind.
Change highlights:
- Remove unnecessary mark_dirty() calls performed after
assign_capability(), unassign_capability(), delete_role(),
deleted contexts, brand new contexts
- Move role definition cache clear from the user-centric
accesslib_clear_all_caches() to the newly created,
role-dedicated accesslib_reset_role_cache()
The tests make sure that both existing users as well as signing up users
can accept policies with "on their own page" style of agreement prior
reaching the consent page.
The idea of the patch is to check the list of policies that are shown
before and on the consent page. If that list contains a policy that is
supposed to be accepted on its own page, the existing flow is
interrupted and the user is redirected to a view.php to display that
particular policy.
The view template for such a policy contains a button for getting the
user agreement. When pressed, the policy is marked as accepted and we
can go to start again.
To make this working during the signup, we need to extend the existing
logic and start tracking which particular policies the visitor accepted
prior reaching the signup form. Similarly, we need to start track which
particular policies were displayed and use that list when evaluating
which policies were unchecked on the consent page.
The patch introduces a new property of a policy document called
"Agreement style". It allows the admin to define if the policy should be
accepted together with all others on the consent page (legacy and
default behaviour) or on its page before the consent page is reached
(the new optional behaviour).
