With previous commit some lang strings became unused. As far as they
are not reusable we are deleting them plain and straight. This is the
list of strings, for reference:
- orphanedquestionscategory
- orphanedquestionscategoryinfo
- oauth2upgrade_message_small
- oauth2upgrade_message_subject
- oauth2upgrade_message_content
- apiv1migration_message_small
- apiv1migration_message_subject
- apiv1migration_message_content
- security_key_notice_message_small
- security_key_notice_message_subject
- security_key_notice_message_content
- pendingupgrades_message_small
- pendingupgrades_message_subject
- pendingupgrades_message_content
Three additional checks have been added.
Once grades have been recorded for the activity/grade item -
1) Do not allow the grade type to be changed.
2) Do not allow the scale to be changed.
3) If we are using ratings do not allow the 'Maximum points'
value to be changed.
Also reordered form elements, removed form elements that
were not necessary, added and changed existing language
strings to improve the overall UI.
Changed the messaging API to allow you to provide a parameter
that will cause the code to check if the sender of the message
has the correct permissions before the message is sent.
The ajax messaging (message button on profile page) has been
updated to perform these permission checks. This brings it
inline with the existing private message page.
AMOS BEGIN
REM [interestslist_help,moodle] Commas are no longer required
REM [entertags,tag] Commas are no longer required
REM [othertags,tag] Commas are no longer required
AMOS END
Only change from 2.9 is the modification of the slasharguments
admin setting string to recommend always to keep the setting enabled
and fix the problem in the server, warning about the drawbacks
of disabling it.
Also, there is a little phpdoc note added to one custom check
to have clearly specified when we can get rid of it.
The admin setting updateautodeploy no longer exists. The two existing
config.php flags $CFG->disableupdateautodeploy and
$CFG->disableonclickaddoninstall merged into a single one.
If there is an available archived zip with the version of the plugin
currently installed, we can use it to cancel/abort the upgrade of the
plugin. This is internally handled as the installation of the archived
zip and goes through all the validation and confirmation.
Additionally, some other parts were improved. Most notably, renderer no
longer decides itself if some installation can be cancelled but it
always asks the controller (plugin manager).
The button for installation was moved to the left so there should be
first buttons to add things, and then buttons to cancel things (which is
common in normal forms).
The plugin manager's method install_remote_plugins() has been changed to
install_plugins() and it is now able to install plugins from the
provided list of locally available ZIP files, too. This is used by the
Install plugins admin tool.
The plugins check screen (displayed during core upgrade and/or plugins
upgrade) now supports installation of remote plugins. This includes
installation of missing dependencies (both single and bulk mode) and
installation of available updates (both single and bulk mode).
All the HTTP query parameters supported by admin/index.php are now
explicitly enlisted. Previously, the \core\update\deployer used
its own additional parameters (and was source of some serious problems
in the past).
The implementation uses the plugin manager as the controller and
provides an unified interface for installing any remote plugin or
plugins (be it available update or missing dependency).
As a side effect, we now validate available updates which was not
happening before.
The new method core_plugin_manager::install_remote_plugins() will serve
as a backend for all the ways of installing ZIP packages from the moodle
plugins directory, such as installing new plugins (by clicking the
Install button in the plugins directory), installing available updates
(single and bulk mode) and installing missing dependencies (single and
bulk mode).
The method should be used both for validation pre-check screen and,
after the confirmation, for actual installation. Note that we
intentionally repeat the whole procedure after confirmation. Unzipping
plugins is cheap and fast and the ZIPs themselves are already available
in the \core\update\code_manager's cache.
We will need to add support for archiving existing code to prevent
accidental data-loss.
This basically provides what mdeploy.php was doing, but better. We now
have consistent way of installing all remote ZIP packages, always
validate them and we can perform bulk operations, too.
Previously, the validator was used for installation of the new plugins
only. We now validate every incoming plugin package. As a result, we
must no longer insists on the target location is empty. Instead, warning
is raised.
Provides a bit more compact layout. Finally cleans up the relevant LESS
files and makes available updates info boxes consistent across all
screens where they are displayed.
