In MDL-80271, the line `$user->timemodified = time();` was removed to
make sure that `user_update_user()` does not unnecessarily writes to
the database. This seems to have been accidentally put back during
conflict resolution while rebasing the patch for MDL-78427.
In addition to adding in theme usage reports, there is also the
addition of an icon on the theme cards which takes you to the report.
This icon only appears for that theme if it has been used in any
overriding context.
The API was incorrectly assuming that all uses of the API were for a
course, and that the instanceid of the communication instance was a
course id. These assumptions are both entirely wrong.
The API is intended to support a range of uses including use at the
site, user, and activity levels.
Furthermore, if a group were to be used, then the instanceid should be
of that group's id, and therefore the contextid would need to be fetched
or that group's course instead.
The only solution here is to add a new contextid field to the table, and
implement it all parts of the API.
This commit implements the communication api updates
when a user is updated. It handles the room membership
when a user is suspended and deleted.
Originally implemented as MDL-76703.
Co-authored-by: David Woloszyn <david.woloszyn@moodle.com>
Co-Authored-By: Safat Shahin <safat.shahin@moodle.com>
Create a new profile field type, move all existing content of the fields
'icq', 'skype', 'aim', 'yahoo', 'msn' and 'url' in the mdl_user table to
theses new profile fields if needed.
AMOS BEGIN
MOV [aimid,core],[aimid,courseimage,profilefield_social]
MOV [yahooid,core],[yahooid,profilefield_social]
MOV [skypeid,core],[skypeid,profilefield_social]
MOV [icqnumber,core],[icqnumber,profilefield_social]
MOV [msnid,core],[msnid,profilefield_social]
MOV [webpage,core],[webpage,profilefield_social]
AMOS END
This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).
The last access implementation also fixes an existing bug,
where it was assumed never accessed would be 0, when it also needed to
handle null to return correct results. Related userlib unit tests also
updated to reflect this, as well as some incorrect comment wording.
Added new MESSAGE_CONVERSATION_TYPE_SELF type for self-conversations
and upgraded legacy self-conversations to the new type, removing
repeated members in the message_conversation_members table.
Besides, from now, a self-conversation will be created by default for
all the existing users.
All the self-conversations have been also starred and a default message
will be displayed always to explain how to use them.
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().
Purge cache just for the current user to avoid redirection when 2
simultaneous users try to sign up at the same time and some policy
has to be agreed.
The 'createduser' invalidation event has been removed also because
is not used any more.
Thanks John Azinheira for spotting it!
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.
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.
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.
Jun Pataleta