Previously, when a during backup/restore the "Schema"-stage is loaded,
some settings are fixed if they are LOCKED_BY_HIERARCHY. However, user
data fields of activities can be locked, when the section they are
contained in has user data set to false. When this setting is changed on
the same screen, the fixed setting of the activity can not be "unfixed"
by javascript.
This patch adds a settings-level to the call of is_changeable. With this
only those dependency_settings are considered, which belong to parent
settings, which are not changeable on the current stage.
The function is_locked was changed to determine only, if the
dependency_setting want's the dependent setting to be locked.
In the previous version, is_locked did not only check, if the
dependency_setting want's the setting to be locked, but also if the
setting was already locked. A recursive call to the status of the
dependent setting leaded to problems, when unlocking locked settings.
Also the PHPDOC of the is_locked was adjusted to coincide with the current
usage in backup_ui_settings->is_changeable() and
base_setting->set_status(). In both functions all dependency_settings of
a setting are iterated to check if this setting should be or is LOCKED_BY_HIERARCHY.
The actual state of the setting was therefore either checked beforehand
or is not interesting, since the question is, if it shall be changed.
This new test defines different combinations of global and local user
data settings during the restore process and tests that global defaults
can be overriden.
- Uses site generated (on backup) key.
- Can be applied potentially everywhere in the restore process.
- Covered with unit tests.
- Authentication / integrity aware so can be used between any 2 servers
(just requires matching key).
- count() can only be called on arrays or Countable, it can not be called on null
- recordset is neither so iterator_count() should be used
- instanceof or get_class() can not be applied to non-objects
- class methods must have the same arguments as methods in parent class
- Users without permission to download or restore won't see the
respective links.
- The 'Manage backup files' button for the 'automated' backup filearea
now requires the same permissions as downloading does for this filearea,
those being 'restore:userinfo' and 'backup:downloadfile'.
It was decided to roll only configuration dates and any date related to user content
such as 'timecreated' , 'timemodified' etc should not be rolled forward.
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.
