Body: <p>Civi 4.7.13, Drupal 7.56.  I set up an unsupervised rule for FN/LN/email, with weights of 10 each and a weight threshold of 30.  What I see happening is this:</p>
  
  <p>Contact A is in Civi as Jane Doe, only one email (location type: home) of janedoe@mail.com.</p>
  
  <p>Contact B is entered via a contribution form and enters a first name and last name that match Contact A (Jane Doe).  The email address entered <em>also</em> matches Contact A, but the form enters it as location type billing.</p>
  
  <p>I would have expected Civi to consider Contact A's email as a primary email and check for a match irrespective of location type.  That is not what is happening - a new contact record is being created consistently each time.</p>
  
  <p>Since the duplicate rule doesn't allow the specification of a location type (and I'd prefer not to go down that road), I'm not sure how to proceed or even if this is expected behavior.  (I don't recall seeing this behavior in previous versions of Civi.)  Any ideas?</p>
  
  <p>Thanks in advance.</p>
  
  <p>EDIT to add screenshot of dup rule: <a href="https://i.sstatic.net/qoeve.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/qoeve.png" alt="enter image description here"></a></p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-05T16:37:28.137Z
Comments.Text: Is the home email the primary email? sounds weird indeed, could you reproduce on demo?
Comments.UserDisplayName: Xavier
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-05T19:16:49.713Z
Comments.Text: agree it sounds odd. If Contact A has x@x.x as Primary email, and if a form is filled in with x@x.x as Billing then I would assume it would be matched, since it matches the existing Primary. perhaps paste screenshot of your Rule in case there is a minor issue that needs fixing. (having seen people with Rules where the threshold is set to zero i know that anything is possible!)
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-06T17:28:43.047Z
Comments.Text: I'm not able to replicate on the demo site, no.  I'll edit to add the screenshot of the duplicate rule.
Comments.UserDisplayName: Lesley Carter - BackOffice
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-19T15:32:19.783Z
Comments.Text: Just to update this, I now have been able to replicate this issue on the 4.7.x demo site.  (Cannot replicate on the 4.6.x demo site, however.)  Was duplicate handling changed much for 4.7.x, does anyone know?
Comments.UserDisplayName: Lesley Carter - BackOffice
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-15T17:27:03.240Z
Comments.Text: Has this one gone anywhere? Is there an issue logged and if so has it been fixed? (I'm struggling with dedupe problems in 4.7.23)
Comments.UserDisplayName: Graham
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-15T19:25:43.857Z
Comments.Text: Graham - thanks for the reminder, I'd forgotten about this posting.  In our case, the culprit turned out to be the name fields, not the email... the only name fields on the form were for the billing profile, and the dedupe rule doesn't seem to be checking the billing name.  Once we added a profile with FN and LN, all worked as expected.  Not sure if that helps your scenario but hopefully it gives you a place to start.
Comments.UserDisplayName: Lesley Carter - BackOffice
Tags: <duplicate-contacts>
Title: Civi duplicate rules with respect to email & primary versus location type
ThreadText: # Civi duplicate rules with respect to email & primary versus location type
  
  (Asked by: username_0 on 2017-07-05)
  
  Civi 4.7.13, Drupal 7.56. I set up an unsupervised rule for FN/LN/email, with weights of 10 each and a weight threshold of 30. What I see happening is this:
  
  Contact A is in Civi as Jane Doe, only one email (location type: home) of janedoe@mail.com.
  
  Contact B is entered via a contribution form and enters a first name and last name that match Contact A (Jane Doe). The email address entered *also* matches Contact A, but the form enters it as location type billing.
  
  I would have expected Civi to consider Contact A's email as a primary email and check for a match irrespective of location type. That is not what is happening - a new contact record is being created consistently each time.
  
  Since the duplicate rule doesn't allow the specification of a location type (and I'd prefer not to go down that road), I'm not sure how to proceed or even if this is expected behavior. (I don't recall seeing this behavior in previous versions of Civi.) Any ideas?
  
  Thanks in advance.
  
  EDIT to add screenshot of dup rule: [![enter image description here](https://i.sstatic.net/qoeve.png)](https://i.sstatic.net/qoeve.png)
  
  **Tags:** duplicate-contacts
  
  > **Comments:**
  > **username_1**: Is the home email the primary email? sounds weird indeed, could you reproduce on demo?  
  > **username_2**: agree it sounds odd. If Contact A has x@x.x as Primary email, and if a form is filled in with x@x.x as Billing then I would assume it would be matched, since it matches the existing Primary. perhaps paste screenshot of your Rule in case there is a minor issue that needs fixing. (having seen people with Rules where the threshold is set to zero i know that anything is possible!)  
  > **username_0**: I'm not able to replicate on the demo site, no.  I'll edit to add the screenshot of the duplicate rule.  
  > **username_0**: Just to update this, I now have been able to replicate this issue on the 4.7.x demo site.  (Cannot replicate on the 4.6.x demo site, however.)  Was duplicate handling changed much for 4.7.x, does anyone know?  
  > **username_3**: Has this one gone anywhere? Is there an issue logged and if so has it been fixed? (I'm struggling with dedupe problems in 4.7.23)  
  > **username_0**: username_3 - thanks for the reminder, I'd forgotten about this posting.  In our case, the culprit turned out to be the name fields, not the email... the only name fields on the form were for the billing profile, and the dedupe rule doesn't seem to be checking the billing name.  Once we added a profile with FN and LN, all worked as expected.  Not sure if that helps your scenario but hopefully it gives you a place to start.  
  
  ---
  
  ## 0 answers
  
  