Continuing from the last commit, the code to restore question
bank entries, versions and questions, was not taking note of
whether the first stage had indentified questions that did not
need to be restored. This is tricky, but the mapping can only be
worked out for questions, but in the backup file, the questions are
inside the question_bank_entries, and versions, so we encounter
those first.
Now, the code just saves the QBE and QV when it encounters them,
and then does all the processing when it gets to the question,
correctly taking note of whether each question should be restored or not.
In cases where a particular question does not need to be restored,
we still set up the corresponding mappings.
Restore of categories and questions happens in several phases.
First, the file is scanned for which questions and categories
it contains, to work out if these are new questions which need
to be restored, or if they already exist in the database in a
place that can be used.
That code had not been updated to cope with the Moodle 4.0
versioning changes, so it is updated here (while still keeping
the code to cope with the old backup format.)
The badges/index.php and badges/view.php pages are quite similar and
have been merged into index.php.
This commit updates index.php to incorporate the missing information
previously found in view.php.
Duplicate data provider keys were overwriting and/or duplicating
one another, leading to some cases being skipped.
Other "duplicate array key" errors were picked up by `phpcs` in
this dragnet across all tests, which have also been fixed.
The dependency of badges on user data and activities has been
removed when copying, importing, or creating backups in courses.
Now, badges can be imported or copied even if user data and activities
are not selected:
- If user data is not selected (during backup or course copying), the badge
information (name, description, image, etc.) and criteria will be included,
but the users who have been awarded the badge will be excluded.
- If activities are not selected (during backup), the badge information
(name, description, image, etc.) will be copied, but the criteria and users
who have been awarded the badge will be excluded.
This commit adds two new levels to the restore course structure form:
subsection (a delegated section that belongs to a course module) and
subactivity (a course module in a subsection).
Restore form can only use information from the backup file. To allow
activities to know if they are inside a subsection, the backup now
incorporates an "insubsection" attribute. This attribute is used only
for the form display but not for the restore logic.
The patch adds two new levels to the backup form structure: subsection
(a delegated section which parent is a course module) and subactivity
(an activity inside a subsection). Those new elements are displayed as a
inner section below the parent activitiy.
For now the UI is the same as a regular section but future issues will
define how the UX should be. The new two levels have their own classes
to represents settings and have extra dependencies.
This commit adds all the logic to allow delegate sections backup and
restore. The backup and restore process is quite complex and it is not
designed to have task hierarchy. To solve the subsection problem, the
backup/restore planners do not include delegated sections at a course
level, but they are included when the activity with delegated section is
processed.
To allow restoing, the activity is responsible to store the
component/itemid mapping in the backup_structure_dbops. This way, when
the delegated section is restored (delegated sections are always
processed right after the parent activity) it can use the itemid
mapping.
Backup and restore settings needs to be refactored before introducing
subsections. With the current code adding two new hierachy levels
(subsections and activities in subsections) will require many
unnecessary lines of code because most of the structure is hard-coded.
With this patch when backup/restore present the course structure uses a
stack to control how mani divs are opened, instead of relying on adhoc
class attributes per each div.
About the tasks for sections and activities, the class has been
refactored. This way when subsections are introduced it will require
less lines of code and the final patch will be more comprehensible.
This fixes various (not all) wrong @covers annotations that
are reported as warnings by PHPUnit when it's run with
code-coverage enabled.
When possible, the preferred solution is to change to
@covers at class level, that is the recommended way.
If multiple classes are involved, then a mix of @coversDefaultClass
and @covers at method level are used (always trying to use the
minimum needed patch).
This is the first of a series of issues created as sub-tasks
of MDL-82142.
