Prevent backups containing legacy MD5 hashed user passwords
from being added back into the database. Hashes are converted
to random SHA512 hashed passwords upon restore for these backups.
Several version checks were incorrectly using
restore_controller::info::moodle_release instead of moodle_version as a
version number. This replaces all of those checks with a common pair of
methods to make the checks clearer and more maintainable.
Applied the following changes to various testcase classes:
- Namespaced with component[\level2-API]
- Moved to level2-API subdirectory when required.
- Fixed incorrect use statements with leading backslash.
- Remove file phpdoc block
- Remove MOODLE_INTERNAL if not needed.
- Changed code to point to global scope when needed.
- Fix some relative paths and comments here and there.
- All them passing individually.
- Complete runs passing too.
Special mention to:
- Some fixtures, initially defined in the test files have been
moved to new files in fixtures subdirectory, leaving the unit
test files clearer:
- moodle2_course_format_test.php
- Rename wrong named test:
- baseoptiogroup_test = baseoptigroup_test
The versioning changes will require some major changes
in the backup and restore of question bank and its
elements. This change introduces those changes to make
it compatible with the new world of versioning in question
bank. This commit also removes quiz_slots fields and
quiz_slot_tags table.
This commit will also introduce the versioning db
structure and some major changes to the quiz
and quiz attempts for the question, random
question and the view.
This commit implements the behat changes for versioning
in core question and associated locations.
Though it's really rare for this to happen (it only was discovered
when running unit tests with Oracle), it's possible to get
problems restoring courses when context ids in the backup file
do match existing contexts in the restore target site in certain
ways (see the issue for more information).
This change just ensures that every call to the method (that
happens 4 times, for sys, coursecat, course and module levels):
prechek_precheck_qbanks_by_level()
Is processed always for that level. Before the patch it was
possible (hardly but possible) to return question categories
belonging to another level when some qcats contexts were matching
between the backup file and the target site.
All the setup/teardown/pre/post/conditions template methods
now are required to return void. This was warned with phpunit 7
and now is enforced.
At the same time, fix a few wrong function names,
provider data and param types, return statements...
1) Remove any floatval() casting. They are breaking / killing
.10 versions (converting them to .1). Since Moodle 2.0 all the
backup::RELEASE have been 100% numerical values.
2) Use version_compare() always to compare backup::RELEASE values.
They are always versions and the function is aware of versions
> .9, able to clean/ignore alpha chars... and everything else.
Note that I've also changed a couple of cases in formats (topics and
weeks) that were correct, but just added the same comment and used
the same version_compare() comparison parameters style, so all uses
in core are consistent (and safe to be copied out there).
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.
They are really a pointer from a particular quiz to a question category.
They should never be shared, because if they are, unexpected things
happend when they are edited.
Changed the course libs such that module and section deletion is now
handed off to relevant functions in the util class and exempted
modules scheduled for deletion from the course backups.
The unserialize() function will not always return an object
especially when as can happen the controller field of a
record in the backup_controllers table is empty.
This change ensures that in this case the script will
not cause a fatal error, but instead throw an error.
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.
General backup/restore does not need to handle external data sources natively - so
any changes needed to achieve this should be contained to the plugin that needs it.
Huong Nguyen