There were 4 instances of the calendar refresh events task being
queued, which is redundant as we now have the "one true task" to
fix the events table, and it needs to be run for everybody.
This upgrade step was setting the priority field for assign events
in the events table. This is redundant since we queue a task to
refresh all events.
This patch also removes a redundant refresh_events task that is
queued from assign.
The assign update events code depends on the "old" events in the
DB being returned in the same order as they were originally made,
however there was no guarantee that this would be the case.
There were also situations where the priority would not be explicitly
set (e.g., when creating the "original" event).
The lesson update events code depends on the "old" events in the
DB being returned in the same order as they were originally made,
however there was no guarantee that this would be the case.
There were also situations where the priority would not be explicitly
set (e.g., when creating the "original" event).
The quiz update events code depends on the "old" events in the
DB being returned in the same order as they were originally made,
however there was no guarantee that this would be the case.
There were also situations where the priority would not be explicitly
set (e.g., when creating the "original" event).
Previously we did not require the lib.php files for each module
in this ad-hoc task, which meant that the *_refresh_events functions
would only be called if some lucky sequence of events led to the
lib.php file for the module being required.
Instead we should use the component_callback function which can handle
that stuff automagically.
As a result of fixing the auth plugins config storage in MDL-12689, many
settings would be falsely reported as new ones by
admin/upgradesettings.php. We do not want to confuse admins so we try to
reduce the bewilderment by pre-populating the config_plugins table with
default values. This should be done only for disabled auth methods. The
enabled methods have their settings already stored, so reporting actual
new settings for them is valid.
It has never been guaranteed that settings.php would always be included
from inside the core\plugininfo\auth::load_settings() scope only.
Alternative fix would be to use $plugininfo->name but I think it is
better to be explicit here (same as we are explicit with setting names,
strings etc).
