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).
Significant string changes:
* errorinvalidbyhour,core_calendar - correcting number from 59 to 23
* cron_help,core_admin - updated recommendation to run cron every minute
* tour1_content_end, tour1_content_welcome, tour2_content_end,
tour2_content_welcome all in tool_usertours - removing reference to
3.2
* invalidsesskey,core_error and invalidsesskey,mod_wiki - more
understandable error message
* pluginname_help and pluginnamesummary in qtype_essay - explaining that
the question type can be used for file uploads
* formatnoinline, mustattach and mustrequire in qtype_essay - changing
the word 'inline' to 'online'
Previously the assign submission page was using "lenient" logic
for overrides when more than one group override applied to a user
(i.e., use the earliest "open" date and the latest "due" date)
when really it should be using the sortorder as per the assign
grading table.
In the detailed statistics view for one user attempt, the user response
for numerical question types was not being displayed.
This was only happening for incorrect responses.
The feedback module lets you alternate between responses being anonymised and
not anonymised. When the module is in anonymous mode, its possible for a single
user to make multiple responses.
However when the activity is switched to non-anon mode, if a user leaves a
follow up feedback, one of their previously anonymous responses is used, so
their new response stays anonymous and their old anon response is lost.
This change lets them leave a new non-anonymised feedback entry and retains all
previous anonymous responses instead of incorrectly reusing one of their anon
ones at random.
