This has been generated running the following Sniffs, all
them part of the Moodle's CodeSniffer standard:
- PSR12.Functions.ReturnTypeDeclaration
- PSR12.Functions.NullableTypeDeclaration
- moodle.Methods.MethodDeclarationSpacing
- Squiz.Whitespace.ScopeKeywordSpacing
All them are, exclusively, about correct spacing, so the changes
are, all them, only white space changes.
Only exceptions to the above are 3 changes what were setting the
return type in a new line, and, when that happens, the closing
parenthesis (bracket) has to go to the same line than the colon.
The OR conditions in the WHERE clause prevented the query from
effectively filtering the messages related to the user quickly, this
change helps gets around this by allowing the database to limit
the rows in the messages table it needs to scan significantly.
In MDL-67853, the "Enabled" label was added to all the toggle switches in the
user notification preferences page. This string is confusing, so this issue
is to remove it (and leave it as it was in 3.11).
Apart from that, following Helen's suggestion, I've renamed "Disallowed" to
"Locked off" and "Locked" to "Locked on", in order to help users to understand
better their meaning.
If a component has no available notification types (because they're
disabled), then it (the component) should be hidden entirely from
the user notification preferences page.
When the messagingallusers setting is disabled only contacts that are
on the same course as the user should be returned as results.
We can reduce the number of candidate users significantly by
pre-filtering them by being enrolled on the same courses as the user
performing the search.
Since we must also return the user themselves sometimes, even when they
are not enrolled on a course I used a UNION as the most efficient way of
retriving them, this meant that the order by had to reference returned
columns by number to be sufficiently cross-database compatiable.
There were existing places each doing its own checks similar to the ones
covered by the newly added core_user::awaiting_action() method. This
patch replaces those custom checks with this new API call.
This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).
Added an admin setting to show/hide the emoji picker in messaging
because some versions of MySQL don't have full unicode support so
emojis won't save in the dabase.
If we detect that the site is running an unsupported version of MySQL
then the setting can not be enabled. Instead the admin will see a
message explaining that they will need to upgrade their database
before they can enable the emoji picker.
It is possible that before this patch the user blocked a
teacher from messaging them, even though this would have
no effect. It is also possible for a user to block a user,
then that user gets 'promoted' to a teacher role and the
block becoming ineffective. In these cases we dont show the
user's status as blocked.
If blocking will have no effect (ie. you are attempting to block
the admin) the 'Block' button will not be shown and instead a
message will be shown explaining why you can not block the user.
We previously had this page when contact requests were first introduced
and unfortunately we created a bunch of notifications that reference
this URL directly which now won't work because the page has been removed.
I've added it back but set it to redirect to the message/index.php page
and load the contact requests page there.
Instead of creating all the self-conversations during the upgrading,
some code has been added to the get_conversations and to the
get_conversation_counts to create it whe it doesn't exist.
