CiviCRM Community Forums (archive)

I am with Eileen - I think the default script rule should be email + first name + l last name.  Plus add the "new individual" profile as a default on new events and donation pages.   I may be biased, but I  think the situation of 2 people sharing an email is pretty common.     

I see value in having the two types - I think of them as 'front-end' and 'back-end' rules so perhaps something that denotes the difference between the fact that 'strict' are basically used by people on the outsite of the system and fussy  by people on the inside would make more sense.

I agree the shared e-mail issue is demographic related - we mostly hit it in families but I imagine that it is also common in communities where there are limited internet resources (which would probably be a geographic thing). Having said that I am not aware of any organisation that uses events where I would find e-mail only adequate. Events seem to be particularly prone to people signing other people up in many and varied ways and giving their e-mail both for themselves and other people they sign up (not necessarily using the multiple participants feature). I'm not sure I would see huge value in specifying a rule per event / profile / contrib but others might.

Regarding the first name / last name on the billing screen. I would tackle this by putting the first-name/ last-name/email profile as the top of page profile & putting in javascript to autofill the billing based on this profile - either automatically or - like Ubercart does - give the option to select 'my billing details are the same as my details' or similar - this would presumably copy address details in as well

Dave - I think the 3.2 navigation buttons are really useful & well laid out

 

A really simple tweak that might help some of us who are suffering early onset - would be at least a warning notice on the Import Wizard to 'check your dedupe rules before starting the import' , or even better a checkbox to confirm that 'yes i have checked my settings in DeDupe before I commence my import" (and probably a nice message at the end to suggest that you may need to change them back again!

Asking to approve the whatever without providing infos about the whatever is very much the microsoft way (eg. for the EULA, the security pop up, wizards... you end up with users that are trained monkeys that know that they should click on "yes" -or "next"-, even so they don't have a f**king clue of what the question is, nor what their answer means.

Just went back from Guatemala and Mexico, saw a lot of monkeys in the jungle. Let's leave them there and not in front of the keyboard using civicrm.

Unfortunately I doubt I am the only one to forget to check if the strict dedupe default has been reset by someone else, or worse not even checked by me, before firing off an import.

And I'm willing to bet that you won't check more, just that you will train yourself to check whatever box or ignore whatever message.

As for the dedupe rules and duplicate, my experience is completely different than Brian's: virtually each of the contact has a different email, and duplicates are a big issue that takes them a lot of time to fix.

X+

P.S. Trying to gauge if we can get community support. How much work would it be to:
1) add the list of potential dedupe rules (with the default/strict being selected) on the import
2) apply this rule instead of the strict/default one
3) same goes for profile (that should cover all the other use cases, eg. online event registration/donation...

There is the potential that the same profile will be used in multiple registrations (name and address) but each registration would prefer its own dedupe rule (a bit more general IMO)

That's already an issue today with the boolean on the profiles, what happens if you have two profiles, one asking to match existing contacts, the other that doesn't ?

Wouldn't it be simplier/cheaper (for the profile) to convert the boolean into an int, if null no dedupe applied (like the boolean today) if a value use that rule ?

Same goes for the import,  instead of having an option "update/skip/create dupe" offering the option to choose the dedupe rule.

ie. no new table, altering  civicrm_uf_group to have an int update_dupe foreign civicrm_dedupe_rule null instead of a boolean is_update_dupe. Modifying the ui/wizard on the import to add the choice of rule and no impact on the DB, as import jobs aren't stored anyway (I think)

X+

P.S. Trying to get funding for that isn't going to be easy, as it's an issue that isn't a concern for the users (that aren't aware of dedupe rules in the first place) and given the length of this discussion, not a trivial one to explain, let alone convince it needs their funding to fix.

The other tweak that would be advantageous if remotely possible would be as well as the update/fill/skip - only update or fill for records where a match is made, do not import and create new contacts if no match is made.

Maybe an extra checkbox - Do not create new records. Update or fill only on matched contacts.

As per Dave's request:

http://civicrm.org/blogs/xavier/how-civicrm-avoid-creating-duplicates-and-suggestions-improvements