Includes option to convert all enrolments to enrol_manual instances, support for mapping of custom fields and fixes for several other problems. This does not include support for custom enrol tables, it will be addressed in another issue.
An activity module might want to use question_usages in different ways.
We should suppport this, because it lets people make interesting
activities.
At the moment, the backup and restore code does not support this,
because it uses fixed element names for the question_usage element and
its children. This fix changes things so that a prefix can be appended
to all the element names.
* Fixed up database installation and upgrade code
* Reverted some whitespace optimisations to minimise conflicts
* Optimised commits made by Mark to reduce complexity and add tracker issue numbers
It was not previously possible to have a section called 0 because of
bugs in the standard course formats, but we hit this with the OU course
format. You got an exception because backup settings tested to see if
their lable was empty, which means a section name of '0' was fatal.
Should work now.
Conflicts:
lib/db/upgrade.php
lib/phpunit/lib.php
version.php
Fixed:
lib/db/upgrade.php - duplicate course->sectioncache add code
lib/db/install.xml - cleanup needed because xmldb editor was not used
lib/phpunit/classes/util.php - cleanup $GROUPLIB_CACHE on test reset
Credit: original version done by Kirill Astashov of NetSpot (netspot.com.au),
finished and tweaked by sam.
This change adds conditional availability support for sections analagous to
that already available for activities. (Backend, UI, backup/restore.)
In order that this feature does not reduce performance, section cacheing has
also been added using a new course 'sectioncache' field analagous to modinfo.
The new feature integrates with activity availability so that activities
inside sections which are not available are automatically not available
themselves (meaning it works to restrict access).
1. This used to use a complex legacy system which was buggy.
2. It now relies on a new mod/...:addinstance capability for each module.
3. All the legacy code has been stripped out.
4. Old restriction data is upgraded by creating the necessary permission
overrides. Similarly, when old backups are restored, the old settings
are converted to be overrides.
5. The required addinstance capabilities will be added as a separate
commit.
6. There is a developer debug warning about modules that are missing the
addinstance capability, unless they are MOD_ARCHETYPE_SYSTEM mods.
