Is this currently possible? If not, wouldn't this be a good feature, or at least a way to check if you are entering a duplicate. Or do I have to write a custom service?
thanks
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | user_service_save.407726.patch | 2.51 KB | fp |
| #15 | 407726.patch | 2.82 KB | gdd |
| #13 | 407726.patch | 3.11 KB | gdd |
Comments
Comment #1
gddThe user.save service simply calls Drupal's user_save() function, and that function checks for email address uniqueness. When this fails services will return an error (although this error is kind of vague.) Generally services try and work simply as passthroughs to core functions, and since this is how core works it is probably how services should work as well.
Comment #2
benthroop commentedI just tested this and unfortunately, when a user is registered through services, email conflicts do not appear to be checked for. I was able to register two users with the same email. When doing so through the normal Drupal web interface, this is caught.
Comment #3
gddWow that is really weird, one of us should take a look soon, that should definitely be caught.
Comment #4
benthroop commentedI thought maybe it was because I was using Login Toboggan , but nope. I will tell you that I'm using AMFPHP and Flex, for what it's worth, along with the March 31 dev version.
Any idea where the email checking function is? I couldn't see anything obvious in user.module but it seems like it should live in there.
Comment #5
gddSo the email address checking is done in _user_edit_validate() in user.module. Unfortunately this is only called when users are registered through the Drupal admin interface (through a hook called by the validate handler.) Services is just calling user_save(), so this is all bypassed. This should be fixed to use drupal_execute() just like the node.save service does.
Comment #6
primouomo commentedI encountered this problem too. Is it going to be fixed?
Comment #7
marcingy commentedRaising priority as it affects all user registration functions eg email. However we should keep the existing user save service and add a new user register service as they exist for different cases. User save should error if a user doesn't currently exist as part of this change.
Comment #8
Paintbox commentedSubscribing.
Comment #9
giorgio79 commentedSubs
Comment #10
Paintbox commentedSorry to bump....but any news on this? (I hope I am not coming accros as rude, as I know this an open-source project, with real people, with real lives behind this :-), so a big thank you for all the work already done.)
Comment #11
syakely commentedI have made a small service call to check for username and email. Maybe it can be added to user services.
It is very basic with no access check, but yet again, all it dose is check for validation and if anyone else is using the username or emails address.
Replace xxxxx with your custom service call module name, and don't forget your .info so you can turn it on. Also remember to edit your key to allow it to use the call.
pretty much taken from _user_edit_validate()
Comment #12
gddI am not a fan of this solution, because it repeats code from core. If this code ever gets patched as part of security or bug fix, we're left out in the cold. I'd rather figure out a way to exploit core's validation, or use drupal_execute() which is how it should really be done. Unfortunately this could very well break existing installations. Am playing with this now and hope to have a patch soon. This has been broken far too long.
Comment #13
gddAttached is a patch that replaces the existing user.save() service with one that uses drupal_execute() and as such acknowledges all validation rules. It should work pretty much exactly the same as the old service, and the code should be 100% compatible. As an added bonus, this service can save user profile information through the addition of a 'category' key to the submitted data. If this means nothing to you don't worry about it.
Would love to see some testing of this patch so we can get it in. I've done some but it's pretty basic.
Thanks all.
Comment #14
Hugo Wetterberg commentedOk, this needs review by some you you guys who were using and were having trouble with the user service in the first place, as a important consideration is whether it breaks current implementations. emosbaugh, benthroop, primouomo & Paintbox are you guys still active and interested in this issue?
Comment #15
gddHere is an updated version of this patch, the previous patch was destroying all but the most basic user settings (like user's default language for instance.) This one preserves that information, as well as other info that modules add in.
Comment #16
abhaga commentedHi,
I am using this patch for creating Drupal users through a python front end and it seems to work fine. Although I am not setting any profile fields etc, just simple name, email and password.
BTW I noticed that you are loading node.pages.inc in the beginning of the function -
// Needed for drupal_execute().
module_load_include('inc', 'node', 'node.pages');
This is not required since user_register is already available by virtue of being present in user.module. Commented that out and still works fine.
Regards,
Abhaya
Comment #17
fp commentedI've tested the patch and it works fine w/ new users and updating existing user accounts and profiles.
As abhaga says in #16, it appears that the
module_load_include('inc', 'node', 'node.pages');is not needed.Comment #18
abhaga commentedIn order to successfully create a new user, the logged in user needs both the "Create New User" permission in user_service module and also the "Administer Users" permission from the user module.
I figured this out after wasting close to an hour wondering why my service is giving a 302 error.
abhaga
Comment #19
gddThis has been committed, thanks all.
This review is powered by Dreditor.
Comment #20
gdd