Answers.Body: <p>You can potentially do this by implementing the hook:</p>
  
  <p>CRM_Utils_Hook::dupeQuery</p>
  
  <p>Check: CRM/Dedupe/BAO/RuleGroup.php</p>
  
  <p>to see places where the hook is invoked</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-06T11:47:14.833Z
Answers.Text: That looks good. I could watch for $obj->id being the rule ID I want to add to, and $type being 'table', and add an additional query to the array checking the value of (in this case, but any field could be used) the contact_subtype. The rule's threshold would need to be increased to cover the extra query that would not be visible in the interface. This sounds to me like a good idea for an extension if we could afford the time to develop it.
Answers.UserDisplayName: DaveFF
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-06T16:14:16.960Z
Answers.Text: What I've done for my case, I've put in a gist at https://gist.github.com/futurefirst/a4e1d4346fa99b50cb8e . This gist also covers something I mentioned on another question where I could not add conditions covering custom fields that are only defined on contact subtypes.
Answers.UserDisplayName: DaveFF
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-06T01:10:43.110Z
Answers.LastActivityDate: 2015-05-06T01:10:43.110Z
Answers.UserDisplayName: Donald Lobo
Body: <p>It's possible to specify on a dedupe rule that 'Contact Subtype' must match. Is there any way of attaching specific values to that, for example, 'and they must both be Student'?</p>
  
  <p>Some of this could be done by having, say, a group of students and a group of teachers, and choosing the students group when I run the rule. I only have this option when running it manually (Find and Merge)- what about for rules I want to be Supervised and Unsupervised?</p>
  
  <p>In this case I want to deduplicate students against students (subject to the other conditions in the rule), but not students against teachers, or teachers against teachers. We are looking to run a survey of a large number of contacts and they tend to object if they receive it several times!</p>
  
Tags: <contacts><duplicate-contacts>
Title: Adding value conditions to dedupe rules
ThreadText: # Adding value conditions to dedupe rules
  
  (Asked by: username_0 on 2015-05-05)
  
  It's possible to specify on a dedupe rule that 'Contact Subtype' must match. Is there any way of attaching specific values to that, for example, 'and they must both be Student'?
  
  Some of this could be done by having, say, a group of students and a group of teachers, and choosing the students group when I run the rule. I only have this option when running it manually (Find and Merge)- what about for rules I want to be Supervised and Unsupervised?
  
  In this case I want to deduplicate students against students (subject to the other conditions in the rule), but not students against teachers, or teachers against teachers. We are looking to run a survey of a large number of contacts and they tend to object if they receive it several times!
  
  **Tags:** contacts, duplicate-contacts
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-05-06. Score: 1 | Accepted answer
  
  You can potentially do this by implementing the hook:
  
  CRM\_Utils\_Hook::dupeQuery
  
  Check: CRM/Dedupe/BAO/RuleGroup.php
  
  to see places where the hook is invoked
  
  > **Comments:**
  > **username_0**: That looks good. I could watch for $obj->id being the rule ID I want to add to, and $type being 'table', and add an additional query to the array checking the value of (in this case, but any field could be used) the contact_subtype. The rule's threshold would need to be increased to cover the extra query that would not be visible in the interface. This sounds to me like a good idea for an extension if we could afford the time to develop it.  
  > **username_0**: What I've done for my case, I've put in a gist at https://gist.github.com/futurefirst/a4e1d4346fa99b50cb8e . This gist also covers something I mentioned on another question where I could not add conditions covering custom fields that are only defined on contact subtypes.  
  
  ---
  
  