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.
Re-factor existing code to make use of file manager class that renders
these details for us by default.
Co-authored-by: Simey Lameze <simey@moodle.com>
The previous code was resetting timestamps for only the file itself,
which could lead to it having an earlier time than the root entry of
it's filearea.
This caused sporadic test failures when the current time ticked over
by a second during execution.
It has been detected that the flatten_dependencies_array() was fragile
and leading to wrong results when some incorrect data was passed to it.
This includes:
- Missing elements.
- Null dependencies.
- Non array dependencies.
While the existing behaviour (testing-wise) has been preserved, now the
situations above are better controlled and the function ignores all
those incorrect cases that shouldn't happen ever.
That implies that a good number of notices/warnings/errors aren't
happening anymore. That was impacting both results (when the problems
were only notices and warnings) and execution (when the problems
were errors).
Covered with tests.
Reverting the addition of a Boostrap tooltip on the alert notification's
close button. It introduced a bug where the tooltip remains after
dismissing the notification alert. We can manually toggle the state of
the tooltip via JS, but I don't think it's worth the effort. The tooltip
is meant as an added bonus for sighted users to see what the close
button is about.
