CiviCRM Community Forums (archive)

1. You should be able to make the dupe match clause empty (i.e. have no first / last name / email) and it should work (in which case its supposed to not do any dupe matching)

2. If the above fails, can u please reproduce on demo, and file an issue

3. Alternatively, u can hack the code at: CRM/Core/BAO/UFGroup.php:

   public static function findContact( &$params, $id = null, $flatten = false )

and return null for that function in all cases (thats what item 1 on this list is supposed to do)

lobo

hey chris:

did not recognize the user name

so drupal should not allow the same email for two accounts? I'm not sure how you are getting around that issue (or if it just fails to catch that scenario), but CiviCRM synchronizes with drupal using the email address, and hence it is triggering the error below. So to some extent it is a valid error

Not sure if we can get around this issue, its quite core to how we sync. So the solution is: don't create two drupal accounts with the same email address (its invalid anyway).

lobo

I can see why CiviCRM uses emails to try and identify potential matches, but don't yet see why a non-unique identifier is used for UF lookups when the Drupal/Joomla ID should do. Maybe I'll understand once I've dug a little deeper.

(FX: digging sounds)

It seems (from a look around the Drupal site), Drupal doesn't technically *require* unique email addresses per user account; address uniqueness is only validated during the registration phase, and an administrator is able to create or import multiple accounts per email address. You can happily create multiple accounts per address using user_save() as I did above.

Joomla meanwhile, has a configuration option for unique email accounts per user ($mosConfig_uniqueemail in 1.0), which is on by default but not required. (Checked on current version 1.0, can't find the same setting in 1.5.)

So ... my question is, if Drupal and Joomla don't actually require unique emails per account, should I be looking at getting a fix in that removes this requirement from CiviCRM, or using a workaround?

For a workaround, I could provide internal-only email addresses that alias to the first "real" CiviCRM email detail for these members who duplicate the address. That's OK - I can just create a fake domain like "@members.my.org", then create a DB lookup alias table that aliases MEMBERID@members.my.org => result of DB lookup (if anything), and bounces when they don't have a working email.

Then any secondary user using the same email will have their Drupal account point to a unique alias, and their CiviCRM data can list the correct member email. That ought to work around it.

Thanks for the tips, Lobo & Dave. I have a couple of options to consider.

CiviCRM tries to match a drupal/joomla user to an existing contact in your CRM db via the email address before it creates a new contact.

Agreed. However as email addresses are non-unique, and we have a user database with a large number of family members. Trying to match them is a good thing, I agree, but I think that requiring they be unique is a limitation (which I'm prepared to put some energy into resolving, and would prefer to do this in a way that benefits all CiviCRM users rather than making a workaround just for us).

It looks like we may have 10 - 20% of our members with a shared email account - lots of family memberships I guess, combined with some repeat registrations which would be useful to identify (easier done once we've imported the contact DB into CiviCRM). We also have several hundred users who lack any email contact whatsoever, and they need to be handled nicely too.

So not sure how drupal/joomla operate in the above scenario to find an user account by email and/or email a missing password. We were not aware that multiple users could share the same email address. However in this day and age, email addresses are cheap , so not sure if we should really encourage sharing?

Emails are cheap, but it's my job to work with the data as it exists, not to suggest several hundred members sign up for gMail because I couldn't find a way to deal with them sharing an address ... after all, matching surnames and phone numbers aren't stopping me from getting the data in

Joomla 1.0 allows multiple emails if you configure the site that way; in 1.5 this is no longer an option (an imposed restriction on user migrations). J1.5 is still in beta, of course.

I dont think the fix to CiviCRM will be trivial. I'll think a bit about this over the next few days, but we dont have a whole lot of information to match between a drupal user record and a civicrm contact record. A unique email is so so nice and convenient Your workaround seems a bit too complex and might not be worth it? Another option is to avoid creating a drupal user account for folks who share the same email address (or just create it for the first person on the list). Do u need a drupal account for everyone?

Yes, our current plan is to have a Drupal user and CiviCRM contact for each member. That way they can log into the site and adjust their own user preferences.

I agree that unique emails are convenient, but they are not always guaranteed.

Matching emails may indeed pose a problem when resetting passwords, but that problem is outside CiviCRM's domain. CiviCRM doesn't handle that so it's up to Drupal/Joomla to handle that sensibly. Another means of resetting passwords is for the administrator to do it via the GUI (extra workload, but also how a good portion of our password resets are currently done).

I understand that, given the limited amount of other user info in Drupal/Joomla by default, emails are an obvious first check to find a matching user. I don't think it follows that we should tie the email address to the UF match, and therefore make it impossible to create multiple UF matches if their email addresses match.

Hope I'm not rocking the boat too much, Lobo! Keen to chat via Skype or gTalk/AIM/etc if you have thoughts about this and want to, my username is the same all the world around.

dlobo and I discussed this in the IRC channel:

I and the rest of the Code for Change team have implemented a standalone (no CMS required) version of CiviCRM and an OpenID login system to go with it. However, OpenID doesn't always provide a valid email address back to the system requesting authentication, and we don't want to require one.

So dlobo and I talked about doing something like this: create a cms_identifier field in civicrm_contact that can have a UF-defined unique string in it. For OpenID systems (Drupal 6 & Standalone), this would be the OpenID url (which is the "username" more or less for OpenID) or it could be the email address for another UF. Or all UFs could just use uf_username.site_domain in there, which would basically be an OpenID.

That last option would get around the non-unique email address problem since the usernames have to be unique across a domain anyway.