the service web could return something like:
<User xmlns:xsd="http://www.w3.org/2001/XMLSchema" ...>
<Login>jerome</Login>
<Email>jerome@moodle.com</Email>
...
</User>

the function get_users could return:

• an associative array: array("login" => "jerome", "email" => "jerome@mouneyrac.com");
• a user object, but I'm not sure that we got a user class in Moodle

Let me know what you decide that I update the technical specification.
Thanks.

First of all, I'm sorry for this delay in this forum.
In the webservices specification we have defined return as a list of objects (list of user).
This is the easy return way for this kind of data, but if you need something like an associative array we can implement a functionality to do it or convert this object at "posteriori"

/**

• Returns an user
• Returns user record with optional fields set (Moodle 1.8 and later)
• and maybe some fields filtered out (password, email if user said
• not to disclose it ...) depending of the identity of the "caller"
• (admin or the user himself)
• @private ?
• @param string $field Possible values:
• <ul>
• <li>id</li>
• <li>idnumber</li>
• <li>login</li>
• <li>email</li>
• </ul>
• @param string $value
• @return array User record from database
  */
  function get_user($field, $values){
  }

/**

• Returns an array of users
• Returns user records with optional fields set (Moodle 1.8 and later)
• and maybe some fields filtered out (password, email if user said
• not to disclose it ...) depending of the identity of the "caller"
• (admin or the user himself)
• @param string $field Possible values:
• <ul>
• <li>id</li>
• <li>idnumber</li>
• <li>login</li>
• <li>email</li>
• </ul>
• @param array $values
• @uses get_user
• @return array Array of user records
  */
  function get_users($field, $values){
  }

Ok, picture must be an URL. For instance, what's up with password hash?

I think password should never be returned.

A md5 hash can be cracked by brute force, so this hash should stay in Moodle internals for ever.

Same situation, although less severe with user's email. If site policy (or user will) is not to disclose them, they should be filtered out .

Custom profile fields are more tricky to return, since there actual key name in the returned associative array will be dependent of the Moodle site, so the corresponding WSDL complex type ( for SOAP clients) must be generated "on the fly" ... We reach here the limitation of SOAP where tools such as wsdl2java, wsdl2python,wsdl2php ... relie on a clean WSDL description to generate client's classes and must be "rerun", and clients recompiled, if the WSDL changes. I don't know how this is managed in XML-RPC, REST or others ...

Cheers.

http://tracker.moodle.org/browse/MDL-13127

http://cvs.moodle.org/contrib/patches/dfws/webservice/apis/user.lib.php?revision=1.6&view=markup

The name of the function is:

array mdl_user_delete_instances (criteria, users)

For the moment, function returns an array of user objects. user objects is not as long as using get_record and return only some necessary fields:

-id
-auth
-username
-idnumber
-deleted
-firstname
-lastname
-email
-institution
-department
-address
-city
-country
-lang
-lastaccess
-url
-description

I think this information is enough to show a "character sheet" in any application, but I will add photo support tomorrow, returning a url of the image as Martin says (http://tracker.moodle.org/browse/MDL-12887?focusedCommentId=51667#action_51667)