CiviCRM Community Forums (archive)

Hi Guys,
Bit of a general query really, but it seemed to relate to custom coding so I put it here (please feel free to move to a more appropriate forum). I couldn't find this info elsewhere in the forum or in the docs/book.

We run civicrm+drupal.
We have contacts added manually by administrators, as well as web users. When web users sign up to the drupal site, we are using a custom drupal module to add some fields to the registration form corresponding to custom contact fields in CiviCRM (in a similar way to profiles).

To avoid spam, and prove identities etc. we have the user options in drupal set to 'require e-mail verification', so when someone signs up, they receive an authorisation email to check they are who they say they are (or at least own that email address).

Q1: CiviCRM creates a contact for each drupal user at the point of registration, before they have confirmed their email address and logged in for the first time.
If a contact already exists in CiviCRM, and someone signs up to the drupal site with the same email address, does the account get immediately linked?

Q2: What happens if there is more than one contact with this email address?

Q3: What happens if someone fakes a signup with another person's email address? If it gets linked before the user has verified it, then any info put in the profile on the signup page might overwrite the correct info for that contact

Q4: What happens if an administrator manually edits the contact info between signup and first login. Do the profile fields from the signup form overwrite the manually entered data?

Q5: About 25% of our web users that sign up never log-in. We presume this is due to spam, incorrect email addresses and various other reasons. Since CiviCRM creates contacts for them as soon as they register, we end up with a lot of contacts which aren't 'real' contacts, either because their email addresses don't exist or they were spammers. This tends to clog up the database and doesn't give a true account of the number of contacts we are engaging with.
Do other people have this problem?
How do you deal with it?

Q6: As a result of these problems, is there any way I can get Civi to only create the webuser->contact link when the user first logs in? Or disable the auto-linking on registration so that I can link it myself on login with a drupal module?

Does anyone have any other suggestions for how I could sort out this workflow?

Unfortunately our organisation has reporting requirements that means we must collect location information (only on a rough regional basis) from all contacts. The only way to guarantee getting this information is to put it on the registration form, otherwise once logged in you have no way of forcing them to fill it in.
I guess we could have a check that runs on every page load to see if they have filled the data in but this would cause a performance hit, and would be quite annoying for the first time they log-in.

I'd be willing to try compiling a patch, since I am having to code around this issue anyway.

I need a bit more info to understand how it works properly first though...

1) Are you saying that using a profile on the registration form definitely inserts it's data as soon as the contact is created/linked on registration. And that it overwrites what is already there?

2) The code which matches a civicrm user to drupal user in in Core/BAO/UFMatch.php
What happens if there are two civicrm contacts with the same email address as the new drupal user. How does it choose?

3) I'm trying to work out how the hook_user in civicrm.module works. Could it be as simple as changing:

   case 'login':
        require_once 'CRM/Core/BAO/UFMatch.php';
        return CRM_Core_BAO_UFMatch::synchronize( $user, false, 'Drupal',
                                                  civicrm_get_ctype( 'Individual' ), true );
    case 'register':
        $config = CRM_Core_Config::singleton( );
        if ( $config->inCiviCRM ) {
            return;
        }
 
        if ( empty( $_POST ) ) {
            return civicrm_register_data($edit, $user, $category, true, false );
        } else {
            return civicrm_register_data( $edit, $user, $category, false, true );
        }
        break;

to this:

   case 'login':
        $config = CRM_Core_Config::singleton( );
        if ( $config->inCiviCRM ) {
            require_once 'CRM/Core/BAO/UFMatch.php';
            return CRM_Core_BAO_UFMatch::synchronize( $user, false, 'Drupal',
                                                  civicrm_get_ctype( 'Individual' ), true );
        } else {
           //not entirely sure what this if (empty()) does?
           if ( empty( $_POST ) ) {
               return civicrm_register_data($edit, $user, $category, true, false );
           } else {
               return civicrm_register_data( $edit, $user, $category, false, true );
           }
         }
 

    case 'register':
        break;

I'm not entirely sure what the if (empty($_POST)) is for?

4) This would fulfill my requirements, but could there be a legitimate use case where you definitely wanted the contact link/create to happen on registration as it does now? If so, this would need an option in the admin config screens somewhere (or just under an admin page for this drupal module).
If we have the option to change, then when the setting is changes from 'link on login' to 'link on registration' would we need to update everyone who hadn't logged in yet with a sync account?

u'll lose the location info if u dont process it during registration (unless u save it in some other table)

lobo

Isn't it possible to have a hook that is run when user are unblocked ?

In that case, I'd create a hook after the contact creation from the registration, add a tag "unconfirmed", and remove it in the drupal hook when the user is unblocked.

X+

(we are doing something quite similar for the petitions as an option)

HI Graham - your explanations pretty much reflect a post we made many moons ago, particularly your 1) and 2) below . Our clients weren't in a position to contribute anything towards this sort of improvement.

Hi,

I have several use case of willing to register the contact when you create the user:

1) If you have a profile on a membership/event registration with the option to create an account, I definitely want to register the contact and the associated payment in Civicrm, even if the never confirm their account

2) to be able to use civimail to send an email "hey, you haven't confirmed your account"

Another option: create the contact when creating the account, but with the status "deleted", and you "undelete" it when the account is confirmed.

While we are on that region: I'd love to see the source set "account created online" when creating the contact, so you can more easily see where the contact comes from.

X+

might be easier to discuss this on IRC

Unfortunately in D7 the user hook has been broken up into smaller chunks (a good thing), but the code will need to be modified for that release (when it comes out)

lobo

Hi everyone.

I've made some modifications to civicrm.module to try to solve this issue (see attached new version). I added a flag to the user-register form to indicate that it was the source of the registration (rather than an API call or admin screen). Then when the user is created, the contact sync only happens if this flag is not present. I then added a check to the login which syncs the user to CiviCRM if it doesn't already exist. This keeps the existing functionality, but only changes things if the user create route comes via the user/register website form.

I have attached my hacked version in case it helps anyone else in this situation, and in case some of it can be absorbed into the main CiviCRM codebase.

Unfortunately, this version does not save CiviCRM profile data.
On our site I have a custom module which collects extra info much like the profiles system (but with some custom UI that profiles could not provide). My module works using the standard drupal form API by injecting extra fields into the registration form. These become automatically saved in the user object and retreived and synced to CiviCRM on login.

CiviCRM by contrast, uses Quickform to process user registration profile fields. They are added to the user registration form as raw html, and not using the Drupal form API, thus Drupal knows nothing about them and does not save the data in the user object/DB. To get this working, one would have to manually save the profile fields to another table in the DB, and then retrieve them on login.

New suggestion:
Perhaps we are going about this the wrong way.
Since the drupal user registration match uses the 'strict' individual rule, we could modify this rule to never match any contacts and thus 'force' a new user for every contact. You lose some of the automated linking of users->contacts, but this can be performed during regular contact merge/dedupe runs. It also means the profile data won't overwrite anything important.
The main problem for me with this approach is that the contact import, event registration and contribution system all use the 'default' strict rule. We really need imports to match properly against email addresses.

So, it would be really useful to be able to specify seperate strict dedupe rules for website registration, event registration, contribution pages and contact import. I know this has come up before, so would this be a good idea to try to patch this functionality? It would just mean changes to a few admin screens and a couple of extra fields stored wherever the dedupe rules are kept (DB or $config object?)

What do you think of this idea?

Thread summary
Since this has got rather long, I thought I would summarize.

Problem:
Many sites require email verification from website signups to prove identity. Until the user has first logged in, you do not know that they have received the verification email, and are who they say they are. CiviCRM syncs users->contacts on user registration, which means a user could set up an account for an email address they do not own, and it would be linked to CiviCRM, effectively 'stealing' that contact.
If any profile fields are used to collect additional information from the user, these would overwrite the valid entries with whatever the 'fake' user had entered.

Solutions:
It seems there is no 'catch-all' solution to this problem. It is reasonably easy to fix the 'fake' synchronisation problem by just doing the sync on login rather than registration (see attached module).
The complex part is what do do with the profile data.

If there is a long time between registering and logging in, the profile fields may have changed and not save properly.
If there is a long time between registering and logging in, the contacts details may change (say moving address) and then when they login the old out-of date data from registration may overwrite the newer correct data.

The ideal fullproof process seems quite complex:
-website registration
-drupal account created
-submitted civicrm profile saved somewhere
time passes
-user gets email and logs in
-load saved profile.
-Remove fields in stored profile that no longer exist.
-For each field, only update that field in CRM if it hasn't been changed since date of registration. This is the main problem, as we do not have field level change logging in CiviCRM. It also gets quite complex, because we can't update part of an address for example...
-remove saved profile

As you can see, some of this is probably not possible in current CiviCRM. Here is a summary of the various suggestions in this thread for how to approach this issue:

1) Add contacts immediately on registration but as 'deleted'
Good idea, but these contacts may get removed between registration and login using the 'permanent delete' facility. What happens if contact undelete is not turned on? Could they be added as an extra level of 'hidden' which would need an access permission to view? Then how doe sit it interact with all the components, de-dup etc.

2) Add contacts from website signup on login instead of registration (save in Drupal user object) (attached module)
Requires user-registration profiles to use drupal form API. Doesn't handle accounts made with event registrations or contributions

3) Add contacts from website signup on login instead of registration (save to CiviCRM DB)
Requires DB table to store profile fields. Could we serialize the $_POST object and then use quickform to process on login? Can quickform even work this way without a direct submit? Doesn't handle accounts made with event registrations or contributions

4) Modify dedupe rules system to accept different strict rules for import and website registration
Automatic sync lost. New contacts are created for each user so need to run de-dupe every so often.

I would appreciate the thoughts of anyone else with this problem and how they solved it or what approach they would prefer to use? This is starting to drive me slightly crazy!