CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site
This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Using CiviCRM »
  • Using CiviContribute (Moderator: Donald Lobo) »
  • In Honor of
Pages: 1 [2]

Author Topic: In Honor of  (Read 5370 times)

Donald Lobo

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 15963
  • Karma: 470
    • CiviCRM site
  • CiviCRM version: 4.2+
  • CMS version: Drupal 7, Joomla 2.5+
  • MySQL version: 5.5.x
  • PHP version: 5.4.x
Re: In Honor of
April 26, 2008, 01:48:28 am

the dedupe rules currently are enforced only within contacts of the same type. hence it is hard to match your specs with the current system

i'm not sure how we can solve that issue in a easy manner. hopefully in 2.1 we'll unify dedupe and contact matching rules and make them extensible / adaptable via an API / hook. Check: http://wiki.civicrm.org/confluence/display/CRM/Dedupe+Changes+for+CiviCRM+2.1 for details

lobo
A new CiviCRM Q&A resource needs YOUR help to get started. Visit our StackExchange proposed site, sign up and vote on 5 questions

jeff porter

  • I post occasionally
  • **
  • Posts: 72
  • Karma: 2
Re: In Honor of
April 26, 2008, 06:55:04 am
Thanks. I will look at the specs.  What do you think of the possibility of creating a series of duplicate match rules? So that we could define Last Name and Household Name as equivalents across the contact records?   

And, a perspective only, but I think this should only be done on inserts and edits.  I think the best way to minimize dups is to prevent them from happening in the first place and should simplify burden on the system when you look for dups across the entire db. I know that many bulk load contacts. We do the same, but I dedup them in excel before I import.  You can find excellent formulas for finding dups in an excel list on this site: http://www.cpearson.com/excel/Duplicates.aspx.
Jeff Porter
Foundation for Prader-Willi Research (www.fpwr.org)

Donald Lobo

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 15963
  • Karma: 470
    • CiviCRM site
  • CiviCRM version: 4.2+
  • CMS version: Drupal 7, Joomla 2.5+
  • MySQL version: 5.5.x
  • PHP version: 5.4.x
Re: In Honor of
April 26, 2008, 12:40:34 pm

Our goal in 2.1 is to build a scalable de-dupe and combine the dedupe / contact duplicate rules.

The below extension of definining equivalency between last name and household name is potentially an extension for a future 2.x release. Please do add your comments and requests on the wiki page

We will give folks both options. A dedupe rule to use for operations like edit/insert/online transactions etc (could be a more constrained rule) and rules for fuzzy matching across the entire db.

Note that many a time dupes are created during an online transaction / profile creation, so doing a dedupe there might not be a realistic option

lobo



A new CiviCRM Q&A resource needs YOUR help to get started. Visit our StackExchange proposed site, sign up and vote on 5 questions

jeff porter

  • I post occasionally
  • **
  • Posts: 72
  • Karma: 2
Re: In Honor of
August 30, 2008, 10:15:48 am
Quote
I just skimmed through the code and there is logic in there to detect and reuse a contact if it already exists. If you can reproduce this on the demo server, we will fix it in 2.1

the code is in: CRM/Contribute/BAO/Contribution.php, function createHonorContact (line 614)

lobo

Lobo - sorry to bring this one up again, but wanted to ask some advice on how we can eliminate this problem.  We tightened down the duplicate matching rules on our instance of CiviCRM down to email only so that we don't get a lot of dups for family members that are honorees (just had a situation where a person's mother died and people donated in her honor).  This eliminates the situation where we have Fred Claus and Santa Claus both the same email and different names, but it now creates a problem where Santa Claus' name is updated/overwritten by the name "Fred Claus". 

I suspect the best logic would be to hack the code on our server to not over-write contact fields during a contribution.  Instead, we would rather have the system follow a business rule that a user can ONLY change their contact information by going through profile forms, so that we better know their intent (e.g. If they register for an event or create a contribution and slightly change their name - perhaps we NOTE it to them that they have entered data that doesn't match and encourage them to update their record, but don't do it for them)

Does that make any sense?

Jeff

Jeff Porter
Foundation for Prader-Willi Research (www.fpwr.org)

greenmachine

  • I post occasionally
  • **
  • Posts: 58
  • Karma: 6
Re: In Honor of
April 28, 2009, 06:01:45 pm
OK, this is an old thread but it was what I found when trying to figure out this issue.

I encountered a problem with CiviCRM 2.0 whereby using the in honor of fields always created a duplicate contact - they did not match properly to existing contacts in the database. The duplicate matching rule was set only to e-mail.

It looks to me that findContact(), or more importantly getWhereClause() in CRM/Core/BAO/UFGroup.php doesn't properly process the e-mail param when passed like this:

$params['email-Primary'] = emaildata;

Changing the variable being passed to findContact() to the following does work:

$params['email'] = emaildata;

So I am going to modify createHonorContact to pass along the param using the "email" key instead of the "email-Primary" key.

$*@#* Drupal 5/Drupal 6 menu code incompatibility has me stuck fixing bugs on 2.0 instead of upgrading. Sigh.
Pages: 1 [2]
  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Using CiviCRM »
  • Using CiviContribute (Moderator: Donald Lobo) »
  • In Honor of

This forum was archived on 2017-11-26.