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.
Changes:
- Add logic to retrieve all the existing current roles.
- Apply the backup's role shortname by matching on the archetype.
- Added backup lang string 'undefinedrolemapping'.
The new setting will allow to host the temporary backup files
into a specific target directory. Defaults to '$CFG->tempdir/backup'.
Calling make_backup_temp_directory() checks that the required sub-directory
will be properly created under the new target directory.
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.
Shamim Rezaie