Answers.Body: <p>I'd expect the Contact in Trash to be ignored by the dedupe rules, so if the dedupe rules don't match a (non-Trash) contact then a new one would be created.</p>
  
  <p>If you add the Contact B .nz address as an extra email on Contact A then with the right dedupe rule you could avoid repeated new contacts.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-25T09:33:08.067Z
Answers.LastActivityDate: 2019-01-25T09:33:08.067Z
Answers.UserDisplayName: Aidan
Body: <p>Scenario was Contact A had email mydomain.co.nz</p>
  
  <p>Contact A then filled out a Join/Renew (not using checksum) and used mydomain.nz</p>
  
  <p>Result was Contact B was created.</p>
  
  <p>Those contacts were later identified and merged while keeping Contact A with their original .co.nz email. Contact B was hence in Trash with the .nz email.</p>
  
  <p>Contact then again renewed by using the .nz email - and hence the dedupe rules matched with the contact in Trash and added the membership to that record ie Contact B.</p>
  
  <p>Seems like this is a fuzzy area, if a Contact is in Trash, but meets the required 'matching rules' what should happen to eg Contributions and Memberships or any other data.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-01-23T00:15:25.513Z
Comments.Text: This seems like a bug if it's the member person doing the renewing, and it should create a new contact, no? It might not be dedupe rules causing the issue - it might be separate membership renewal code not excluding deleted contacts in its search.
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-01-23T03:02:49.890Z
Comments.Text: not sure what you mean by 'separate renewal code' - if it helps, afaik the person involved just filled in a form as anon.
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-01-23T03:40:34.350Z
Comments.Text: I mean there are code functions that handle dedupe, and this doesn't sound like the exact same code functions get run, rather, it's a separate set of code that uses different business logic. I say that because dedupe, e.g. when run from Find and Merge Duplicate Contacts, doesn't match on deleted (at least on dmaster demo). So, this seems like a bug in the (likely) separate business logic code that handles membership signups where it isn't excluding deleted. In any case, I would expect the behavior to be that it excludes deleted.
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-01-23T09:54:36.323Z
Comments.Text: When the contact renewed again and the membership was added to Contact B, was Contact B moved out of Trash or left there?
Comments.UserDisplayName: Aidan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-01-27T20:24:56.397Z
Comments.Text: Left in trash..
Comments.UserDisplayName: petednz - fuzion
Tags: <civicontribute><civimember><duplicate-contacts><deleted>
Title: If a contact is in Trash (because they were merged) but the person with matching details fills in Membership what is a good outcome
ThreadText: # If a contact is in Trash (because they were merged) but the person with matching details fills in Membership what is a good outcome
  
  (Asked by: username_0 on 2019-01-22)
  
  Scenario was Contact A had email mydomain.co.nz
  
  Contact A then filled out a Join/Renew (not using checksum) and used mydomain.nz
  
  Result was Contact B was created.
  
  Those contacts were later identified and merged while keeping Contact A with their original .co.nz email. Contact B was hence in Trash with the .nz email.
  
  Contact then again renewed by using the .nz email - and hence the dedupe rules matched with the contact in Trash and added the membership to that record ie Contact B.
  
  Seems like this is a fuzzy area, if a Contact is in Trash, but meets the required 'matching rules' what should happen to eg Contributions and Memberships or any other data.
  
  **Tags:** civicontribute, civimember, duplicate-contacts, deleted
  
  > **Comments:**
  > **username_1**: This seems like a bug if it's the member person doing the renewing, and it should create a new contact, no? It might not be dedupe rules causing the issue - it might be separate membership renewal code not excluding deleted contacts in its search.  
  > **username_0**: not sure what you mean by 'separate renewal code' - if it helps, afaik the person involved just filled in a form as anon.  
  > **username_1**: I mean there are code functions that handle dedupe, and this doesn't sound like the exact same code functions get run, rather, it's a separate set of code that uses different business logic. I say that because dedupe, e.g. when run from Find and Merge Duplicate Contacts, doesn't match on deleted (at least on dmaster demo). So, this seems like a bug in the (likely) separate business logic code that handles membership signups where it isn't excluding deleted. In any case, I would expect the behavior to be that it excludes deleted.  
  > **username_2**: When the contact renewed again and the membership was added to Contact B, was Contact B moved out of Trash or left there?  
  > **username_0**: Left in trash..  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-01-25. Score: 1
  
  I'd expect the Contact in Trash to be ignored by the dedupe rules, so if the dedupe rules don't match a (non-Trash) contact then a new one would be created.
  
  If you add the Contact B .nz address as an extra email on Contact A then with the right dedupe rule you could avoid repeated new contacts.
  
  
  ---
  
  