If there is a required custom field that the user can fill by editing
their profile, and that field is missing, the user should be considered
as not fully set up. Instead, we want to redirect them to edit their
profile first.
There are some exceptions when we want to fall back to the previous
behaviour and check just the name and email fields. These exceptional
cases include checking remote user data in incoming MNet request (no
user id, no custom fields supported) and calls to require_login() with
redirecting disabled (typically ajax filepicker requests on profile
editing page itself).
Additional plugins that call the function user_not_fully_set_up()
themselves, should perform the strict check in most/typical cases. So
the strict mode is enabled by default even if it changes the behaviour
slightly. In improbable case of additional plugins relying on the
previous behaviour of the function, they can use the $strict parameter
and keep performing the lax check. However, I am sure the correct fix in
that case will likely be to stop abusing this function.
Note that custom fields are not currently transferred during the MNet
roaming. So having custom fields configured as required on MNet service
provider site (where users can't edit their profiles) is expected to
display an error (as the site is considered as misconfigured).
PHP has a recursion limit and random_bytes on PHP5.6 without openssl
will error if sent a large value. Using a loop has lower overhead than
recursion as well.
Repositories can now override usespost() if they don't upload using POST
requests. This restores the ability of users with
moodle/course:ignorefilesizelimits to upload files of unlimited size
lost in MDL-44626.
Even when a user has the appropriate capability to upload any sized files,
they are still restricted to the PHP post_max_size, and upload_max_filesize
values.
Rather than showing a value of "Unlimited', we should always restrict to
this value.
When $CFG->divertallemailsto is specified, this allows a list of email
or domain exceptions to be whitelisted enabling easier testing by groups
of testers who don't share a single email address.
The support for Advanced PHP Debugger was dropped in Moodle 2.2
(MDL-29881). This seems to be a forgotten relic no longer used and
needed in moodlelib.
The 'completion enabled' flag does not reflect any course data, its a
course setting. Previously when doing a backup deleteting existing
course content this was forced off when it should not have been.
Simey Lameze