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()
Significant string changes:
* completionpass_help, gradetopassnotset in mod_quiz - grade to pass set
in quiz settings not gradebook
* namecolumnmissing,core_cohort - fixing incorrect message about adding
users to a cohort
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.
The user_selector classes supported custom list of extra identity
fields. But they should obey the configured user policy and respect the
privacy setting made by site administrators. So the list of user
identifiers should never be hard-coded, but the setting
$CFG->showuseridentity should be always respected.
In core we now use a modal to perform these actions. I
initially thought these were kept because they were a fall
back if JS was disabled. However, the functionality is
broken and doesn't work. Since we do not have to support
non-JS anymore these files have simply been removed as well
as relevant strings deprecated.
The preferred language has been added only to the user creation form.
For existing users, you should access to the user profile, click over
Preferences and go to the Preferred language page.
As this is an editor element field, the it is supposed to be PARAM_RAW.
Otherwise it cleans-up certain non-HTML syntax such as Markdown
blockquote characters.
Adds a new callback, <plugin>_control_view_profile. Plugins may
return core_user::VIEWPROFILE_PREVENT to prevent access,
core_user::VIEWPROFILE_DO_NOT_PREVENT to make no change, or
core_user::VIEWPROFILE_FORCE_ALLOW to allow access even when Moodle
would normally prevent it.
This allows third-party plugins to restrict (or allow) access to
profile pages in response to arbitrary business logic.
