This just deletes all the upgrade steps previous to 3.0.0. Some
small adjustments, like adding missing MOODLE_INTERNAL or tweaking
globals can also be applied when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2015111600 (v3.0.0) as anti-cheating measure.
Next commit will get rid of/deprecate all the upgradelib functions
not used anymore in codebase.
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.
It shoudl be possible to link multiple OAuth2 sources which have the
same e-mail address to an account.
This patch makes the check for an existing linked account stricter so
that it only checks for linked account records which match the same
issuer, and which do not have expired confirmation tokens.
As a result of fixing the auth plugins config storage in MDL-12689, many
settings would be falsely reported as new ones by
admin/upgradesettings.php. We do not want to confuse admins so we try to
reduce the bewilderment by pre-populating the config_plugins table with
default values. This should be done only for disabled auth methods. The
enabled methods have their settings already stored, so reporting actual
new settings for them is valid.
It has never been guaranteed that settings.php would always be included
from inside the core\plugininfo\auth::load_settings() scope only.
Alternative fix would be to use $plugininfo->name but I think it is
better to be explicit here (same as we are explicit with setting names,
strings etc).
Auth plugins with custom signup forms may not be using renderables / renderers - or
even if they are they may return a renderable that can only be rendered with the renderer from the auth
plugin.
This change checks if the signup form is a renderable - if so try the plugin renderer or fall back on the general renderer.
Otherwise call display() from the mform which is the previous way of rendering an mform.
Significant string changes:
* errorinvalidbyhour,core_calendar - correcting number from 59 to 23
* cron_help,core_admin - updated recommendation to run cron every minute
* tour1_content_end, tour1_content_welcome, tour2_content_end,
tour2_content_welcome all in tool_usertours - removing reference to
3.2
* invalidsesskey,core_error and invalidsesskey,mod_wiki - more
understandable error message
* pluginname_help and pluginnamesummary in qtype_essay - explaining that
the question type can be used for file uploads
* formatnoinline, mustattach and mustrequire in qtype_essay - changing
the word 'inline' to 'online'
Some auth plugins used to have a mix of the legacy style of plugin names
in config_plugins table (such as 'auth/mnet') and the new correct
style (such as 'auth_mnet'). Attempting to rename the setting plugin via
low level SQL UPDATE could lead to duplicate key violation.
The patch introduces a new helper function to safely migrate the old
settings to the new ones, eventually informing the admin about the
values mismatch.
* 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
The login domains were checking the email of the moodle account, not the returned
email from oauth. Also after a failure, it was not killing the oauth session, which
prevents you trying again with a different account.
The username passed to the confirm account link request is the oauth username,
which may be different to the moodle username so can't be used to look up the user record.
This was broken by the refactoring to always link logins. Some of the static
variables could also be removed but I'll do that in a later issue to keep this patch small.
