set_user_preference and unset_user_preference let you pass the user to
set preferences for as an id. Previously, if you passed $USER->id there,
those methods did not update the Cache in $USER, which was surprising,
and not easy to debug.
Now, we always update the preference cache in $USER if the preference is
being changed for the current user.
If there is an empty required custom user profile field, Web Services
should return the usernotfullysetup exception instead ignoring it.
The mobile app already handles this exception for core fields
redirecting the user to web in order to fill the missing field.
The patch adds validation for the noreplyaddress setting variable, for
the explicit $replyto parameter and for the sender's email. In case of
misconfigured noreplyaddress setting, it falls back to the default
noreply address value. In case of invalid email in the user's record,
the email is not sent.
The patch also adds unit test for the value returned by the function
generate_email_processing_address() so that it can be considered as a
valid email, too.
This is supposed to significantly minimise the risk of exploiting the
vulnerability in PHPMailer's Sender field.
Removing the check in login/token.php is secure since the
auth_forcepasswordchange is checked in require_login that is called via
validate_context.
The user must be able to get a token even if that setting is on. With
that token we’ll redirect the user to the site or we’ll change the
password when a new WS for that is available.
We din't call it SSO because:
- SSO usually requires a 3rd party for authentication
- SSO term is already used in tool_mobile when supporting using auth methods like CAS or Shibboleth
This is:
a) To help avoid devs going on a wild goose chase to find a perf issue
when it's caused by css building
b) To make it clearer that this should never be enabled on production
sites (we already have a warning in the performance report, but who
looks at that)
Now that boost is the default theme and builds css itself, it's more
critical.
- New site setting to define the default course duration (used to set
the default end date for some course formats)
- End date setting out of restore
- Fix tool_uploadcourse
- Other fixes here and there
This commit includes a change in moodlelib to throw the
sitepolicynotagreed exception in a way that can be captured and
identified by external systems.
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).
Use core functions that are faster for test file creation.
To support large requests for hashes, the core hash function
must support large hashes without recursion. PHP has a default
recursion depth of 100 and long hashes don't support this.
Remove transactions as they create performance problems for larger
courses and doesn't introduce significant benefit for developers.
Performance changes meant the times were much faster, a reasonable
guess was taken on performance of an average machine.
Dan Poltawski