Mdtryhht

I'm wanting to refine the de-duping rules, but first of all I'd like to find out exactly what the predefined rules are before I create my own. They are reserved, so you can't edit them, which is fine, but it only tells you which fields they use and not what the weights and thresholds are so the full behaviour is not clear.

If you have access to the database type

SELECT * from civicrm_dedupe_rule r inner join civicrm_dedupe_rule_group rg on rg.id = r.dedupe_rule_group_id;

which will give you a table which isn't pretty but is mostly understandable.

Using Demerit's correct and useful answer above, here are the details in plain text of the three pre-configured rules that you can't see by the normal method, so may be of use to others:

Name and Email (reserved): Supervised: Individual

First Name: Length "null", Weight 5

Last Name: Length "null", Weight 7

Email: Length "null", Weight 10

Threshold 20

Email (reserved): Unsupervised: Individual

Email: Length "null", Weight 10

Threshold 20

Name and Address (reserved): General: Individual

First Name: Length "null", Weight 5

Last Name: Length "null", Weight 5

Street Address: Length "null", Weight 5

Middle Name: Length "null", Weight 1

Suffix: Length "null", Weight 1

Threshold: 15

Demerit's and Mick's answers are incorrect for the (built-in) reserved rules - though it's definitely confusing!

If a RuleGroup has a value in the name field, and that name corresponds to a filename in CRM/Dedupe/BAO/QueryBuilder, then the customized SQL in those files will be used. The existing entries in civicrm_rule for those RuleGroups are holdovers from before that system existed, and editing them has no effect.

"Standard" dedupe rules with multiple criteria are very inefficient compared to handwritten SQL, which is why this is a valuable technique. You can create your own handwritten queries with hook_civicrm_dedupe, and the Veda dedupe extension has a number of excellent examples. Note that this extension doesn't work on modern Civi because of some of its other functions, but the dedupe rules can be ripped out into something else.

Finally - I learned just yesterday that the built-in handwritten dedupe rules seem to execute different SQL when comparing in Unsupervised/Supervised mode (a single contact) vs. General mode (find all dupes). While I haven't proved it, I suspect that if you're in the rare scenario of needing to optimize your unsupervised/supervised dedupes, creating a new class to extend CRM_Dedupe_BAO_QueryBuilder is the way to go. I just posted org.agbu.optimizeddedupe to provide an example of this.