When restoring a backup containing a question bank, we were always
trying to match questions to an existing category on the target course
if once existed. This meant that when duplicating a qbank on the same
course, or importing the same qbank to another course multiple times,
only one of the restored qbanks would end up with questions in it.
This adds a mechanism to record any activities in the backup which
support `FEATURE_PUBLISHES_QUESTIONS`. Then when we restore the
questions, we check if we will be restoring the original activity they
belong to, and skip trying to match them to an existing category. This
means a new copy of each question will be created, and moved to the new
copy of the qbank once it is created.
This patch modifies the way copy data is shared in order to mitigate potential race conditions
and ensure that the serialised controller stored in the DB is always in a valid state.
The restore controller is now considered the "source of truth" for all information about the
copy operation. Backup controllers can no longer contain information about course copies.
As copy creation is not atomic, it is still possible for copy controllers to become orphaned or
exist in an invalid state. To mitigate this the backup cleanup task has been modified to call
a new helper method copy_helper::cleanup_orphaned_copy_controllers.
Summary of changes in this patch:
- Copy data must now be passed through the restore controller's constructor
- base_controller::get_copy has been deprecated in favour of restore_controller::get_copy
- base_controller::set_copy has been deprecated without replacement
- core_backup\copy\copy has been deprecated, use copy_helper.class.php's copy_helper instead
- backup_cleanup_task will now clean up orphaned controllers from copy operations that went awry
Thanks to Peter Burnett for assiting with testing this patch.
This patch adds asynchronous backup and restore functionality
to Moodle. This is an optional feature and is not enabled by
default. It can be enabled by site administrators.
Asynchronous backup and restores are actioned by the Moodle
adhoc task API. The progress of backup and restores is
displayedin the Moodle UI. Users can also be sent a message
when a backup or restore operation completes via the
Moodle messaging API.
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).
Mark Johnson