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'
Also deprecated the following functions -
1. message_move_userfrom_unread2read - It is not necessary
for us to mark a message as read on user deletion.
2. message_get_blocked_users - Horrible logic used to
determine if a user is blocked via reference on some
randomly chosen 'isblocked' variable.
3. message_get_contacts - The same as above. This can be
done in a much nicer way.
4. message_mark_message_read - We want two functions to do
this to avoid confusing messages and notifications.
5. message_can_delete_message - This assumed the variable
$message contained the 'useridto' property, which
was present in the old table structure. We do not want
future usages where a query is done on the new table
and is simply passed as this won't contain this property.
6. message_delete_message - Same as above.
The OR clause in these queries used different sets of columns to select
userid which meant that the indexes that included user id could not be
used.
This change splits the query so that each individual part can use one of
the indexes that includes a userid which speeds them up considerably.
If there was no conversation found and the method returned early, the
active transaction was not marked as committable and the error was
reported by the request shutdown handler.
Attaching a unit test for the case just because it did not seem to be
covered. I was trying to reproduce the thrown error in the unit test but
it can't be used in this case. The shutdown handler puts the warning
directly into the error_log and it is not guaranteed where such messages
go (depending on the PHP configuration). And we do not even raise it
during the unit test execution (presumably due to noise it would
produce) anyway.
I have broken up the single query that was doing multiple joins on the
messaging and user tables. It no longer does any joins and will instead
query each data set individually.
This may cost more in terms of PHP processing but it will mean that
standard database tunings should be able to handle larger data sets.
For example this function was taking a long time to run on moodle.org
and was causing the MySQL join buffer to overflow.
