1. get_context_name should respect the $CFG->courselistshortnames
setting.
2. When $CFG->courselistshortnames is on, what to display should use a
language string, rather than string concatenation. This makes it
possible for people to configure the display. For example, they might
want 'My first course [M101]' instead of 'M101 My first course'.
(also triggering an amos script here for the other MDL-34650 commit)
AMOS BEGIN
CPY [minute,form],[minute,core]
CPY [month,form],[month,core]
CPY [options,editor],[options,core]
CPY [selectacourse,backup],[selectacourse,core]
AMOS END
- when loading core_filepicker we extend the Node element with functions necessary to display files list in different view modes;
- repository/filepicker.js is changed to use those functions;
- FileManager now has three different view modes (icon view, tree view and table view), JS code is re-used from FilePicker;
- files in FileManager no longer have context menu, they have one popup Widget with different actions instead;
- Added more templates for JS code to FileManager, use similar CSS class names as FilePicker;
- lib/filelib.php : fixed double slashes in path, return more data about files;
- lib/form/filemanager.php : pass information to FileManager about available licenses and default author;
- repository/draftfiles_ajax.php : return information about directory tree for file moving UI in FileManager, return formatted information;
- repository/lib.php : function repository::prepare_listing() now can work also with draftarea files listing;
These changes fix several points and suggested changes:
* increase the size of the help popup to 800x600
* fix issues with centering of the dialogue
* swap next/cancel buttons
* convert next button to use string for 'Add'
* convert add text to 'Add an activity or resource'
* Change markup way from 'activity module style' to its own markup
* Remove 'a new' from the 'add an activity' string
* Remove the 'personalisation' from the nohelp lang string
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.
Sam Hemelryk