Details
-
Type:
Improvement
-
Status: Done/Fixed
-
Priority:
Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 2.1
-
Fix Version/s: 2.2.0
-
Component/s: Core CiviCRM
-
Labels:None
Description
In order to prevent unintentional loss of data AND allow users to merge location-related data into a given location type:
1. On the "main contact" (right side) of the merge screen, when user selects a location type from the drop-down we dynamically display existing data for that location (e.g. address, phone #, email ....).
2. For address blocks - we only support 1 per location type, so if user selects a main-contact location type that currently has address data - we will be overwriting that address data with data from the duplicate contact. We will display "(Overwrite)" next to location type to let the user know this.
3. For phone, email, IM, OpenID - we will always add the data to the existing main contact at the selected location IF the row is checked to merge. We will display "(Add)" to inform the user.
— Original Issue Post ----
currently, the dedupe merge process allows contact information (eg. phone, email, address) from the dupe contact to overwrite existing contact information, or it will be lost when the dupe is erased. however, frequently we do not know which is the most recent or best information, and in many cases both remain valid.
solution: allow duplicate contact information to be *added* (like relationships, memberships, tags, etc.) to the existing contact information. this involves creating new location, if necessary, or just additional phone entries, email, etc. result is that contact info from both original and dupe is kept.
Attachments
Activity
this issue is similar to CRM-3161
-fixed rev-17073
1. Primary problem is a "design issue". Currently in the "main contact" column (right side) we show the drop-down with choice to "Overwrite" or assign to a selected location (which is good). BUT we do NOT show the existing value of that data property. The user ALSO needs to see the value they are either overwriting or preserving. This should displayed next to the drop-down. I've attached a screenshot which shows a merge page. The "main contact" actually has populated values for Work:email, Work:phone and Work:address - but you can't tell that from the screen 
2. (minor bug) My "duplicate contact" doesn't have a value for birthdate. However, I asked for that to be merged - which resulting in fatal error during the merge process - when trying to update the main contact with values from the duplicate (the bad update query is listed below - not the value of '1' for birthdate):
UPDATE civicrm_contact SET contact_type = 'Individual' , do_not_phone = 0 , sort_name = 'Mycase, Pablo' , display_name = 'Dr Pablo Mycase' , home_URL = NULL , preferred_communication_method = '1' , prefix_id = 4 , greeting_type_id = NULL , job_title = NULL , gender_id = NULL , birth_date = 1 WHERE ( civicrm_contact.id = 110 ) [nativecode=1292 ** Incorrect date value: '1' for column 'birth_date' at row 1]
=====
NOTE: It "looks like" we'll allow user to assign an Address block to a location (and NOT overwrite) - even when the main contact already has an address with that location type. EXAMPLE: Duplicate contact has a Work address. Main contact also has a Work address. User selects "Work" (rather than "Overwrite" in that merge row. I guess we'll wind up with two address records with Work location type. Not sure if this will cause problems when editing the merged contact record.
In addition, the following navigatin issues were fixed as part of this issue:
- Select Group or All Contacts to Find Dupes form (civicrm/admin/dedupefind?reset=1&rgid=1) is missing a Cancel button
. - The next screen (action=update) should have a Done button which takes you back to the previous page (Select Group or all contacts).
- When a merge operation is completed, user should be redirected back to the list of remaining dedupe "candidates" since it is likely they'll want to merge additional records. Currently they are sent back to "Select Group or all contacts" form which means they'll have to trigger the dedupe search again and again.
Batch move to verification
assigning for 3.0 QA
If I'm not mistaken, relationships, group memberships, tags, notes, etc. are actually added; only location parts (address, phone, email, IM, OpenID) must come (per location type) from either contact - so this bug is mostly about better handling of the location parts.