The patch allows for strings welcomeback and welcometosite to be
customised and use other user names than just the firstname.
Supported are placeholder properties matching all known name fields:
firstnamephonetic, lastnamephonetic, middlename, alternatename,
firstname and lastname. Special values fullname and alternativefullname
are supported, too.
By default, the firstname is kept for compatibility with the original
feature design.
The method allows to check if the user is fully ready to use the site or
whether there is an action (such as filling the missing profile field,
changing password or agreeing to the site policy) needed.
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).
When editing a user and checking the 'Delete picture' checkbox to delete
the old picture and uploading a new one at a time, the new one didn't appear
in the user profile. This happened due to the 'if/else' statement
in the 'core_user::update_picture()' method which allowed either to delete
the old picture or to upload a new one.
The fix removes the 'else' part of the 'if/else' statement to force
checking for a new uploaded picture no matter if a user checked
the 'Delete picture' checkbox or not.
This chagne adds support for a new feature known as Context Locking.
This allows a context to be locked, thereby removing all write
capabilities for all users (including admin) for that context, and all
child contexts.
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.
Implements core_user::search function which can search through the
names (and, if allowed, other identity fields) of all users visible
to the current logged-in user, within a course context or globally.
Authentication has a hard coded list of valid internal user fields - but they are in a class variable. We need them
in oauth user_field_mapping so we need to move them to a central place and call them from oauth2 and auth.
New accounts and linking a login to an existing account MUST go through email verification.
We cannot trust the emails we get from oauth providers have been confirmed.
Part of MDL-58220
useredit_update_picture as moved to user_update_picture
as it's more general. It was also moved to user/lib.php
so it can be used by both webservices and edit without more include files.
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)
Also the get_property_definition() was created to get the property without retrieve the whole definition cache and
unit tests were created to tests those new methods.
With fake noreply and support users, the notifications were not accessible by user
Support for viewing messages from noreply user has been added.
Signed-off-by: Rajesh Taneja <rajesh@moodle.com>
This is used by messaging system for sending/receiving message
to/from noreply or support user. message_send api will now use
core_user class to get noreply or support user and then
send/receive message depending on user state.
