New API \core_search\manager::request_index($context, $areaid = '')
adds the given context to a list which is intended to be indexed
later by the scheduled task.
This was supposed to be split into multiple commits to make it easier to understand
but I failed to do it properly. So this is the list of changes:
- New analytics_indicator_calc db table to store indicators calculations
- Reuse previous calculations during prediction/training; other models
previous calculations should also be reused as long as they belong to
the same sample (sampleid depends on sampleorigin), time range and indicator
- Allow bulk inserting of these calculations as this can hurt database performance
- Block the same analysable to be analysed for training and for prediction
- Use a new instance of the target and use it for is_valid_* functions
as using ::is_valid_sample can lead to problems if people
uses it to cache stuff
Now we only predict using the most recent range available, this means
that if someone upgrades to moodle 3.4 at three quarters of a course
we will only calculate the latest range, previous ranges were not
displayed anyway once more recent predictions were available.
This commit deletes all previous predictions :) this shouldn't be a
problem in master as we don't provide any guarantee, the alternative
(retrive sampleids from mdl_files) would have been slow and a waste of
time as well as require horrible code in an upgrade step (text fields
do not accept defaults nor we can use NOTNULL).
Show the username and email of the connected system account (if it ever requires refreshing - this will help identity the account
to re-authorise).
Part of MDL-58220
* New priority column in order to enable the rendering of a single,
relevant calendar event for a module that has user/group overrides.
* Insert refresh_mod_calendar_events_task record to task_adhoc
table to upgrade existing calendar events for mod plugins via cron
after upgrade process.
Add field 'visibleoncoursepage' to the course_modules table
Add site-wide setting for turning on stealth mode availability
Add callback for "stealth" mode support in the course formats
Change display of modules/sections availability on the course page
Now if the current theme requires some blocks that don't exist, they
will be created - but with a new flag that indicates this block should
only be returned if the current theme requires it. This allows flipping back
and forth between boost and clean without restoring the nav and settings blocks
in boost.
Created a flag, 'deletioninprogress' on the course_modules table to be
used when deleting course modules and course sections. Modified
modinfolib caches such that, when rebuilt, these caches hide the
relevant modules based on the value of the flag.
Private tokens are generated at the same time that the token.
They must be stored safely by the ws client, and they must be transmitted only via https.
