CiviCRM Community Forums (archive)

Hi,

Just had a long mail about api and dedupe, and one of the issue is that sometimes, civicrm can't know what is the right solution.

One example if that when you have two contacts with the same name (duplicates) and that you need to pick one up automatically, it can't know which one to take. Say that you import John doe with the current employer ACME, but you have two organizations ACME in your database, it can't know if that's the first or the second one.

Right now, it does create a 3rd ACME organization, put it as the employer and don't put any error message.

Among the different options, that's probably the one that is longer to fix (you multiply the number of merges), but it has the benefit of not corrupting any existing data or exposing any information.

I would suggest that at minima when civi is faced to a choice it can't solve automatically, it adds the tag "to be validated" to the contact(s), so that's easier to spot for humans that something needs to be fixed.

As a second rule, avoid to destroy/corrupt/compromise data (that one is already applied).

but otherwise, when that's about adding content vs. modifying it, I'd as a user prefer to add the individual as employee to the oldest acme  instead of creating yet another duplicate.

What do you think ?
X+

Wasn't specifically about the api, eg. for the import as well. (this being said, the import should use the api indeed

Agree, we need to be able to return more info (eg error code, as opposed to error messages on, array of the params in error....).

For calls to api v2, pretty sure we return already a deprecated, but can't see it right now...

X+

Among the different options, that's probably the one that is longer to fix (you multiply the number of merges), but it has the benefit of not corrupting any existing data or exposing any information.

I would suggest that at minima when civi is faced to a choice it can't solve automatically, it adds the tag "to be validated" to the contact(s), so that's easier to spot for humans that something needs to be fixed.

As a second rule, avoid to destroy/corrupt/compromise data (that one is already applied).

but otherwise, when that's about adding content vs. modifying it, I'd as a user prefer to add the individual as employee to the oldest acme  instead of creating yet another duplicate.

In general, i think we should use a sensible default (in this case we do and we dont destroy/corrupt/compromise data), BUT allow the user to override the behavior via a hook.

different users / orgs have different opinions Allowing them to modify what civi does is probably a good path forward.

lobo

I think hooks are evolving and the newer hooks "modify" behavior (which could mean adding or changing current behavior). We've done this pretty nicely with some gift aid related hooks and changed existing behavior.

All the hooks get a chance to modify the behavior. hopefully they behave nicely and dont overwrite each other

lobo

No, I wasn't aware - but good to know! Maybe it should be a RULES event.

I was pondering the fact that we seem to be in a transition from basically all interaction with CiviCRM being through the CiviCRM forms (a while ago now) to one where other forms of interaction are becoming more & more common.

Re the de-dupe behaviour - I'm not sure in what circumstances it takes place so it's hard to comment - I suspect that if there were a site-wide setting that allowed you to also match oldest contact on de-dupe we would set it on most sites we use

xavier can implement the hook to use the first id that is found and tag it at the same time!

Can we please ship Xavier's module with core!

If this is controversial, let's go with hooks, but had an idea.

Background: I find that hooks a clever hack, but a hack, put that in the monkey patching category.
What about using OO and the "hook" is in charge of defining what class to instantiate ?

eg (pseudo codish, the existing classes/functions have likely different names):

the BAO contains
function saveIndividual ($params) {// or whatever that's named

  $dedupeClass=hookHandler::getClassName ('dedupeOrg') // returns "dedupeOrg" by default, the hook can overwrite it
  $dedupe = new $dedupeClass (__FUNCTION__,"online registration");// set info about the context
  $dedupe->setEmployer ($params);
}


class dedupeOrg { // that's the default class implementing the default behaviour

  function setEmployer (&$params) {
     if ($params['current_employer'])
       if findOne ($params['current_employer'])
         $params['organization_id'] =  findOne ($params['current_employer']
      else {
         $neworg=civicrm_api ('Contact','create', array ('organization_name' =>$params['current_employer'])
         $params['organization_id'] = $neworg[id];
      }
  }
  return true;
}


Then in my module as a regular drupal/joomla one:
--------------- my module -----------


mymodule_getClassName ($className) {
  if ($className == 'dedupeOrg')
    return "mySmarterDedupeOrg";
}

class mySmarterDedupeOrg  extends dedupeOrg{
    function setEmployer (&$params) {
      //do whatever, tag, search on this and search on that...
      if (happy with the dedupe){
        $params['organization_id] = 42;
        return true;
     }
     parent::setEmployer($params); // fallback on the default behaviour
   }
}
I have extended an activity using the various class hooks, the approach described above would have been much easier and would have allowed me to put it as a separate module.

It would be as well a better alternative/complement for the contactListQuery hook: I would have been able to bypass all the code around the query and directly provide the list of 25 contacts. That would allow smarter searches that you can't do today: search on "$q%", if <20 results, search on "%q%", if <20 results, split on words and OR search...

X+

The discussion about introducing that new OO Hook as been postponed, we will do a regular hook now.

 
Note for me: CRM_Dedupe_Finder::dupesByParams($dedupeParams, $contactType, 'Fuzzy', array( $contactID ) );

adding more context (probably in dedupeParams)

Otherwise the test id is matching the name of the employer is unuseful in the API, that's handled already (and better) in CRM/Contact/BAO/Contact.php