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.
This is not directly relevant to the issue. I just spotted it while
working on the messaging API. Consider it as a well meant Trojan horse
on this branch ;-)
Auth and enrol is moved to the top because other plugin types depend on accurate user list and enrolments. Passwords and failed login messages are generated during every cron execution. Contexts are build properly in each execution. Fixed deleting of unconfirmed users. And minor phpdocs and comments improvements.
"Enable messaging system" (Site administration > Advanced features) is
supposed to control messaging between site users only, thus it should not
remove user messging preferences menu item. However, it may remove instant
messging preferences from providers list for the user.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
AMOS BEGIN
MOV [enableemailnotification,mod_assignment],[enablenotification,mod_assignment]
MOV [enableemailnotification_help,mod_assignment],[enablenotification_help,mod_assignment]
AMOS END
This function populates default message preferences for all existing providers
when the new message processor is added.
The change also includes update of message_set_default_message_preference to
make possible using it for particular message processor update.
install_populate_default_messaging_prefs() is no longer needed and depricted.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
The new messaging default settings can be set in messages.php and deployed
during installation. This also ensures the removing of settings on plugin
uninstallation and contains the update script to populate current default
settings on the existing system when the new feature is introduced.
For security reason we have to avoid using library functions in upgrade
function, so we set defaults the blind way. At this point we do not expect
plugins to have individual messaging defaults presets anyway. The site
defaults are the same as were set for each user using
message_set_default_message_preferences function.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
