Use question_get_top_category() instead of directly inserting into DB when
parent category is 0. This is to make sure we are not ending up with having
multiple top level question categories for a single context.
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).
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.
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.
To kerb future stamp duplication, MDL-54864 added a unique index to the
question_categories table (stamp, contextid) and added an upgrade step
to fix existing duplicate stamps. It missed the case where a course with
duplicate stamps in the same context is directly restored into moodle
3.1, causing index clashes. This issue provides a fix for that.
- New site setting to define the default course duration (used to set
the default end date for some course formats)
- End date setting out of restore
- Fix tool_uploadcourse
- Other fixes here and there
In short, when a user is creating a new course they can set
the ID number, shortname, fullname and summary. However, when
they merge a backup into a course they need the permissions to do so.
Using standard subplugin support, this commits implements
the restore of logstore subplugins in general and the
standard logstore is particular. Notes:
- TODO: Decide about these 2 pending issues:
1) Some logs are already created (events fired) by the restore process itself. Every time
an API is used and it fires events... corresponding (and actual!)
logs are created. We need to prevent restore to duplicate them (or,
alternatively, stop firing events when restore is happening).
2) There are 2 pieces of information in the logs that, right now, can
not be restored, because the process does not know enough to be able
to remap that information to its new counterparts. We are talking
about objectid and other columns. So we need to specify, in some way
understandable by restore, to which existing mappings they correspond
to.
Michael Hawkins