Two modes of visibility checking are supported, depending on the value
of the 'messagingallusers' site setting (site-wide messaging):
- If site-wide messaging is enabled, a user may only be returned in
search results if the searching user can view their profile somewhere
(either the site profile or any course profile).
- If site-wide messaging is disabled, a user may only be returned in
search results if the searching user shares a course with them and can
view their course profile in the shared course.
This had a relatively simply check for course profile visibility, which
meant that users in separate groups could see one another's profile.
This has been replaced with the more correct check in
user_can_view_profile().
* External authentication mechanisms (e.g. via oauth2, etc.) don't store
password in the user table, so we shouldn't be requiring password in
such case when creating users via the core_user_create_users WS
function.
Default setting value for new instances is 0
Default setting value for existing instances is 1
to get same search results than before this setting exists
Setting messagingallusers = 1 for behat tests to simulate old versions functionality
Followup: MDL-63911
Add new messaging profile preferences to allow users to choose who
can message them:
- By default, users can select between 'My contacts only' and 'My
contacts and anyone in my courses'
- When $CFG->messagingallusers is enabled, a new option is displayed
also: 'Anyone on the site'. For users who have selected this option,
if $CFG->messagingallusers is disabled, the behaviour will be changed
to 'My contacts and anyone in my courses'
A new optional parameter $context has been added to the
core_group::groups_get_members_join() function.
Besides, some core_group methods now accept -1 (USERSWITHOUTHGROUP) for
the groupid field.
Thanks to MDL-49398, we can separate the combined user session and role
definition cache clearing function into two separate functions. At the
same time, we want to identify and remove mark_dirty() calls that were
added for role definition changes but were incorrectly left behind.
Change highlights:
- Remove unnecessary mark_dirty() calls performed after
assign_capability(), unassign_capability(), delete_role(),
deleted contexts, brand new contexts
- Move role definition cache clear from the user-centric
accesslib_clear_all_caches() to the newly created,
role-dedicated accesslib_reset_role_cache()
The core API function user_create_user() did not check the case when the
given username was empty.
Also adding a missing string 'usernamelowercase' for the existing lower
case check and unit tests.
To be consistent with the web administration UI, we should not allow to
create invalid user records with empty username, lastname or firstname
via the web services.
David Mudrák