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

CommentFileSizeAuthor
#17 user_service_save.407726.patch2.51 KBfp
#15 407726.patch2.82 KBgdd
#13 407726.patch3.11 KBgdd

Comments

gdd’s picture

Status: Active » Closed (won't fix)

The 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.

benthroop’s picture

I 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.

gdd’s picture

Category: support » bug
Status: Closed (won't fix) » Active

Wow that is really weird, one of us should take a look soon, that should definitely be caught.

benthroop’s picture

I 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.

gdd’s picture

So 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.

primouomo’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev

I encountered this problem too. Is it going to be fixed?

marcingy’s picture

Priority: Normal » Critical

Raising 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.

Paintbox’s picture

Subscribing.

giorgio79’s picture

Subs

Paintbox’s picture

Sorry 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.)

syakely’s picture

I 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()

<?php
// $Id$
/**
 * @file
 * Service Calls used by xxxxx
 */
function xxxxx_service() {
  return array(
   //Check if user or email exists
    array(
      '#method'   => 'xxxxxx.usercheck',
      '#callback' => 'user_check',
      '#args' => array(
      array(
        '#name'        => 'User Name',
        '#type'        => 'string',
        '#description' => t('new username')),
        array(
          '#name'           => 'User Email',
          '#type'           => 'string',
          '#description'    => t('new user email'))),
      '#return' => 'array'
    ),

  );
}

function user_check($username_in, $email_in) {
  //Check UserName
  if ($error = user_validate_name($username_in)) {
    return array(error => TRUE, message => $error);
  }
  else if (db_result(db_query("SELECT COUNT(*) FROM {users} WHERE LOWER(name) = LOWER('%s')", $username_in)) > 0) {
    return array(error => TRUE, message => t('The name '. $username_in .' is already taken.'));
  }
  else if (drupal_is_denied('user', $username_in)) {
    return array(error => TRUE, message => t('The name '. $username_in .' has been denied access.'));
  }
  //Check email
  else if ($error = user_validate_mail($email_in)) {
    return array(error => TRUE, message => t('The e-mail address '. $email_in .'is not valid.'));
  }
  else if (db_result(db_query("SELECT COUNT(*) FROM {users} WHERE LOWER(mail) = LOWER('%s')", $email_in)) > 0) {
    return array(error => TRUE, message => t('The e-mail address '. $email_in .' already exists'));
  }
  else {
    return array(error => FALSE, message => 'no error');
  }
}

gdd’s picture

I 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.

gdd’s picture

Status: Active » Needs review
StatusFileSize
new3.11 KB

Attached 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.

Hugo Wetterberg’s picture

Ok, 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?

gdd’s picture

StatusFileSize
new2.82 KB

Here 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.

abhaga’s picture

Hi,

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

fp’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new2.51 KB

I'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.

abhaga’s picture

In 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

gdd’s picture

This has been committed, thanks all.

This review is powered by Dreditor.

gdd’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.