MDL-46783, MDL-63772 and MDL-63818 were originally coded on the
assumption that MDL-46783 would get integrated first. However it wasn't.
Therefore, it was not easy to add unit tests for MDL-63772 and MDL-63818
at the time, but it is now, so here they are.
The capabilities changed ('contextlevel' => CONTEXT_COURSE changed to
'contextlevel' => CONTEXT_MODULE) are:
* moodle/site:accessallgroups
* moodle/site:viewfullnames
* moodle/site:trustcontent
* moodle/site:viewuseridentity
This list came from reviewing the _get_extra_capabilities functions in
all core activities. They were all somewhat inconsistent, but I think it
makes sense that these capabilities are consistently overridable in all
activities. E.g. moodle/site:accessallgroups affects conditional
availability even if there is no other user of groups, and
moodle/site:viewuseridentity and moodle/site:viewfullnames affect the
logs report, if nothing else.
As a result of this, several _get_extra_capabilities functions are no
longer needed, and all the rest have been simplified.
There is an automatic data privacy request created to get rid of all the
personal data upon the user deletion. With the actual user record
absent, the data privacy requests page throws an error. Let's do here
same as we do in `delete_incomplete_users_task` and let us not delete
the actual user record.
The oauth2 standard does not require access tokens to have an
expiration date. This assumes a default validity period of 7 days unless
an explicit expiration date is communicated by the server.
Fix an error with users with the moodle/site:viewfullnames capability
in a course context (like teachers), to display properly the full
names in pages like the participants one.
The converation favourites were previously set in the system context
which is not right, as they should be stored:
- In the conversation context when defined.
- In the user context, when contextid is null (that means is an
individual conversation).
Changed the settings page in the message drawer to display all message
notification processors (e.g. email, mobile, jabber) for the user to
configure based on which processors are enabled on the site.
We were already caching these preferences when a user object is provided
to get_user_preferences, or when $USER is provided.
This changee swaps get_user_preferences to use the global USER object
when the USER->id matches the userid supplied to the function.
If A is related to B, then we should be able to view this relationship
from both badge A and badge B. The following badge methods were updated:
- get_related_badges()
- has_related()
- delete_related_badge()
