Cron can cause duplicate completion records if triggered during a long
running restore process. If this is the case, replace the new record
with the record from the backup file
When we restore a course, the grade that a user has for the
grade item of the course cannot be created twice. If we try
to create it when it already exists, a database exception is
raised because of index duplication.
The safest way to proceed is certainly to ignore the grade
information from the backup, otherwise we could potentially
overwrite existing information. Though, this only applies
to restore as merge, and it does not affect the update of
the course grade.
Implements backup and restore for the new conditional availability
data. This includes:
* Backup and restore of new field.
* Restore updates IDs in conditions, as required.
* Restore converts availability data from legacy (Moodle 2.6) backups.
* Unit tests for all this.
The sequence of questions that made up a quiz used to be stored as a
comma-separated list in quiz.questions. Now the same information is
stored in the rows in the quiz_slots table. This is not just 'better' in
a database design sense, but it allows for the future changes we will
need as we enhance the quiz in the MDL-40987 epic.
Having changed the database structure, all the rest of the code needs to
be changed to account for it, and that is done here.
Note that there are not many unit tests for the changed bit. That is
because as part of MDL-40987 we will be changing the code further, and
we will add unit tests then.
While restoring course/activity, restore will blindly insert grade_item
sortorder. Which cause dulicate sortorder and lead to unpredicatble sorting
results.
Now we will call grade_item::fix_duplicate_sortorder() after restore is finished
to fix duplicate sortorder and order grade items to the closest order possible
Previously, restore was blindly inserting the old sort order into the
database, causing duplicate sortorders which lead to unpredicatble
sorting results.
Now we will use the api function to add it after the original sortorder,
this means if a duplicate exists in the original location, this item
will appear after it.
If a backup contains a large number of questions, the
create_question_files function can take a very long time. This
change adds progress reporting during that function.
When restoring a backup that contains a large number of users
to a different server where those users don't already exist,
creating users can take a significant time. This change adds
progress reporting so that it doesn't time out and shows
activity in the user interface while doing the creation.
Deleting directories at the end of backup can take a long time if
there are many directories (potentially up to 65536 file
directories). This change reports progress while deleting
directories to avoid timeout.
When doing a backup or restore operation with the normal user interface,
if there is anything in the backup/restore log, it will now be displayed
at the end of the process below the Continue button.
If you have developer debugging enabled, it sets the display level to
LOG_DEBUG and there will always be content in the log. Otherwise, it
uses LOG_INFO which generally means the log is empty, and nothing
displays (no visible change for users).
This parallels question_attempt->minfraction, which allows the
fractional mark to go below zere.
This is needed to allow the certainty-base marking behaviours to work
better.
1. Changes progress bar code to allow headings for progress bar (so users have
some clue what's going on if a page has more than one progress bar).
2. Changes restore code so that a progress bar can display during pre-checks if
they take longer than 5 seconds.
3. Changes pre-check and restore code so that, in various points where the system
can take a long time within an individual step, intederminate progress is
indicated and it won't time out.
encode_backup_temp_info() and decode_backup_temp_info() have been
introduced to keep the info field encoding in one place.
Many locations used get_backup_ids_record() to obtain info, that
makes lots of calls to get_backup_ids_record() which can be slow.
We now complete all those inline by adding the info field to the query.
To reduce memory usage, all queries of that nature have been changed
to use get_recordset_*. gzcompress was introduced if available to minimize
traffic to/from the database and to decrease the memory required for caching.
The compression time is saved by the benefits in other places of having smaller data.
This patch fixes:
* missing enrolment methods after 1.9 backup restore - defaults are added
* enrolment methods are restored only when users option is enabled
* manual enrolment override option is disabled if users not available
Andrew Nicols