The new recordset support for Postgres requires transactions and
will cause errors if recordsets are not closed correctly. This
commit fixes problems that were identified during unit tests, and
via some basic code analysis, across all core code. Most of these
are incorrect usage of recordset (forgetting to close them).
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).
- Built using standard backup custom fields.
- Can be applied potentially everywhere.
- Automatically addded 'encrypted' attribute.
- Defaults to site generated key.
- Enforces key robutness / provides authentication (hmac integrity)
- Covered with unit tests.
- 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
When restoring into a new course, it will queue a request to index
the whole course; when adding to existing, it will queue a request
to index the specific (a) activities and (b) blocks that were
restored.
- 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'.
- added relevant cap check on restorefile.php to improve the error
message when attempting to restore automated backups. This cap is
already responsible for controlling restores from automated areas.
- Restored the 'viewautomatedfilearea' capabilities original lang
string.
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.
1) There is no need to store the 'timemodified' value of
the section when backing up a course module, they do
not refer to the same time.
2) When creating a new course section during restore use
the current time.
3) Added timemodified value to more places when updating
the 'course_sections' table.