- Define sitepolicy handler manager class, base class and the core handler
- Allow to set a plugin as sitepolicyhandler that implements the sitepolicy API
- Modify web services to return information from the 3rd party handler instead of core if needed
The patch introduces a new site setting 'sitepolicyhandler' that can be
either empty or contain a plugin component name. If it is empty, the
site policy feature keeps working as before and the core keeps the
control over it.
If a plugin is specified, it is expected to implement the callback
'site_policy_handler' in its lib.php file. The callback should return a
URL to a script where the user can accept the site policies. The plugin
itself is responsible for setting the 'policyagreed' flag in the users
table. The callback may return an empty value, in which case the user
can continue using the site without being redirected.
The patch adds support for a new pre-config flag NO_SITEPOLICY_CHECK.
This constant should be defined and set to true if we should not check
the user's policyagreed status during the require_login().
This is for pages where the user actually accepts the site policies and
helps to avoid the redirect loop.
Starting with Moodle 3.5 the XMLDB->PATH attribute is checked
to be correct and pointing to the correct plugin directory.
It only was used for writing PHP savepoints code, but better we
ask for strict correctness.
With this patch applied, neither the XMLDB Editor neither install
will be able to load a file with wrong PATH anymore.
The patch increases the maximum supported precision (total number of
digits) for numeric (decimal) fields to 38 digits (current limit on
Oracle and MSSQL).
Additionally, we add our own limit for the whole number part of numeric
fields so they are no longer than integer fields (20 digits). This is to
make it easier to eventually convert from one field type to another.
Note that PHP floats commonly support precision of roughly 15 digits
anyway.
The google_oauth class extends oauth2client which was modified to send "Accept" headers.
The "Accept" headers break picasa and could break any other plugin that was using google_oauth.
While the lack of the filename in curl POST does not
directly affect Moodle, some external API's expect to get
the filename of the original file, which affects plugins
using the CURL class.
* New optional parameter 'closeSuggestionsOnSelect' for the enhance()
function for form-autocomplete. Setting this to true will close the
suggestions popup immediately after an option has been selected. If not
specified, it defaults to true for single-select elements and false
for multiple-select elements.
Part of MDL-59290.
* New optional parameter $enrolid for the following functions:
- get_enrolled_join()
- get_enrolled_sql()
- get_enrolled_with_capabilities_join()
Setting this parameter to a non-zero value will add a condition
to the query such that only users that were enrolled with this
enrolment method will be returned.
Part of MDL-59290.
All these functions were used only by deleted upgrade steps
so it's safe to proceed with straight deletion, considering
them internal. Deletion has been documented in corresponding
upgrade.txt files:
- upgrade_mimetypes()
- upgrade_fix_missing_root_folders_draft()
- upgrade_minmaxgrade() and upgrade_minmaxgradestepignored setting
- upgrade_course_tags()
- atto_equation_update_librarygroup4_setting()
- mod_lti_upgrade_custom_separator()
These have been kept because continue being used by restore:
- upgrade_group_members_only()
- upgrade_extra_credit_weightoverride()
- upgrade_calculated_grade_items()
This patch introduces support for an optional method provided by the
form element classes to validate the submitted values implicitly -
without the need to have the rule explicitly added via the form
definition.
I am aware this should ideally be added to the HTML_QuickForm_element
parent class. But I wanted to avoid modification of that third party
library and keep the change in the moodleform layer only.
The core_group_get_activity_allowed_groups WS should be returning not
only the groups but also if the user is allowed to access all the
activity groups.
This change removes the complex and partial loading of role definition data for users.
It is replaced by keeping one system-wide definition for each role in MUC.
This is cheaper to regenerate as it avoids complex database queries (repeated LEFT JOIN to context).
Memory usage is kept low thanks to array CoW for each user access data.
While ldap_get_entries_moodle() PHPdocs state that it returns "array
ldap-entries with lower-cased attributes as indexes.", this is not true. It
uses ldap_get_attributes() internally, which returns both numerically indexed
attribute names, and dictionary-like entries indexed by attribute names.
Current code lowercases the dictionary-like entries, but then uses the
numerically indexed entries for the attribute names used as keys in the
returned array. The numerically indexed names might or might not be lowercased,
depending on the LDAP server and PHP version) version. E.g., OpenLDAP 2.x,
Novell eDirectory 8.x and MS Active Directory return mixed-cased attribute
names, and PHP 5.x and PHP 7.x don't lowercase them inside ldap_get_entries().
This is probably why all calls to ldap_get_entries_moodle() are followed by
calls to array_change_key_case(), even if that shouldn't be necessary.
So make sure we always return lower-cased attributs as indexes and add some
unit tests to avoid regressions in the future.
This includes:
- Changing PHPUnit's bootstrap to use https://www...
- Modify all existing expectations to the new wwwroot.
- Amend some tests now with different defaults because of is_https()
- Added a note to main upgrade.php about the change.
* get_identity_providers(): Retrieves available auth identity providers
* prepare_identity_providers_for_output(): Prepares auth identity
provider data for output (e.g. to templates, WS, etc)
* Use these helpers for the login renderer
This introduces a new "controlled link" file type where the file is not
stored in Moodle - but Moodle will control the access permissions on the file.
Plugins can "freeze" a filearea which means Moodle will take ownership of all the remote
files of this type.
When accessing a file, if the "filebrowser" infomation indicates the current user can write to the file, they
will be granted temporary write access.
Part of MDL-58220
