- Fixed reference to non-existent column 'timeread'.
- Fixed alignment issues.
- Fixed inconsistencies between upgrade.php and install.xml.
- Cleaned unit tests of unnecessary DB calls.
- Renamed 'get_does_conversation_area_enabled' to
'is_conversation_area_enabled' and moved to api.php.
- Replaced "$mform->elementExists('enablemessaging')"
check with a capability check.
- Removed the change of [] to array() in unrelated to upgrade code.
- Updated conversation 'timemodified' field when updating name.
- Bumped version based on latest master.
This function has been deprecated and no other function has been
added to replace it. It was only called from can_post_message, so
its code has been moved there.
Created capability 'moodle/site:messageanyuser' to allow
bypass user privacy preferences for messaging participants in a course,
even when some of them has blocked the teacher.
Add new messaging profile preferences to allow users to choose who
can message them:
- By default, users can select between 'My contacts only' and 'My
contacts and anyone in my courses'
- When $CFG->messagingallusers is enabled, a new option is displayed
also: 'Anyone on the site'. For users who have selected this option,
if $CFG->messagingallusers is disabled, the behaviour will be changed
to 'My contacts and anyone in my courses'
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.
It's possible the '\core\message\message' object has a null value
for the 'courseid' which is used in \core\message\manager::send_message().
Make sure we compensate for this.
