Previously, the test was passing by fluke because all question attempt
steps had the same timecreated date. However, the $originaliterator only
contained the first step of the question, not all 3 attempts that were
being backed up and restored. This means we were comparing the
timecreated of the first backed-up step with the timecreated on the
third restored step. As of MDL-68806, the first step's timecreated is
question_attempt_step::TIMECREATED_ON_FIRST_RENDER, which shows up this
error.
This change gets the question_usage_by_activity object back from the
attempt object which contains all the attempt steps, rather than using
the one created in the test, which doesn't.
Currently, large courses can take a long time to perform a full regrade.
This is currently handled with a progress bar to prevent frontend
timeouts while the regrade takes place. However, because it can take so
long a teacher may not want to wait with the page open for several
minutes, particularly if they are performing several operations that
trigger a regrade.
This adds a new async flag to grade_regrade_final_grades which is true
by default. Instead of performing the regrade immediately, this queues
an instance of \core\task\regrade_final_grades for the course, which
will be executed in the background.
It is advisable to always leave the async flag set true, except in the
following scenarios:
- Automated tests.
- The regrade_final_grades task which actually wants to do the
calculations immediately.
- When you have performed a check to determine that the regrade process
is unlikely to take a long time, for example there are only a small
number of grade items.
Historically it was possible, through a series of question restores,
moves and edits, to end up with multiple questions in the same
category with the same stamp, but differences in other question
or answer fields. This, combined with changes in versions, led
to errors when restoring or duplicating quizzes using these questions.
While recent changes have made it impossible to create this situation
in current Moodle versions, as any edits will create a new question
version with a new stamp, this situation may exist on long-standing
Moodle sites which have been upgraded since pre-4.0.
This change performs a much wider-ranging comparison of restored
existing questions, generating a hash of all the data for a question in
a backup file, and a corresponding hash for each question in the target
category, to decide if a restored question matches a question already in
the database.
The restore process assumes all categories in the backup need restoring,
then sorts out which ones to keep later.
This caused issues with restoring set references that used categories
from a shared question bank, since the reference was updated to point to
a copy of the original category, which then got removed as it wasn't
needed.
This change checks whether we should keep the set reference pointing at
the original category, which it will unless:
- We are restoring to a different site (so the original category will
not exist)
- The context the original category belonged to no longer exists.
- The original category itself no longer exists
- The original category belonged to the same context as the original set
reference (in which case we are restoring a whole module, including a
copy of the category)
- We do not have permission to access questions in the original context.
If any of these are true, we should be keeping the restored copy of the
category, and the filter condition should point to it instead.
While MDL-43938 introduced badge importing, two tasks were left incomplete.
1) Creating the backup_import_badges setting for default import behaviour.
2) Preventing the inclusion of badges during activity duplication.
This commit implements them.
- .custom-check is now .form-check.
- .custom-check.custom-switch is now .form-check.form-switch.
- .custom-select is now .form-select.
- .custom-file and .form-file have been replaced by custom styles on top of .form-control.
- .custom-range is now .form-range.
- Dropped .input-group-append and .input-group-prepend. You can now just add buttons
and .input-group-text as direct children of the input groups.
Data attributes for all Bootstrap5 JavaScript plugins are now namespaced
to help distinguish Bootstrap functionality from third parties and your own code.
For example, data-bs-toggle instead of data-toggle.
This commit refactor all old Bootstrap data-attributes to the new syntax.
Co-authored-by: Daniel Ziegenberg <daniel@ziegenberg.at>
- A hook to enable plugins to add extra settings to the restore task.
This would be placed inside restore_root_task::define_settings()
- A hook to enable plugins to add extra fields to the copy course form. This would be done inside the copy_form class.
- An adjustment to add the restore plan settings to the course restored event data.
This would be done inside restore_plan::execute().
- A hook to enable extra work inside the asynchronous copy task. To be placed inside asynchronous_copy_task::execute().
The fields imageauthorname, imageauthoremail, and imageauthorurl have
been removed from badges due to confusion and their absence from the
official specification. These fields also do not appear in OBv3.0.
Additionally, the image_author_json.php file has been removed as it
is no longer needed.
As MDL-73016 set the minimum supported PHP version for Moodle 4.4 and up
to PHP 8.1 we can now safely remove this check.
Signed-off-by: Daniel Ziegenberg <daniel@ziegenberg.at>
As MDL-73016 set the minimum supported PHP version for Moodle 4.4 and up
to PHP 8.1 we can now safely switch to php_serialize as the serialize
handler.
Signed-off-by: Daniel Ziegenberg <daniel@ziegenberg.at>
When a quiz that used shared questions was being restored without the
qbank the questions came from, if the qbank still existed on the target
site, the restored questions were being left in a category in an invalid
course context.
This changes the process so that if the original qbank does exist and
the user can access to it, we will find any references to the restored
copies of questions from that qbank, switch them to refer back to the
original qbank, then delete the category they were restored to from the
course context.
If the user does not have access to the qbank, a new one will be created
in the target course and the questions moved there, just as if the
original qbank did not exist.
