CiviCRM Community Forums (archive)

Hmm - that does sound like a useful option. But if we're going to re-add it we'll need a test on it I think.

NB - we would like at some point to add dedupe actions to the contact api

trunk now has civicrm_api3_contact_merge() in api/v3/Contact.php and civicrm_api3_process_batch_merge() in api/v3/Job.php

I'm starting to look at these (and their associated batch dedupe/merge facility in the GUI, see CRM-9312 for more) for use by one of my clients, but am currently feeling at a loss wrt to how to use these excellent sounding features.

Might anyone be able to:

• describe what situations these are/are not best suited for?
• suggest best practices for their use?

For my part, I can:

• test these features on our dataset
• document methods of use and possible issues

Thanks lcdweb, that's a helpful example module. The hook offers a lot of options for customizing the merging.

It wasn't immediately obvious to me how to actually make use of the batch merge. There's a new button called "Batch Merge Duplicates" at the bottom of the list of duplicates when you do a dupe search. Simple! So far, very impressed with the new version.

The batch/merge is (so far) working great, though still in testing mode.  I made a small change to the api call doc (and switched the main_id, other_id params which were backward) to make more sense and attach the patch here (didn't feel it was significant enough to create a new ticket).

Found the issue: CRM_Dedupe_Merger::merge returns $resultStats and since the API checks for $result['is_error'] == 0 but since $result['is_error'] is not set, the API wrapper considers this a pass.

I don't know the dedupe_check() function, so I can't help there

I've been working on a script to take a list of dupes returned from a mailhouse (which used data exported from CiviCRM) and merging them.  One question I am currently up against is the merging of addresses.  Even if all the values in the source (other_id) address == all the values in destination (main_id) address (but their address ids are different) we end up with a merged contact with two addresses, the src_address being placed in location_type_id == 2 for the dest contact.

I'm thinking of checking for address_match in the batchmerge hook and removing the older address before the merge, but this is dangerous because if the merge fails then I've lost an address.  Is there some way to make this happen more safely that I am missing?

Also, and perhaps more importantly, the merge process keeps the destination primary address as primary, whereas our experience is that whichever address was most recently created (or changed) is generally the correct address and should be primary.  This should be easier to add to the batchmerge_hook, though perhaps it should be default functionality?

yes, this is a consequence of the "safe" batch merge.
i've chewed over options as well, as it impacts email/phone/etc. -- any of the 1-to-many records on the contact object.

my current thought is to create a cleanup script to be run post merge where I compare and remove duplicate records on a contact. the batch merge is pretty slow as it is. if we have to also do a lookup a comparison during the merge, it will really slow things down. a post import script could be done with straight sql and be much faster.

on the positive side --
because it adds these records instead of comparing and merging, you pick up a lot more merges. if we were comparing them, there'd typically be a ton more conflicts that would block the merge.