Added new MESSAGE_CONVERSATION_TYPE_SELF type for self-conversations
and upgraded legacy self-conversations to the new type, removing
repeated members in the message_conversation_members table.
Besides, from now, a self-conversation will be created by default for
all the existing users.
All the self-conversations have been also starred and a default message
will be displayed always to explain how to use them.
- The get_conversation_messages has been added to the API and the WS
with the conversation identifier (convid) instead of the userto,
to let get conversation messages and the members involved.
- The cache has been also reviewed, to use the convid instead of the
[userfrom, userto] keys.
- The get_most_recent_conversation_messages has been added to the API
to update the cache when needed.
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.
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.
- No longer use the Fibonacci sequence for delaying the timeout.
It is too aggressive.
- The backoff_timer AMD module now expects the callback AND the
backoff function to be passed to the constructor.
- Added ability to specify polling frequency in config.php.
- Added helper function to return the cache key.
- Reworded the parameters for clarity.
Instead of silently defaulting to SITEID when courseid (coming
from message_send()/\core\message\manager::send_message()) is missing,
now a debugging message is shown to allow developers to fix their
messages to, always, include courseid.
Raw creation of events via message_sent::create() missing other[courseid]
leads to coding exception since now (there shouldn't be any legacy use, as far as
they are always created via create_from_ids() when sending a message.
Updated upgrade.txt notes a little bit, added references the 3.6 final
deprecation issue (MDL-55449) and covered with unit tests.
dirname() is a slow function compared with __DIR__ and using
'/../'. Moodle has a large number of legacy files that are included
each time a page loads and is not able to use an autoloader as it is
functional code. This allows those required includes to perform as
best as possible in this situation.
This patch includes following fixes:
- messages may be now sent when database transactions active
- consistent return status on failure from message_send(), false is
returned only when message not created in message(_read)? table,
processor failure results in debugging message only and messages
are not marked as read
- message_sent is triggered always with id from message table
- logic for marking messages as viewed was standardised
- message_viewed event is triggered consistently
- improved performance when fetching user preferences
- full unit tests coverage for send_message() function
- fixed multiple other smaller issues discovered by unit tests
This is used by messaging system for sending/receiving message
to/from noreply or support user. message_send api will now use
core_user class to get noreply or support user and then
send/receive message depending on user state.
Some message providers have an associated capability. For example
the mod/quiz:emailconfirmsubmission capability. At the moment,
we only show the preferences for the capabilities that the user
has in the system context.
That does not work for the example capability above. Typically
the capability will be overridden in one quiz, to allow for
Students, and the user will have the Student role in the course
context. Therefore, this message type does not appear on the
preferences page.
This fix corrects the logic, so that all message types that are
to the current user are displayed.
