Adds an extra import section alongside the existing export in the
calendar views. Allows the user to import from either a file or a
URL as a subscription, with an optional polling interval of hourly,
daily, weekly, monthly, or annually. This subscription may be added
to the user, group, global or course calendars. These subscriptions
are tracked in a separate database table, and an extra column added
to the events table to relate them to the subscription. The event
uuid field is also expanded to allow for the RFC-2445 UID property.
Subscriptions are listed on the calendar view page, and can be
added and removed, manually polled, and the polling interval
adjusted. Subscription events are updated on cron.
* 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
The combination of repositoryid and reference field is supposed to be a
unique identification of an external file. Because the reference is a
TEXT field, we can't use it to compose the index. So we use the
referencehash instead and the file API is responsible to keep it
up-to-date.
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.
Jonathan Harker