Similarly to how the scheduled tasks work, we now automatically check
and make sure that all the models specified in the component's
db/analytics.php file exist during the installation or upgrade of the
component.
The functionality of the \core_analytics\manager::add_builtin_models()
method is to be replaced with automatic update of models provided by the
core moodle component. There is no need to call this method explicitly
any more. Instead, adding new models will be done by updating the
lib/db/analytics.php file and bumping the core version.
Properly integration badges with competencies provided in Moodle.
Automatically grant the badge when the defined competencies are marked as proficient.
Due to the bug, the no_teaching model might have been marked as
not-trained in the database. Static predictions models (i.e. those using
a target based on assumptions, not facts) are always considered as
trained. If they were marked as not-trained, the prediction scheduled
task would skip them and they would produce no predictions.
Ideally, such a fix should be done for all static models. But there is
no easy way to do it during the upgrade where accessing the analytics
API is not possible. I don't think there are many models out there that
would be affected by this so this seems to be good enough solution for
now (and the future ability to reset models will cover the rest).
The useridfrom would normally be a foreign key to the users table. But
it can also contain some extra negative values with special semantics
(-10 or -20 for no-reply or support user). Therefore we can't make it a
foreign key and the index must be created explicitly.
This commit is part of work on Custom fields API,
to minimize commit history in moodle core the work of a team of developers was split
into several commits with different authors but the authorship of individual
lines of code may be different from the commit author.
This commit is part of work on Custom fields API,
to minimize commit history in moodle core the work of a team of developers was split
into several commits with different authors but the authorship of individual
lines of code may be different from the commit author.
Purge cache just for the current user to avoid redirection when 2
simultaneous users try to sign up at the same time and some policy
has to be agreed.
The 'createduser' invalidation event has been removed also because
is not used any more.
Thanks John Azinheira for spotting it!
3.7 (min PHP 7.1) requires 3.2 (first version supporting PHP 7.1)
This just deletes all the upgrade steps previous to 3.2.0. Some
small adjustments, like adding missing MOODLE_INTERNAL or tweaking
globals can also be applied when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2016120500 (v3.2.0) as anti-cheating measure.
Next commit will get rid of/deprecate all the upgradelib functions
not used anymore in codebase. (note there isn't any this time).
The capabilities changed ('contextlevel' => CONTEXT_COURSE changed to
'contextlevel' => CONTEXT_MODULE) are:
* moodle/site:accessallgroups
* moodle/site:viewfullnames
* moodle/site:trustcontent
* moodle/site:viewuseridentity
This list came from reviewing the _get_extra_capabilities functions in
all core activities. They were all somewhat inconsistent, but I think it
makes sense that these capabilities are consistently overridable in all
activities. E.g. moodle/site:accessallgroups affects conditional
availability even if there is no other user of groups, and
moodle/site:viewuseridentity and moodle/site:viewfullnames affect the
logs report, if nothing else.
As a result of this, several _get_extra_capabilities functions are no
longer needed, and all the rest have been simplified.
