Answers.Body: <p>The address aspect of this has recently been raised as a bug here:
  <a href="https://issues.civicrm.org/jira/browse/CRM-18455" rel="nofollow">https://issues.civicrm.org/jira/browse/CRM-18455</a></p>
  
  <p>And has been patched as part of:
  <a href="https://issues.civicrm.org/jira/browse/CRM-18338" rel="nofollow">https://issues.civicrm.org/jira/browse/CRM-18338</a></p>
  
  <p>As for the rest of the merging logic - where it creates many email addresses (phone numbers, and other 'location blocks') of the same type, I agree this doesn't seem desirable; but deciding which phone/email to keep isn't always straightforward. The current logic is:</p>
  
  <p>When force merging if there are any conflicts the 'main' record takes precedence, otherwise any information from the 'other' record is added to it. Ie: all emails would be added. If there were two addresses of the same type then the 'main' one would stay on the record.</p>
  
  <p>I also posed this question on the civicrm-dev mailing list as to whether this is the desired behavior and I've created a follow-up thread on the forum: <a href="https://forum.civicrm.org/index.php?topic=37165" rel="nofollow">https://forum.civicrm.org/index.php?topic=37165</a></p>
  
  <p>Please feel free to get involved =] It would be great to improve this tool and have it working as desired - once we know what 'as desired' looks like.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-04T08:20:55.450Z
Answers.LastActivityDate: 2016-05-04T08:20:55.450Z
Answers.UserDisplayName: John
Body: <p>I'm pretty sure this is not an intended behavior, but I want to make sure. </p>
  
  <p>When I try to add a second address of the same location type I get an error and civi will not let me (Image 1). </p>
  
  <p>If I use the merge tool and I try to merge contact A (Image 2) with contact B (Image 3), I am told moving/merging the home address to the home address of the destination contact will cause an overwrite (Image 4). </p>
  
  <p>In the merge tool I see no conflicts even though contacts have home addresses that differ (Image 5). If I use the [Batch Merge All Duplicates] button I end up with 1 contact with 2 different address records of the same type (Image 6). Same issue with email addresses, although civi will let me add two email addresses of dame location type (which I don't think should happen). </p>
  
  <p>Bug?</p>
  
  <p>*note, this was tested on civi demo site.</p>
  
  <p><strong>Image 1</strong>
  <a href="https://i.sstatic.net/utcF4.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/utcF4.png" alt="Image 1"></a></p>
  
  <p><strong>Image 2</strong>
  <a href="https://i.sstatic.net/Cydgy.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Cydgy.png" alt="Image 2"></a></p>
  
  <p><strong>Image 3</strong>
  <a href="https://i.sstatic.net/713c7.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/713c7.png" alt="Image 3"></a></p>
  
  <p><strong>Image 4</strong>
  <a href="https://i.sstatic.net/49tLn.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/49tLn.png" alt="Image 4"></a></p>
  
  <p><strong>Image 5</strong>
  <a href="https://i.sstatic.net/Fip1L.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Fip1L.png" alt="Image 5"></a></p>
  
  <p>Image 6
  <a href="https://i.sstatic.net/XPDTl.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/XPDTl.png" alt="Image 6"></a></p>
  
Tags: <duplicate-contacts>
Title: Bulk merge creating multiple address (and email) records of same location type
ThreadText: # Bulk merge creating multiple address (and email) records of same location type
  
  (Asked by: username_0 on 2016-04-28)
  
  I'm pretty sure this is not an intended behavior, but I want to make sure.
  
  When I try to add a second address of the same location type I get an error and civi will not let me (Image 1).
  
  If I use the merge tool and I try to merge contact A (Image 2) with contact B (Image 3), I am told moving/merging the home address to the home address of the destination contact will cause an overwrite (Image 4).
  
  In the merge tool I see no conflicts even though contacts have home addresses that differ (Image 5). If I use the [Batch Merge All Duplicates] button I end up with 1 contact with 2 different address records of the same type (Image 6). Same issue with email addresses, although civi will let me add two email addresses of dame location type (which I don't think should happen).
  
  Bug?
  
  \*note, this was tested on civi demo site.
  
  **Image 1**
  [![Image 1](https://i.sstatic.net/utcF4.png)](https://i.sstatic.net/utcF4.png)
  
  **Image 2**
  [![Image 2](https://i.sstatic.net/Cydgy.png)](https://i.sstatic.net/Cydgy.png)
  
  **Image 3**
  [![Image 3](https://i.sstatic.net/713c7.png)](https://i.sstatic.net/713c7.png)
  
  **Image 4**
  [![Image 4](https://i.sstatic.net/49tLn.png)](https://i.sstatic.net/49tLn.png)
  
  **Image 5**
  [![Image 5](https://i.sstatic.net/Fip1L.png)](https://i.sstatic.net/Fip1L.png)
  
  Image 6
  [![Image 6](https://i.sstatic.net/XPDTl.png)](https://i.sstatic.net/XPDTl.png)
  
  **Tags:** duplicate-contacts
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-05-04. Score: 0 | Accepted answer
  
  The address aspect of this has recently been raised as a bug here:
  <https://issues.civicrm.org/jira/browse/CRM-18455>
  
  And has been patched as part of:
  <https://issues.civicrm.org/jira/browse/CRM-18338>
  
  As for the rest of the merging logic - where it creates many email addresses (phone numbers, and other 'location blocks') of the same type, I agree this doesn't seem desirable; but deciding which phone/email to keep isn't always straightforward. The current logic is:
  
  When force merging if there are any conflicts the 'main' record takes precedence, otherwise any information from the 'other' record is added to it. Ie: all emails would be added. If there were two addresses of the same type then the 'main' one would stay on the record.
  
  I also posed this question on the civicrm-dev mailing list as to whether this is the desired behavior and I've created a follow-up thread on the forum: <https://forum.civicrm.org/index.php?topic=37165>
  
  Please feel free to get involved =] It would be great to improve this tool and have it working as desired - once we know what 'as desired' looks like.
  
  
  ---
  
  