Both classes using cURL features now access it via the core curl wrapper
class. Credit goes to Dan Poltawski for spotting the previous discrepancy
during the integration review.
Previously, the testable validator's get_plugintype_location() used to
return path to a directory that itself did not need to be writable. This
was causing false failures. This patch reimplements the testable
validator's get_plugintype_location() method so that it returns a path
inside $CFG->tempdir which is always writable.
Also, to make all test methods consistent, all of them now use the
testable_tool_installaddon_validator class. Before this patch, some test
methods used the testable class and some used the parent class.
The badges feature allows to integrate Mozilla "Open Badges" to issue, assign,
manage and display digital badges in Moodle. This feature supports:
-- badge creation and issuing based on criteria
-- badge baking and verification service
-- direct pushing of internal badges to external backpack
-- interanl and external badge display in Moodle
-- Moodle block to display latest badges
If the user selects a plugin in Moodle plugins directory to be installed
into their site, Moodle plugins directory will redirect them into their
site's admin/index.php script, providing the installaddonrequest
parameter.
This patch makes sure that only if the user is logged-in as the admin
and the site is fully installed and up-to-date, the add-on installation
request will be dispatched to the tool_installaddon for actual
processing.
We need to store the installaddonrequest value in the $PAGE's URL so
that is is stored in $SESSION->wantsurl in case the user needs to log in
at their site. Thanks to this, the request is dispatched after the user
logs in.
There is a new hook in the index.php file. If valid HTTP parameter
installaddonrequest is detected, the installer asks the administrator to
confirm the request.
If confirmed, the installer calls download.moodle.org/api/1.2/pluginfo.php
service to get information about the given plugin version. The essential
data are the URL of the ZIP to download and the MD5 hash of the ZIP.
These data must be fetched via HTTPS to protect against MiM attack.
If the ZIP is downloaded and the MD5 content hash is correct, the user
is redirected to the previously implemented ZIP validation page, as if
the ZIP was uploaded manually.
The valid format of the installaddonrequest is documented via the
test_decode_remote_request() unit test method.
* added new config option to determine length of courses returned by import
* added text indicator if there are more than X number of courses, similar to how the restore course list currently works
The script validate.php expects a ZIP file stored in a temporary
location. It extracts the ZIP (optionally renaming the root directory)
and executes the validator. Then it renders the validator log messages
and continue buttons.
