Author Topic: Duplicate contact created on event registration (Read 3048 times)

pbarmak · January 12, 2011, 10:06:01 am

This seems to be new to me, as of our 3.3.1/.2 upgrade. We have our events set with "Allow multiple registrations from the same email address?" checked so that we can allow multiple family members to use the same email to register for an event. There is a note there that says:
"In order to allow multiple registrations with the same email address, the default "Fuzzy" Dedupe Rule will be used to check for matching contact records and prevent duplicate registrations. This rule currently uses the following fields: First Name,Last Name,Email. First and Last Name will be used to check for matches among the multiple participants being registered."

So, the rule uses Email, First and Last name. Well, when we go in and register for the same event (or a new event) using the exact same information (exact same Email, First, and Last name) as an existing contact, the system does NOT see this as a duplicate contact and register the existing contact. Instead, it creates a brand new contact and registers that one. So we end up with duplicate contacts.

When I run the "Find and Merge duplicate contacts", using either the Fuzzy or Strict rule (our Strict rule includes all three fields - we changed that to allow this exact scenario), it finds all the dupes created by the registration and I can merge them. So, the matching is working there, but not during registration.

What is the issue here? Is there an open bug for this somewhere (I couldn't find one)? Seems like the dupe checking is not working at all.

It's a major concern for us as we have the same person register for multiple events using the same info quite often (they go on different trips). So we're seeing 5-6 duplicate contacts show up with the same info, a huge mess to clean up.

pbarmak · January 12, 2011, 03:33:18 pm

Digging down further, it seems the real issue is that the system is creating a duplicate contact on the first registration, which messes up the dedupping on subsequent registrations.

For example, let's say I have a contact that was created on the admin side with the following info:
ID: 1
First Name: Paul
Last Name: Barmak
Email: none@none.com

Then I want to register the same contact using Profiles (not logged into Civi). When I register the contact, using the same First, Last, and Email as above, Civi does the usual check for duplicate contacts and finds Contact ID 1 (I debugged this and printed $contactID from CRM/Event/Form/Registration/Register.php, line 1184).

However, instead of using that Contact ID to register the participant, it goes ahead and creates a NEW contact and puts the registration under that contact. This is what is confusing me - why doesn't it put the registration under the correct contact? It used to (prior to 3.3.2).

Of course, the big problem is, now we have 2 contacts - ID=1 and ID=2. So when the same person registers again, the code looks for a dupe and finds ID=1 and only ID=1 because, for some reason, it doesn't care to loop through the list of dupes, only uses the first (also weird to me). But ID=1 is not a participant, so the system assumes this is a new participant and tries to register it - and, of course, it creates another NEW contact to do so! So the cycle repeats.

If I merge the two duplicates prior to trying another registration, then the dupe check works as expected - it finds the single user, sees that it has already registered, and "errors" out providing the proper "oops" message. But that only happens if we're quick enough to merge duplicates before another registration occurs.

So I'm seeing 2 problems here - creation of a new contact on registration and then not checking more than the first returned duplicate ID on subsequent registrations.

Has anyone else been seeing this type of thing?

Can some one point me to the code that actually creates the user during registration? I don't see it in Register.php, maybe in Confirm.php?

pbarmak · January 12, 2011, 04:04:53 pm

Well, I think I found the bug - I'd love for a Civi Guru to double-check this before I create a Jira for it. I did a diff of the Confirm.php page with an older version I had (I think the version was just 3.3.1). It looks like 3.3.2 of Confirm.php is missing a key block of dupe checking code, and that is what causes a new contact record to be created instead of updating the existing one. When I switch to using the old code, everything works as expected.

Here is the diff - again, I'd love to know if this is an existing issue or if I should file a bug ... maybe I'll just do that and you all can close it if it's not the real problem.

Code: [Select]

diff Confirm.php ~/backups/civicrm/CRM/Event/Form/Registration/Confirm.php
994c994,1018
<             $contactID = CRM_Contact_BAO_Contact::createProfileContact( $params, $fields, null, $addToGroups );
---
>             // when we have allow_same_participant_emails = 1
>             // don't take email address in dedupe params - CRM-4886
>             // here we are making dedupe weak - so to make dedupe
>             // more effective please update individual 'Strict' rule.
>             $allowSameEmailAddress = CRM_Utils_Array::value( 'allow_same_participant_emails', $this->_values['event'] );
>             require_once 'CRM/Dedupe/Finder.php';
>             //suppress "email-Primary" when allow_same_participant_emails = 1
>             if ( $allowSameEmailAddress && 
>                  ( $email = CRM_Utils_Array::value( 'email-Primary', $params ) ) &&
>                  ( CRM_Utils_Array::value( 'registered_by_id', $params ) ) ) {
>                 //skip dedupe check only for additional participants
>                 unset($params['email-Primary']);
>             }
>             $dedupeParams = CRM_Dedupe_Finder::formatParams($params, 'Individual');
>             // disable permission based on cache since event registration is public page/feature.
>             $dedupeParams['check_permission'] = false;
>             $ids = CRM_Dedupe_Finder::dupesByParams($dedupeParams, 'Individual');
>             
>             // if we find more than one contact, use the first one
>             $contact_id  = $ids[0];
>             if ( isset( $email ) ) {
>                 $params['email-Primary'] = $email;
>             }
>             
>             $contactID =& CRM_Contact_BAO_Contact::createProfileContact( $params, $fields, $contact_id, $addToGroups );

Kurund Jalmi · January 13, 2011, 01:51:46 am

For tracking purpose: http://issues.civicrm.org/jira/browse/CRM-7377

Kurund

kathkeating · August 19, 2011, 10:57:35 am

this issue is still happening in 4.0.4 for me. Even though the ticket says it was fixed in v 3.3.3. Anyone else still having this problem>

I'm randomly either getting a duplicate record (it's not honoring the match) OR it's overwriting the person's record who is making the registration EVEN THOUGH we've selected the "register a different person" setting.

saint android · September 12, 2011, 10:45:29 am

I'm getting this error as well in my installation (3.3.2), but I'm not sure where to drop the code found above. Can someone help me with this?

Kurund Jalmi · September 13, 2011, 06:51:15 am

I would recommend upgrade to latest stable release. If it is not an option, you can get the fix from
https://fisheye2.atlassian.com/changelog/CiviCRM?cs=31830
https://fisheye2.atlassian.com/changelog/CiviCRM?cs=31831

HTh
Kurund

CiviCRM Community Forums (archive)

News:

Author Topic: Duplicate contact created on event registration (Read 3048 times)

pbarmak

Duplicate contact created on event registration

pbarmak

Re: Duplicate contact created on event registration

pbarmak

Re: Duplicate contact created on event registration

Kurund Jalmi

Re: Duplicate contact created on event registration

kathkeating

Re: Duplicate contact created on event registration

saint android

Re: Duplicate contact created on event registration

Kurund Jalmi

Re: Duplicate contact created on event registration