CiviCRM Community Forums (archive)

Just working through some deduping cleanup and noticed a couple issues that I don't believe should be there --

1) The merge process overwrites all fields in a data block, even if the fields in the duplicate record are empty. For example:
Contact 1 main address contains a phone, email, no address.
Contact 2 main address contains address, no phone or email.

If I merge 2 into 1, I would expect that the address would be brought over, giving me a full data set. Instead, the address is brought over and the phone/email previously recorded in Contact 1 is erased (the lack of data for those values in Contact 2 overwrites the existing values).

I believe the logic should be IF value in 2, overwrite in 1 -- on a field by field basis.

2) Smaller issue, but the terminology in the duplicate comparison screen seems backward. In col 1 it reads "potentially duplicate contact" and when one is selected, col 2 says "merge with". As I read that, col 1 is the duplicate and col 2 is the "real" record. But when you continue to the next screen, that language is reversed -- what was in col 2 is treated as the dup and what was in col 1 is treated as the "real" contact.

Since sometimes a user may choose to selectively merge data blocks, it becomes important to have the logic accurate.

Please confirm behavior and let me know if these should be Jira'd.

-Brian

Valid point --
In the specific instance in which I was working, I knew the "real" records because they all had a prefix. But in most cases, you can't tell the difference.

So yes, a preferred way to handle it would be to have the option of selecting the direction of the merge. That issue is probably pretty small, since either way the records will be merged into a single one. I only noticed the mixup in logic because I actually did know (and care about) which record was the one I was keeping.

I think the first issue is more important to functionality.

-Brian

No -- not when unchecked. The problem is that if you check one of the "blocks" available in the merge comparison screen, it completely replaces all the fields -- even if that means an empty field overriding existing data.

In my case, I had some phone numbers in the existing location block, and had addresses with no phone numbers in the dup location block. When I merged them, I lost the phone numbers.

Hi Deepak, If the entire screen is being reworked, it may be relevant still to be asking whether it permits us to define whether we are wanting A to merge with B, or B with A, as sometimes it is only clear when their data becomes visible on the merge screen. Pete

An issue has been filed which will address the first issue (mentioned by Brian) - http://issues.civicrm.org/jira/browse/CRM-3149