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.
This chagne adds support for a new feature known as Context Locking.
This allows a context to be locked, thereby removing all write
capabilities for all users (including admin) for that context, and all
child contexts.
We need to be able to delay calling all member processors with localised
event data if a DB transaction is taking place. This code treats a
conversation message as a single item of work to be buffered, and stores
all localised eventdata, and processorlists for later reference. When
processing the buffer, we pass off all localised eventdata items to
their respective member's processors, before firing a single event.
CSRF protection for the login form. The authenticate_user_login function was
extended to validate the token (in \core\session\manager) but by default it
does not perform the extra validation. Existing uses of this function from
auth plugins and features like "change password" will continue to work without
changes. New config value $CFG->disablelogintoken can bypass this check.
* New button allows to create standard issuer for nextcloud
* Since the endpoints url has to be https and nextcloud relys on the
baseurl to create the endpoints, the baseurl of issuers has now to be
https as well (or empty).
* Google's baseurl was changed to https (there was no reason not to),
whereas Facebook and Microsoft baseurls remain empty.
* In case of the creation of a nextcloud issuer, the baseurl is
required.
* Nextcloud requires the baseurl, therefore a parameter is added to
create_standard_issuer($type, $baseurl = false). That parameter not
required (or used) for anything but Nextcloud.
Improve the format of the HTML representing a forum post.
1. Use <article> tag to mark it correctly.
2. Use <time> tag to include the real datetime information.
3. Use <address> tag to specify who and when the post came from.
4. Use heading level tags to mark the subject of each post.
5. Properly nest reply posts within their parent <article>
6. Use a header tab for each article to split the metadata from the content.
7. Use CSS to separate links, not text content.
Because posts are now nested properly, the heading for each one refers to it's own article
and we don't need to generate arbitrary heading level tags depending on how deep the post
is nested.
A new optional parameter $context has been added to the
core_group::groups_get_members_join() function.
Besides, some core_group methods now accept -1 (USERSWITHOUTHGROUP) for
the groupid field.
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()
Before this patch, we only checked that the given provider has been
configured in the user or system preferences. However, if the provider's
component is disabled, it does not even appear in these preferences.
Additionally, there was no check that the message / notification
provider is among providers allowed to be consumed by the recipient.
The patch checks that the message origin is among providers returned by
the message_get_providers_for_user() so disabled plugins can't act as
sources of messages and users can't receive messages from providers they
do not have capability for. This mitigates the risk of abusing a plugin
as a source of spam, for example.
Unit test is fixed and extended. When the $CFG->messaging is disabled,
no messages between users should be sent (I can't understand why the
unit test was written in an opposite way). Added assertions for the
raised debugging message.
Support use of a token for access to pluginfile.php when rewriting text
content.
This is primarily intended for notifications where the user is unlikely
to be logged into Moodle when receiving the notification.
