Make skipping registration form optional

The module actually does currently do this. If the data needed for registration is available it attempts to use it. Twitter, however, doesn't provide an email address so the module still prompts you for an email address. It does work with facebook if you configure your Gigya.com settings to enable retrieving emails from FB. It probably also works with some of the openID and openAuth services though I haven't tested all of them extensively to find what info they provide. But, in short, if they're able to provide the info, and the user allows the info to be provided, then the module will attempt to automatically register them.

As per azinck's comment, this workflow already is supported for certain services.

Twitter will not provide email. Facebook requires a "special permission" in your FB app settings to provide it.

Actually, the issue is quite the opposite, in my opinion - we should make this feature optional so that the registration form is not skipped unless that is needed. Otherwise, people with existing accounts (in the case of my site, >7000 people), will not have a chance to link them.

Hmmm... I'm not sure I got this right, but I might be missing something that you or Tamir added to the code.

Azinck - How can you setup the module to avoid the registration form? It's true that the module pre-populated the field but skipping is a different issue.

I can confirm that if you have no namespace collision on a user (that is, the user name from Facebook or Twitter is not already taken), and the email address is obtained by the app, then the user registration form gets bypassed.

This should be optional.

The reason this should be optional, at least in my case, is so people can select the proper options for Legal module & CiviCRM group memberships, both of which are also on the user_register form.

It is fine if the rest of the information is pre-populated, but people need to be able to see these other things, for legal reasons.

Also, I've discovered that if you have CiviCRM installed & enabled, the auto-account creation can cause fatal DB errors ("duplicate entry exists") if a given email address is already in the database.

With azinck's help, I have tried to figure out the code in gigya_login_ajax() -- approximately lines 85-109 of gigya.pages.inc -- that handles the pre-population and account creation. However, I have not been able to get it to work. Either it goes all the way through the account creation process, or else the data from Facebook doesn't get pre-populated and added to /socialize-register at all.

For now, I have simply disabled the "special permission" that you can set on Gigya.com to request from Facebook users. But a fix to this issue is, in my opinion, fairly high on the roadmap.

Hey Evan,

I spent some time looking into this. Facebook population works on my setup with the edits you've made as long as you have "Enable Facebook fields population" checked on the Drupal Gigya configuration page. Can you confirm this?

Adding this as an option will be pretty straightforward.

azinck: That was possibly my problem. I'll try to confirm.

Sorry that I couldn't figure this out before. The code cleanup needs to happen soon, but I haven't had the time to devote to it.

azinck:

It was totally the "Enable Facebook fields population" setting. What is weird to me though is why there is a setting for that, whereas the other things pre-populate regardless. Since it was a separate setting, I assumed that pertained only to profile.module settings, not the ["name"] & ["pass"] fields.

So once I re-enabled the "ask for email address" setting on the domain settings at Gigya.com, I was able to get this to pre-populate both username and password.

Then, I changed gigya.pages.inc's gigya_login_ajax function as follows:

// <snip>
// if (form_get_errors()) {
            // Append form validation errors below the above warning.
            $messages = drupal_get_messages('error');
						
						kprint_r($messages);
                       
            $dest = $_REQUEST['destination'];
            unset($_REQUEST['destination']);
            drupal_goto('socialize-register',array('signature'=>$_GET['signature'],'UID'=>$_GET['UID'],'timestamp'=>$_GET['timestamp'],'destination'=>$dest));
        // }
        /* else {
          //save the new user
          $account = user_save('', $form_state['values']); // possibly replace with drupal_process_form('user_register', $form, $form_state) ?
          // Terminate if an error occured during user_save().
          if (!$account) {
            drupal_set_message(t("Error saving user account."), 'error');
            drupal_goto();
          }
          //log in after registration -- maybe this should be an option to turn off/on?
          user_external_login($account);
        } */

It should be fairly easy to create a variable that can be set on admin/settings/gigya. Then the "else" could be turned into an "elseif" and the variable tested against. Then, the "if" probably wouldn't need to be commented out.

The user interface on admin/settings/gigya needs to be redesigned, though, I think, to make this all more clear. I am creating that as a new postponed task: #751806: Redesign admin/settings/gigya page for greater usability.

Thanks, azinck, for your help.

Oh, we should probably postpone this too, since we need to get the branch stabilized first. But this should be fairly high on the roadmap (once I get around to actually working on it). I'll probably have Gigya implemented live on my site before I have time to formulate a roadmap.

There's an extra setting for it because some people consider the practice questionable by the Facebook TOS

Hmm...interesting. Facebook ToS seems very strict. Anyway, we can discuss how to best clarify that on the other issue.

Does this still apply?

I'll be sure to add this feature as I polish content profile support (my current priority)

Please reopen if still relevant.