One of the most important things about any database is the integrity of its data. Is it possible that you could be overriding existing contact information with incorrect information?
One of the many hats I wear at BackOffice Thinking is helping the CiviCRM team reach out to the CiviCRM user community and invite them to share their stories in the CiviCRM Community Newsletter. During one of my conversations with Radoslav Minkov (IT Manager, CEPS), a future newsletter contributor, I found out that even though he is extremely happy with the CiviMail functionality, he was getting so frustrated with the Events/Registration functionality that he disabled this module from his installation.
His issue is one that affects many of our clients. The issue is that when an administrator registers a person for an event, if the email entered has a match in the CiviCRM database, the new information will override any existing information in the CiviCRM database.
Since I am not a developer nor a coder, I like Heather Oliver's approach (Community Highlight person for CiviCRM August Newsletter) to using the User Interface as much as possible. Our recommendation is to change the Rule in the Dedupe Profile (something that can be changed in the User Interface by an administrator) where the system will check for email, last name and first 3 letters of the first name.
In order to change the apropriate Dedupe Rule, In CiviCRM 4.3 and later this is called the Individual "Unsupervised Rule" and in 4.2 and earlier versions is it the Individual Default "Strict Rule". follow these steps (in CiviCRM 4.2.6):
- Go to Contacts/Find and Merge Duplicate Contacts
- Create a new Rule for Individuals
- Name: We suggest creating a name that describes the rule
- level: Strict (for 4.3 - "Unsupervised")
- Under fields, add Email (weight=10); add Last Name (weight=10); add First Name (Length=3, weight=10)
- Set the Theshold at 30
- Save
This works 95%+ of the time and the trade-off is that there might be some duplicate contacts that will need to be cleaned up on a regular basis. However, we've found that most of our clients prefer this behavior.
For those of you that code, there is an extension for you too: https://civicrm.org/
Comments
Good points. I agree and think the default unsupervised (strict) rule is, frankly, dangerous and all sites should re-evaluate their duplicate matching rules. I have some additions and thoughts to add. This is very similar to the dedupe rules I use normally, but I set the weights differently.
Why?
1. Because a contact will score email points (10) for EACH email match and a contact can have more than one email ... 3 identical emails alone on the contact will result in a score of 30. A more common senario would be two identical emails and a same last name, resulting in an inappropriate match on a family member. This is rare, but a contact with 2 or more identical emails (of different type or the same type!) can happen in a mature database. Therefore I set the threshold to 15 and the weights to: email 4, lastname: 5 first name: 6. A small tweak but occasionally and important one. Pete Davis taught me this.
2. No-overwrite is a great extension but under the radar and not chosen for inclusion in core, for reasons I don't understand. But nonetheless thank you to Xavier for taking my hacky jQuery and turning it into an extension.
3. When you set the default strict (or unsupervised rule) to use names and email remember it will affect your User Registration and the uf_match table, as this rule is used when a user is made to match to an existing contact. If you do NOT have first name and last name included in a profile with Drupal User Registration setting you will get no uf_matches like you'd hope.
Stoob,
I think we need to discuss no-overwrite for core. I'm not sure what the reservations are about it but I don't think that solution for a problem that affects most users should be an extension. If no overwrite is not the right solutions we should talk futher about what is.
Eileen
Hi,
I'm not sure I understand Lynn's comment that noverwrite is "for those that code". Installing an extension is meant to be simple and very much "for those that don't code" too. Did you experience any difficulty installing it?
If it's harder to have it working as an extension that having it in the core, shouldn't we focus on solving this problem instead of work around it by moving the feature in the core?
Otherwise, not sure I subscribe to the line of thought "If it's useful for the majority, should be in the core". I don't want the extension to be the dumping ground of whatever is deemed not worthwhile of being able to be included in the core ;) I'm not sure about the other CMSes, but drupal needs a dozen "extensions" to be usable and for my customers, installing a bunch of civi extensions is part of the default install and I don't see it as a failure of the core.
As for the promotion of extensions, not sure how to make them more visible, may be adding a "extension of the month" in the newsletter? Or having a bunch in the community making nice comments about extensions they like? (I love you too ;)
We plan to make visible how many times an extension has been installed, might be good to add stars to the extensions too?
X+
P.S. Stoob, I moved the function from jquery to php (most of it) so it should be more robust, even for those disabling js
I agree that not all extensions should go into core but I do think that the most popular ones should find their way there over time. This does happen in the Drupal World as well (cck and views).
I guess this is something that will start to happen 'naturally' as we live with extensions for a while.
I pretty much do subscribe to this - the strength of CiviCRM has always been that it works out of the box. I don't think drupal is a good model for an alternative as it barely works out of the box - but has an incredibly robust underlying infrastructure & underlying changes almost never cause modules to break (a major release every couple of years). CiviCRM schema changes every release & although we try to maintain stability via the api we are struggling to do that.
So, I understand extensions are great for bits & pieces but I don't think they can replace getting generally useful stuff into core. How annoying if you install an extension & then find that it is not supported for you next release because someone has renamed a function in core & the extension maintainer isn't particularly fussed because they have an every second release policy.
I think at this stage, its pretty hard to distinguish what the majority is and how we want to define majority? Is it 50%+ of the user base or 50%+ of folks who use the feature fairly heavily.
I do agree, that some simple obvious things should be in core, no questions asked. but for more and more of them, its getting to the stage where, should this really be in core?
lobo
Should this (speaking generally of any new feature) be in core? A fair question. In the overwrite case, I can't think of a single user of Event or Contribute that uses public forms that hasn't had a staff person over-write their data at least once - not to mention the public's use of forms too. I think people who don't deal directly with users as much as I do may underestimate the overwrite problem. Since you mention percentages, in my experience it's 100%. How high does a percentage have to be to be useful enough to be in core? ;-)
I don't deal with users enough to know what proportion it is. I am aware of several sites that have experienced problems with it with fairly severe impacts on them
Stoob, thanks for your feedback and for the no-overwrite extension.
Xavier, the focus of this blog was to make end users aware that by changing a few settings in the User Interface, it is possible to avoid the problem of overwriting existing contact information without the need to install/download anything. Since I come from a non-technical background, it is my preference to change things in the UI rather than installing files, as long as the result is the same. I am always going to blog from a non-techie perspective; I think often these blogs get too techie for many users and sometimes can be intimidating or can give the impression that you need to be technical to get CiviCRM working effectively. :)
I can’t claim that I’ve ever tried installing an extension, so I don’t personally know whether the installation is complicated or not. However, if I was a user (again, I’m not technical and just thinking about it from a business perspective), I would worry whether the installation of the extension would be compatible with my existing installation, and whether the extension installation might create unanticipated behaviors (especially in highly customized installations).
I didn’t mean to put down the functionality of extensions. I’m sorry if it came across that way! I think extensions are very valuable, especially when the functionality doesn’t exist through the UI, when it’s a new installation or upgrade, and when you have the help of a consulting firm in case there is a need to correct behaviors that change due to downloading the extension.
You bring up a good point about the question of promoting extensions. For the Nov. newsletter, we are going to highlight different ways that users can find answers when a feature doesn’t do what they expected, or they need any type of help (i.e. forums, extensions, list of service providers, …). If you are interested in writing a quick blurb about extensions (and maybe how nontechies shouldn’t fear them), email me (lwupagano@backofficethinking.com) and we can add it in the newsletter. I liked your ideas about including # times and extension has been downloaded and rating it with stars.