[3.7.1]Webservice core_user_get_users does not return 'Email'

[3.7.1]Webservice core_user_get_users does not return 'Email'

by Richard van Iwaarden -
Number of replies: 9
Picture of Particularly helpful Moodlers

We are currently experiencing that webservice core_user_get_users not returns the Email address from the user.

I have checked the permissions for the webservice-user and it has permissions to see full user details.

We should get this:

General structure

object {
users list of ( 
object {
id int   //ID of the user
username string  Optional //The username
firstname string  Optional //The first name(s) of the user
lastname string  Optional //The family name of the user
fullname string   //The fullname of the user
email string  Optional //An email address - allow email as root@localhost
address string  Optional //Postal address
phone1 string  Optional //Phone 1
phone2 string  Optional //Phone 2
icq string  Optional //icq number
skype string  Optional //skype id
yahoo string  Optional //yahoo id
aim string  Optional //aim id
msn string  Optional //msn number
department string  Optional //department
institution string  Optional //institution
idnumber string  Optional //An arbitrary ID code number perhaps from the institution
interests string  Optional //user interests (separated by commas)
firstaccess int  Optional //first access to the site (0 if never)
lastaccess int  Optional //last access to the site (0 if never)
auth string  Optional //Auth plugins include manual, ldap, etc
suspended int  Optional //Suspend user account, either false to enable user login or true to disable it
confirmed int  Optional //Active user: 1 if confirmed, 0 otherwise
lang string  Optional //Language code such as "en", must exist on server
calendartype string  Optional //Calendar type such as "gregorian", must exist on server
theme string  Optional //Theme name such as "standard", must exist on server
timezone string  Optional //Timezone code such as Australia/Perth, or 99 for default
mailformat int  Optional //Mail format code is 0 for plain text, 1 for HTML etc
description string  Optional //User profile description
descriptionformat int  Optional //int format (1 = HTML, 0 = MOODLE, 2 = PLAIN or 4 = MARKDOWN)
city string  Optional //Home city of the user
url string  Optional //URL of the user
country string  Optional //Home country code of the user, such as AU or CZ
profileimageurlsmall string   //User image profile URL - small version
profileimageurl string   //User image profile URL - big version
customfields  Optional //User custom fields (also known as user profile fields)
list of ( 
object {
type string   //The type of the custom field - text field, checkbox...
value string   //The value of the custom field
name string   //The name of the custom field
shortname string   //The shortname of the custom field - to be able to build the field class in the code
} 
)preferences  Optional //Users preferences
list of ( 
object {
name string   //The name of the preferences
value string   //The value of the preference
} 
)} 
)warnings  Optional //list of warnings
list of ( 
  //warning
object {
item string  Optional //always set to 'key'
itemid int  Optional //faulty key name
warningcode string   //the warning code can be used by the client app to implement specific behaviour
message string   //untranslated english message to explain the warning
} 
)} 
But what we are getting is this:

{
    "users": [
        {
            "id": 4708,
            "username": "xxxxxx@xxx.com",
            "firstname": "Firstname",
            "lastname": "Lastname",
            "fullname": "Firstname Lastname",
            "department": "Informatie Processen en Systemen",
            "idnumber": "546735674367",
            "firstaccess": 1519653876,
            "lastaccess": 1579690555,
            "auth": "saml2",
            "suspended": false,
            "confirmed": true,
            "lang": "en",
            "theme": "",
            "timezone": "99",
            "mailformat": 1,
            "description": "",
            "descriptionformat": 1,
            "profileimageurlsmall": "xxxxxxxx/user/icon/fordson/f2?rev=1940784",
            "profileimageurl": "xxxxxxxxxxxxxxx/user/icon/fordson/f1?rev=1940784"
        }
    ],
    "warnings": []
}

Email address seems to be missing? 

And yes, this user has an Email address in his profile.... which is the same as the login (maybe that's the problem?)

Average of ratings: -
In reply to Richard van Iwaarden

Re: [3.7.1]Webservice core_user_get_users does not return 'Email'

by Andreas Grabs -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Translators

Hi Richard,

the webservice needs the capability "moodle/user:viewhiddendetails" in addition to the documented capabilities.

Best regards
Andreas

In reply to Andreas Grabs

Re: [3.7.1]Webservice core_user_get_users does not return 'Email'

by Richard van Iwaarden -
Picture of Particularly helpful Moodlers

The user that we are using has system admin rights. I just checked and it has the moodle/user:viewhiddendetails capabilities.

Could it has something to do with roles? Would it be so that you can not get the Email address from an admin account?

In reply to Richard van Iwaarden

Re: [3.7.1]Webservice core_user_get_users does not return 'Email'

by Andreas Grabs -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Translators

Hi Richard,

I dived a little deeper and found that this function is a little weird.

If you have your capabilities system wide like an admin, which it is in your case, then you won't get the email address at all.
If you have less rights like a trainer you might get the email address depending on your capabilities in the course the user you ask for is enrolled in. Maybe I am wrong in my interpretation wink.

So my recommendation is: Use another function like "core_user_get_users_by_field" which is, in my point of view, much more convenient. We use this function in some projects without such problem.

Best regards
Andreas

In reply to Andreas Grabs

Re: [3.7.1]Webservice core_user_get_users does not return 'Email'

by Richard van Iwaarden -
Picture of Particularly helpful Moodlers

Thanks Andreas, this will help us a lot.

Should we report this as a bug? Can you explain al little better what's wrong with the code, as I'm not a programmer...


In reply to Andreas Grabs

Re: [3.7.1]Webservice core_user_get_users does not return 'Email'

by Richard van Iwaarden -
Picture of Particularly helpful Moodlers

Hi Andreas,

The webservice core_user_get_users_by_field has exactly the same problems.

We can see a difference when we use manual accounts or SAML2 accounts. SAML2 accounts never seem to work, the mail address is not being returned at all.


In reply to Richard van Iwaarden

Re: [3.7.1]Webservice core_user_get_users does not return 'Email'

by Andreas Grabs -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Translators

Hi Richard,

yes, you are right. Both function use the same function "user_get_user_details_courses" to get the user details.

Sorry, for that.

Best regards
Andreas

In reply to Andreas Grabs

Re: [3.7.1]Webservice core_user_get_users does not return 'Email'

by Richard van Iwaarden -
Picture of Particularly helpful Moodlers

Found it out!


This web service respects the 'maildisplay' settings from users. If set to '2' (allow only course members to see my Email) it will never be returned by the web service.

In my opinion is this very bad BTW. The setting should not be respected, it is not possible now to administrate accounts using a web service. For example: users that change their mail address, we can not update them with web services.

Should I report this as a bug?
In reply to Richard van Iwaarden

Re: [3.7.1]Webservice core_user_get_users does not return 'Email'

by Andreas Grabs -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Translators
Hi Richard,

thank you! That must be the reason we never had a problem with that.

Best regards
Andreas