CiviCRM Community Forums (archive)

I've got an event that uses a profile to gather information for the attendee (and spouse, however spouse isn't a separate contact, rather a couple of custom fields of the particular contact). While we usually restrict event signup to logged in users, this particular event is public and we need to gather information from anonymous users.
My problem is that, e.g., if an anonymous user happens to use as email address the email address of one of our existing contacts, then any other information provided in the registration will overwrite the corresponding information in the contact record. I've set the advanced setting on the profile to "allow duplicate contacts to be created" upon duplicate match, and the unsupervised dedupe rule for individuals is set so that first, last and email must all match exactly to be considered a duplicate.

I'm not sure what I'm doing wrong, but this is a real issue for us.

I've searched the forums but haven't found this issue. If you have any idea what I need to do to fix this, I'd greatly appreciate your help.

Thanks,
Rick

Wow, that's just blown my mind. My dedupe rule is exactly the one you guessed at the top, and I understand what you say, but I don't understand what "if a record has the same email twice" means.

This might indeed be the problem, but what circumstances would make the email match be counted as two matches?

I'll wait for an answer, but meanwhile I'll switch to the second deduce rule and give this a test...

OK, have tested new rule with both the following alternatives

Setting it as
First 6
Last 7
Email 7
Threshold 20

Setting it as
First 8
Last 8
Email 4
Threshold 20

When I register a person anonymously (not logged in) and use the same email address, then the record for that person is altered by the anonymous signup! However, when I register a person anonymously and use the same first name and last name, but a different email address, then a new contact record is created. Seems that the match rule being applied is :

Setting it as
First 0
Last 0
Email 20
Threshold 20

Only the email address counts, and anonymous registrants can overwrite anything in the profile of a current contact by merely using their email address. Profiles are beginning to worry me!

Thanks for any other thoughts you might have - is it possible that for event registrations using a profile, there is a hard-coded dedupe rule that uses only email address? I really don't mind creating some duplicates and having to dedupe, but having a contact's spouse deleted by a helpful registrant who knows his email address is scary...

Yes Pete, now I understand. That's not the case here, but I now realize it's a danger. I've modified my response above after testing and still have the issue. Seems like in this situation the only thing being checked is the email address, and anonymous registrants can overwrite the info in the profile for anyone whose email address they know...

I guess what I'm looking for is:

Logged in users have a profile filled out with info from their contact record and all that info is LOCKED (I don't want someone to delete their spouse from their contact record just because their spouse isn't coming to this particular event)

Anonymous users cannot register for any user who's currently in the database, which means that anonymous users will in every case create a new contact record. I know that means that I will have a lot of deduping to do but at least I'll know what's going on.

And by the way, in case anyone's wondering why the wife would be a few fields in a contact record, instead of a separate contact, it is because this is a men's golf group, so all the members are male. No sexism intended, just trying to simplify!

OK, I think the system isn't designed to do what I need to have happen:

I'm using the advanced setting:
X Allow Duplicate Contact To Be Created

However, the popup help window (click the question mark) tells me this has no effect, AND that it's not the unsupervised rule, but instead the email match only rule that is invoked. And even though the popup suggests my very issue (anon user modifies current contact info), the suggested solution is to modify the email match rule to make it more strict, but it's a reserved rule and therefore can't be modified! So there's apparently nothing I can do to prevent anon user from modifying my database, if I choose to use a profile that includes email address in it...

"This setting is ignored if the profile is embedded in an online contribution, membership signup or event registration form. In this case a contact match always results in the transaction being linked to the matching contact.
In all cases, the check for an existing matching contact uses the default "Individual Strict Duplicate Matching Rule" (match on email address). If you are concerned with existing contact data being over-written by anonymous visitors, you can modify this rule to make matches less likely (or even impossible). For example, if you NEVER want anonymous input to match (i.e. always create a new contact record) - edit that rule and set the 'weight threshold' higher than 10. You will then need to run Find Duplicates periodically using a different rule, and merge any duplicate records with their associated memberships, contributions, etc."

OK Pete, you're giving me hope!

 But I'm thinking that no matter what unsupervised rule I make (and I already have one that should be very, very restrictive), the sytem is going to use that loosey-goosey email only rule to declare that a new anon user who happens to use an existing email (maybe it's even a typo on his part).

Is there some way to specify what dedupe rule to use??

Rick is correct, in 4.4 the matching for event registration is done on email only.  This has been changed for 4.5 where the unsupervised rule is used by default but another rule can be specified if required.

Issues that relate to this include:
https://issues.civicrm.org/jira/browse/CRM-14134
https://issues.civicrm.org/jira/browse/CRM-14540
https://issues.civicrm.org/jira/browse/CRM-14541

There might be a patch in https://issues.civicrm.org/jira/browse/CRM-14134 that could apply to a 4.4 install ( the one that says DO NOT USE - I think it was superseded by one that includes more functionality rather than because it was defective), but I am not sure,  being a non-techie.

Thanks so much for the clarification - I now understand how complex the problem of keeping the documentation synchronized with the code can be. Most of the documentation of dedupe rules has to do with the process of undoing duplicates. Keeping duplicates from happening is the undocumented use of the rules and they are applied differently in different instances. I'll look at the patch, but for this event perhaps I'll just create some temporary custom fields that can't corrupt the database if they get set incorrectly. Looks like the solution is arriving in 4.5 shortly.

Thanks to you both, Joanne and Pete!