It seems to be better to check for required permission later, when the
button to install the update is actually being displayed. Credit goes to
Dan Poltawski for suggesting this.
If the stored response has still 1.0 version (which is expected during
the upgrade to 2.4), a debugging message is displayed. Added a string to
explain what's going on and how to recover from the state.
This class represents the communication bridge from Moodle UI to the
(standalone) mdeploy.php utility. It consists of various helper methods
useful when dealing with user interface, update confirmation etc.
The class is implemented as a singleton. This allows us easily
transfer required data from top level scripts (like /admin/index.php)
into the rendering methods deep in the stack without the need to change
the API of many methods on the way.
The Notifications (admin/index.php) page has now information about
available updates for core and eventually plugins, too. Note that the
structure of the available updates array changed. This breaks backward
compatibility for eventual 3rd renderers out there (not expected
though).
- Course format may define additional fields (format options) to store for course and each section
- Edit course form allows to edit format-specific options and refreshes their list on format change
- Course format may provide it's own form for editing a section
- Default form for editing section allows to edit all format-specific fields
- Class section_info refactored, it defines magic methods such as __get() to access basic section
information and format-specific options (retrieved only on the first request)
- format_base::update_course_format_options() allows to watch pre-update state of the course,
format_legacy automatically copies the options with the same names between formats
* Added a bit of AMOS to copy existing strings and save a little translation effort
* Cleaned up fixed strings in several places
* Cleaned up some existing strings as required.
* Fixed install and upgrade code. Split upgrade into two parts (one for each table).
* Fixed fatal error caused by missing forms lib inclusion
* Added param types to forms.
* Converted file_get_content to use curl for URL's.
* Cleaned things up per coding style.
* Separated subscription management and form into separate files.
* Tidied up bennu inclusion to just where required.
* Lots of other small fixes as well.
AMOS BEGIN
CPY [calendar,calendar],[colcalendar,calendar]
CPY [actions,moodle],[actions,calendar]
CPY [never,moodle],[never,calendar]
AMOS END
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.
