CiviCRM Community Forums (archive)

personally, i would want that to be something handled by the hook.
we don't make that assumption -- in fact, for our data the existing address is typically the more reliable.

it's not a question of risk, it's a question of performance.

Xavier --
Fen is working with the batch merge functionality that will be included in 4.2.
It's a pretty time and resource intensive function as it is. I'm just suggesting that an address comparison is not trivial to spec and process, and would potentially add quite a bit of time to what is already a long-processing script. So my recommendation is to allow the safe batch merge to proceed as it currently does, and then handle the cleanup afterward. You *could* handle it via the hook, which may be fine if you have small volume.

Attached is my current attempt to 1) not duplicate phone, email or address location info (with a very simple-minded '==' check), and 2) switch the primary address to be the more recently added one (adding am operation '3' to CRM/Dedupe/Merger.php).  I've just finished writing this and have not tested it yet (that's for tomorrow) but I'd be interested if you thought I was moving in the right direction or if I have a fatal flaw in my logic somewhere.

I think this would be relatively lightweight (wrt the rest of the process) and generally advantageous.

Thanks!
=Fen

There's also a potential problem that:
IF the Main contact
 * has a HOME address (location_type_id=1) that is_primary, AND
 * has a WORK address (location_type_id=2)
AND IF the Other contact
 * has a HOME address (location_type_id=1) that is_primary,
THEN
 * the resulting merged contact will have two WORK addresses, the second one being the old Other contact's HOME address.

I believe this breaks the constraint (that should exist if it doesn't already) that each contact can have at most one address of each location type.  One place the need for such a constraint shows up is with shared addresses, as one chooses to share an address using two criteria: the contact (id) and the location_type_id.

Not sure yet of a smart (and efficient) way to deal with this.

I'd really like to get clarity on this.  While I believe I have read (e.g. at http://forum.civicrm.org/index.php/topic,22366.msg93784.html#msg93784) that multiple email and phones can exist per location type, addresses are treated specially and only one address per location type should be allowed.  While this constraint is enforced in the UI (e.g., once a Home address is created, Home no longer appears in the pull-down for additional addresses) the API will cheerily allow more than one (e.g.) Work address (as I mentioned above).  While some people have multiple homes or places of business, this does seem to cause a problem with the shared address facility (see above link).

an address comparison is not trivial to spec and process, and would potentially add quite a bit of time to what is already a long-processing script. So my recommendation is to allow the safe batch merge to proceed as it currently does, and then handle the cleanup afterward.

Looking at doing this as a post-merge cleanup script, too much information is needed.  For example, you'd need need to know what addresses were is_primary and is_billing before any merges so that if a newer {location_type_id == 1, is_primary == 1} otherId address gets merged into being a {location_type_id == 2, is_primary == 0} mainId address, we can know this and do the right thing.

before Merge:
mainId == 50:   address_1: id == 100, loc_type_id == 1, is_primary == 1
                address_2: id == 200, loc_type_id == 2, is_primary == 0
otherId == 100: address_3: id == 300, loc_type_id == 1, is_primary == 1
current after Merge:
mainId == 50:  address_1: id == 100, loc_type_id == 1, is_primary == 1
               address_2: id == 200, loc_type_id == 2, is_primary == 0
               address_3: id == 300, loc_type_id == 2, is_primary == 0
My experience is that newer contacts and/or newer address records usually come with newer, more accurate address information.  (If my experience is not the norm, please let me know and I will better understand why my patches are not being considered.)

patched after Merge:
mainId == 50:  address_1: id == 100, loc_type_id == 2, is_primary == 0
               address_2: id == 200, loc_type_id == 2, is_primary == 0
               address_3: id == 300, loc_type_id == 1, is_primary == 1
I believe this can be accomplished with very little extra processing (see merge_switch2.txt, above) but I may be wrong as the patch is not working due to some magic behind some curtain I am not yet aware of.  True, this will not be correct for every case, but I believe it will be correct more of the time, which is a good thing.