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).
Presently it is either unreliable, or not possible to change
the username of a user created with an authentication plugin.
In some cases it is even hard coded to fail. Ideally we would
sync the username, and the issue MDL-21928 exists to address
that. However, in the mean time we should not allow the
username of an external user to be modified.
Previously if the date field was not enabled it would
be treated as having value 0. A bug would allow this 0
to pass through and save the date as 1 January 1970
The validation of the timezone field should not occur, especially
when it is automatically cleaned. Timezones can be volatile, we
must try hard to fallback on real timezones and must not lose reset
the values arbitrarily.
"There is absolutely no need to change $CFG->timezone and user timezones
in database - the timezones may come and go. If you change the value in
upgrade or on the fly you would not be able to get it back. This is the
reason why I implemented the "invalid timezone" thing in server and
user settings instead." - Petr Skoda (MDL-49684)
This commit replace as much as possible of clean_param and PARAM_ usages related to user object.
Also few unit tests has been changed to match the new validation
The new validation were added to user_create_user and user_update_user,
displaying debug message if some invalid data has been found.
Also the unit tests of those methods has been changed to match the methods behaviour.
Fix:
$PAGE->context must be reset when calling validate_context
Improve:
Provide wrapper for calling an external function
The wrapper correctly checks the function parameters and return type against
the description of the external function, and stores the PAGE and COURSE global
state variables, restoring them before the function returns.
Fix: buggy unit tests.
These tests are expecting debugging from a bug that was fixed, and calling web
service functions with no user or session.
1. Participants are sorted by last access and they could
be different on different db's. So sort them by last name
before checking.
2. Use Give-When-Then steps.
This change prevents from registering and/or saving the profile of a
user with the whitespace instead of the required name.
Additionally, there is accessibility improvement for better error labels
in case of missing values (copied over from signup_form).
Eloy Lafuente (stronk7)