Some email body strings use first names as greetings,
some use full names, and some do not.
Using the first name for greeting makes it consistent and
a bit more "personal".
* Make sure that we respect the fullnamedisplay and alternativefullnameformat
parameters to decide on the initials for a given user
* Add further tests
Co-authored-by: Tatsunori Uchino <tats.u@live.jp>
New functions:
* `core_user::get_profile_picture` for retrieving user picture.
* `core_user::get_profile_url` for retrieving profile url.
* `core_user::get_fullname` for retrieving user full name.
Note: the context is not used as this stage. It will be used by "User Disguises" plugin, which will be implemented later.
The "Start page" user preferences page has been reviewed to
consider the new $CFG->enabledashboard setting.
The "Dashboard" won't be displayed in the list if it's disabled.
Besides, the default value is now calculated calling the new
get_default_home_page() method.
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)
Marina Glancy