Answers.Body: <p>B please. This has been a point of frustration when importing. Make the location type simply a label without deduping consideration.</p>
  
  <p>I thought it always takes into account location type.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-17T19:16:25.043Z
Answers.Text: https://github.com/civicrm/civicrm-core/pull/17645 implements this.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-02-13T21:36:27.900Z
Answers.LastActivityDate: 2020-02-13T21:36:27.900Z
Answers.UserDisplayName: Andy Burns
Answers.Body: <p>Looking at the code this was implemented in svn days &amp; it's just a case of removing code &amp; adding a unit test</p>
  
  <p><a href="https://github.com/civicrm/civicrm-core/blob/2cbe6e87cbf0c1ce7a2f89c2000c472b58e66146/CRM/Dedupe/Finder.php#L266-L298" rel="nofollow noreferrer">https://github.com/civicrm/civicrm-core/blob/2cbe6e87cbf0c1ce7a2f89c2000c472b58e66146/CRM/Dedupe/Finder.php#L266-L298</a></p>
  
  <p>Relevant tickets:
  <a href="https://issues.civicrm.org/jira/browse/CRM-17564" rel="nofollow noreferrer">https://issues.civicrm.org/jira/browse/CRM-17564</a> <a href="https://issues.civicrm.org/jira/browse/CRM-5026" rel="nofollow noreferrer">https://issues.civicrm.org/jira/browse/CRM-5026</a> <a href="https://issues.civicrm.org/jira/browse/CRM-3902" rel="nofollow noreferrer">https://issues.civicrm.org/jira/browse/CRM-3902</a></p>
  
  <p>From the code it looks like this is used when matching on creating a contact but not on finding duplicate contacts from the finder screen.</p>
  
  <p>I'm +1 on B but would want to see more people weigh in (esp as I'm not a heavy user of this functionality as we import and then dedupe for historical reasons - which by-passes this)</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-02-18T02:01:16.320Z
Answers.LastActivityDate: 2020-02-18T02:01:16.320Z
Answers.UserDisplayName: eileen
Answers.Body: <p>I came across this today and am also a +1 for B.  I think the Bs have it.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-16T15:21:44.723Z
Answers.LastActivityDate: 2020-06-16T15:21:44.723Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>per the title, what do others think is the better behaviour</p>
  
  <p>a/ ignore Location Type for Email, Phone, but use Location Type for Address (status quo)</p>
  
  <p>b/ change so Location Type is never taken in to consideration (ie Address would be treated same as Email, Phone)</p>
  
  <p>c/ change so Email/Phone also have Location Type taken in to consideration when applying matching rules.</p>
  
  <p>Reason for asking is we got caught out using a rule with postcode. We expected the postcode to be location agnostic. Seems it isn't.</p>
  
Tags: <duplicate-contacts><dedupe-rules>
Title: Dedupe rule ignores the location type for Email/Phone but does not ignore for Addresses. Should we make this consistent
ThreadText: # Dedupe rule ignores the location type for Email/Phone but does not ignore for Addresses. Should we make this consistent
  
  (Asked by: username_0 on 2020-02-13)
  
  per the title, what do others think is the better behaviour
  
  a/ ignore Location Type for Email, Phone, but use Location Type for Address (status quo)
  
  b/ change so Location Type is never taken in to consideration (ie Address would be treated same as Email, Phone)
  
  c/ change so Email/Phone also have Location Type taken in to consideration when applying matching rules.
  
  Reason for asking is we got caught out using a rule with postcode. We expected the postcode to be location agnostic. Seems it isn't.
  
  **Tags:** duplicate-contacts, dedupe-rules
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2020-02-13. Score: 5
  
  B please. This has been a point of frustration when importing. Make the location type simply a label without deduping consideration.
  
  I thought it always takes into account location type.
  
  > **Comments:**
  > **username_2**: https://github.com/civicrm/civicrm-core/pull/17645 implements this.  
  
  ---
  
  ### Answer by username_3 on 2020-02-18. Score: 1
  
  Looking at the code this was implemented in svn days & it's just a case of removing code & adding a unit test
  
  <https://github.com/civicrm/civicrm-core/blob/2cbe6e87cbf0c1ce7a2f89c2000c472b58e66146/CRM/Dedupe/Finder.php#L266-L298>
  
  Relevant tickets:
  <https://issues.civicrm.org/jira/browse/CRM-17564> <https://issues.civicrm.org/jira/browse/CRM-5026> <https://issues.civicrm.org/jira/browse/CRM-3902>
  
  From the code it looks like this is used when matching on creating a contact but not on finding duplicate contacts from the finder screen.
  
  I'm +1 on B but would want to see more people weigh in (esp as I'm not a heavy user of this functionality as we import and then dedupe for historical reasons - which by-passes this)
  
  
  ---
  
  ### Answer by username_2 on 2020-06-16. Score: 1
  
  I came across this today and am also a +1 for B. I think the Bs have it.
  
  
  ---
  
  