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.
This is useful because config_logs are sent via logstores, and we may be interested to know how
many people change a particular admin setting across many sites (aggregated data).
- Split model::predict in parts
- JS promises updated according to eslint-plugin-promise
- New API methods replacing direct DB queries
- Reduce insights nav link display cost
- Increase time limit as well as memory for big processes
- Move prediction action event to core
- Dataset write locking and others
- Refine last time range end time
- Removed dodgy splitting method id to int
- Replace admin_setting_predictor output_html overwrite for write_setting overwrite
- New APIs for access control
- Discard invalid samples also during prediction
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.
Use core functions that are faster for test file creation.
To support large requests for hashes, the core hash function
must support large hashes without recursion. PHP has a default
recursion depth of 100 and long hashes don't support this.
Remove transactions as they create performance problems for larger
courses and doesn't introduce significant benefit for developers.
Performance changes meant the times were much faster, a reasonable
guess was taken on performance of an average machine.
This patch adds two new functions to the event base to allow deprecation of
the individual events, without entirely removing them from the UI.
This is different to our normal deprecation procedure because all events
must support display of historical data. It must also be possible to view
the event information in the event monitor.
Mark Nelson