- 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.
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>
