This patch adds better core support for copying courses.
There is now a simplified and dedicated UI for copying
courses. This can be accessed from the course context
menu or course management screens.
All backups are done asynchronously and there can be multiple
copies of a course in flight at once.
Allow both UI and automated backups to be created without
including files. Instead include only file references.
This is essentially implementing "SAMESITE" to backup files
instead of only for import and export functionality.
A new backup setting to include files (defaults to yes)
has been included.
The restore process will also look for and attempt to
restore files from the trashdir as part of restoring
backups. Additionally to support this process the
ammount of time files are kept in trashdir before they
are cleaned up via cron is also adjustable via admin
setting.
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.
Any backup & restore operation may be leaving opened files
if a file logger is being used. This implementes the close()
method, so every logger can close any resource.
Also, the recommended backup_controlled::destroy() method
now calls to new logger::destroy() method in charge of
deleting all the references and closing any resource.
Finally, some internally used controllers, were missing
their destroy call, leading to associated loggers to
remain open. Now all them are explicitly deltroyed.
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).
When we import courses or duplicate activities, the deduplicating nature of
the file_storage system means that we don't actually have to include the
real files in the backup - just their metadata from the file table.
The restoration process needs to know not to expect files from the backup
phase so a flag is set in moodle_backup metadata.
Some modes of backup cannot be preloaded with general backup
settings because they may conflict with the definitions required/set
by the mode (for example, import backups are, by definition, without
users always, so we cannot apply one default in the opposite direction).
So, after the patch, current general_backup setting will be only applied
to general backups, import/hub modes won't be using any default and
automated backup defaults should be loaded here (TODO)
