The external function 'core_user_update_users()' always returned 'null' no matter
if a user or users were successfully updated or there were some failures.
So, there was no way for the caller to know which users were updated and which were not.
After the commit changes the function returns an 'external_warnings' instance. The function uses
a delegated transaction for each user to update within a loop. This enables the function to update
as many users as possible. This differs from the previous behavior of the function when it used
a delegate transaction outside of the loop where the users were updated. This resulted in a rollback
of the whole users updating in case any of the users had some invalid data. For each user within a loop
a 'try-catch' block is used to throw exceptions which are actually returned
as warnings by the function when they are caught.
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
* 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.
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.
- Define sitepolicy handler manager class, base class and the core handler
- Allow to set a plugin as sitepolicyhandler that implements the sitepolicy API
- Modify web services to return information from the 3rd party handler instead of core if needed
Web Services from user and enrol components has been updated to change
the user preference name field type from PARAM_ALPHANUMEXT to
PARAM_RAW.
The old type was not matching the core functionality.
This function was ignoring any capabilities and was only used to
update the preferences, but could be potentially used to update
any user attribute. A new WS function has been introduced to
handle user preferences with the necessary capability checks.
This commit includes a change in moodlelib to throw the
sitepolicynotagreed exception in a way that can be captured and
identified by external systems.
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.
This commit replace as much as possible of clean_param and PARAM_ usages related to user object.
Also few unit tests has been changed to match the new validation
