Before this patch we would be marking some items as 'needsupdate'
during an update. Leaving them aside and not effectively updating
them.
Part of: MDL-46576
If you edited a question from the Edit quiz page in a quiz, the navigation
bar was far too long. This was due to some odd code that was trying too
hard to be clever.
Instead, editing a question is now always treated as being logically within
the question bank for the purposes of navigation. That is, even if the
returnurl will end up taking you back to where you where when you have finished.
This commit is actually the joint work of Mahmoud Kassaei, Colin
Chambers and Tim Hunt from The Open University. We could only use one
persons name for the commit, and this time Colin gets the credit/blame.
The goal of this work was to increase usability, and also clean up
the page enough that it will be possible to add new features in future.
Display of mod/quiz/edit.php is now entirely generated by
mod_quiz\output\edit_renderer. This uses a helper class
mod_quiz\structure to provide details of the structure of the quiz, and
mod_quiz\repaginate to alter that structure. (Acutally, there are still
some modification methods on mod_quiz\structure. Expect that to be
cleaned up in future.)
The new code uses much more ajax, and there are new scripts
mod/quiz/edit_rest.php and mod/quiz/repaginate.php to handle this.
(Again, don't be surprised if those two scripts get merged in future.)
Also questionbank.ajax.php (which may, in future, be made more generic,
and moved into the core question bank code.)
Most of the new JavaScript code has intentionally copied the way things
are done when editing activities on the course page.
As a result of this, mod/quiz/editlib.php is now much shorter than it
was. (In future, expect the remaining code in here to move into
mod/quiz/classes.)
Learnwise was an old LMS that no longer exists. (Last reference found on
Google from 2009.) So we are removing the ability to import questions in
that format.
This is an extremely dangerous query, because it includes the user
table twice, along-side two other potentially large tables,
role_assignments and user_enrolments.
The solution is to rewrite the query so that:
1. The subquery is JOINed, not WHERE ... INed. Typically query
optimisers handle the JOIN case better.
2. Before the join was role-assignments <-> users <-> subquery.
That is, everything was linked to u.id.
Now the linking is role-assignments <-> subquery <-> users,
so the SELECT DISTINT eu1_u.id FROM {enrolled users} is central.
That seems to send a strong hint to the query optimiser about
a good order to execute the query.
