CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-07-05T23:48:38Zhttps://lab.civicrm.org/dev/core/-/issues/3989Merging contacts should not overwrite empty source2023-07-05T23:48:38ZlarsssandergreenMerging contacts should not overwrite empty sourceIf you merge two contacts, the original with an empty source and the duplicate with some source value, the source value from the duplicate is copied to the original. This doesn't make sense, because the source of the contact is clearly n...If you merge two contacts, the original with an empty source and the duplicate with some source value, the source value from the duplicate is copied to the original. This doesn't make sense, because the source of the contact is clearly not whatever the source of the duplicate contact is — the contact already existed before that!
For example, we have lots of ten year old contacts with no source. A duplicate is created through an event registration now and these contacts can end up with a nonsensical source from an event this year when they have been in our database for a decade.
My proposal:
1. Remove the default selected checkbox for source when merging contacts manually. Source should never be overwritten by default, even if empty for the original contact. Users can still opt to overwrite with the newer source if desired.
2. Never overwrite source when batch merging, even if it is empty in the original contact. I think this is a sensible behaviour that doesn't need user intervention, but if there is a concern about this, we could also flag this as a merge conflict instead in this specific case.https://lab.civicrm.org/dev/core/-/issues/3440Check for matching contact on contact add form sends hardcoded fields to dupl...2023-07-06T07:25:40ZdarrickCheck for matching contact on contact add form sends hardcoded fields to duplicatecheck api callOverview
----------------------------------------
If a custom Supervised rule is created using any field not in ['first_name', 'last_name', 'nick_name', 'household_name', 'organization_name', 'email'] then clicking on the **Check for Mat...Overview
----------------------------------------
If a custom Supervised rule is created using any field not in ['first_name', 'last_name', 'nick_name', 'household_name', 'organization_name', 'email'] then clicking on the **Check for Matching Contact** button will return no results.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Find and Merge Duplicate Contacts**.
2. Click on **Add Individual Rule**
3. Add a rule with field phone, weight 10, threshold 10
4. Click on **Change rule** and set to **Supervised**
5. Click on **Contacts -> New Individual**
6. Add a contact with First Name: Bob, Last Name: Dobbs and phone 666.666.6666
7. Save the contact.
8. Click on **Contacts -> New Individual**
9. Add a contact with First Name: Bob, Last Name: Dobbs and phone 666.666.6666
10. Click on **Check for Matching Contact**
Current behaviour
----------------------------------------
A popup displays "Similar contact if found" after entering the First Name and after entering the Last Name in step 9.
After entering the duplicate phone number nothing happens.
After clicking on **Check for Matching Contact** nothing happens.
Expected behavior
----------------------------------------
After entering either First Name or Last Name nothing should happen unless the entered field is included in the Supervised rule.
A popup displaying "Similar contact if found" should happen after the phone number is entered and also after clicking on **Check for Matching Contact**
Comments
----------------------------------------
I ran across this while looking to see if I could fix any other outstanding bugs related dedupe. Was working on this one: (https://lab.civicrm.org/dev/core/-/issues/2966) I wasn't able to reproduce their issue.
It may still be useful to hard code those fields so by default the form always matches on name or email when entering those fields but then the additional fields will also be searched when added using the custom rule. As any fields not needed for the custom rule will just be ignored.https://lab.civicrm.org/dev/core/-/issues/4500Ongoing duplicate contact creation if mismatch in civicrm_uf_match2024-01-24T21:04:46ZAllenShawOngoing duplicate contact creation if mismatch in civicrm_uf_match(I've only seen this on WordPress, but the relevant file is in core, so I'm filing under dev/core).
**Summary:**
Under certain circumstances involving "crossed wires" in the `civicrm_uf_match` table, a logged-in user's mere activity in...(I've only seen this on WordPress, but the relevant file is in core, so I'm filing under dev/core).
**Summary:**
Under certain circumstances involving "crossed wires" in the `civicrm_uf_match` table, a logged-in user's mere activity in CiviCRM will create a new contact (containing only the user's email address) for each CiviCRM page load (or ajax call, etc.). Left un-checked, this can lead to thousands of duplicate contacts containing only an identical email address.
**Scope of impact:**
I've seen this on a handful of WordPress sites over the past 5-7 years. I've not heard others in the community mention it, nor seen an existing issue on l.c.o.
**Example steps to reproduce:**
This is only one example; there are surely other steps that will get us there. See "Requisite data conditions" below.
These steps are for repro under WordPress. I haven't tried this under other CMSs.
1. Create WP user _a_ with email address _a@example.com_. Observe this creates a corresponding civicrm contact; we'll call this contact C1. Observe that the entry in `civicrm_uf_match` is correct (i.e. Summary tab for contact C1 shows the user ID of user _a_).
2. Change the email address for user _a_ to _a2@example.com_. Observe that the `civicrm_uf_match` link is preserved (but also that the email address in `civicrm_uf_match.uf_name` is unchanged).
3. Delete contact C1 (permanently or to trash). Observe entry in `civicrm_uf_match` is deleted, and user _a_ still exists.
4. Create a new contact (which we'll call C2) with another email address, e.g. _aFoo@example.com_.
5. Use CiviCRM's "Create User Record" feature to create a new WP user for contact C2; specify any username you like, but we'll assume username _a2_. Observe that the entry in `civicrm_uf_match` is correct (i.e. Summary tab for contact C2 shows the user ID of user _a2_), and that user _a2_ has email address _aFoo@example.com_.
6. Change contact C2's email address to _a2@example.com_. Observe that the email address in `civicrm_uf_match.uf_name` is updated, and the emmail address for WP user _a2_ is unchanged.
At this point, you'll have this state of data:
| wp_users.ID* | wp_users.user_login | civicrm_uf_match.id* | civicrm_uf_match.contact_id* | civicrm contact primary email | civicrm_uf_match.uf_name | wp_users.user_email |
|-------------|---------------------|---------------------|-----------------------------|-------------------------------|--------------------------|---------------------|
| 64 | a | NULL | NULL | NULL | NULL | a2@example.com |
| 65 | a2 | 162 | 75512 | a2@example.com | a2@example.com | aFoo@example.com |
_\* IDs in this table are from my real data; yours will differ of course._
7. As for permissions, I granted user _a_ the WP Administrator role, which has _Administer CiviCRM_; you could probably repro with narrower permissions.
8. Log in as user _a_. Perform a CiviCRM search for contacts having email address _a2@example.com_. Observe the result count N.
9. **Bad Behavior:** Do just about anything in CiviCRM. For example, refresh the search just performed. Observe the result count is >N.
10. Repeat step 9 and observe the increasing number of contacts with email address _a2@example.com_.
**Requisite data conditions**:
As mentioned above, there are probably many possible repro recipes, but the key is to arrive at this requisite state of data:
Given a specific WP user e.g. username _a_, email address _a2@example.com_, new contacts are created containing only this email address, each time this logged-in user takes any action (or presumably almost any action) in CiviCRM, as long as:
1. The WP user ID is not represented in `civicrm_uf_match.uf_id`; and
2. The WP user email (_a2@example.com_) is associated with one or more CiviCRM contacts; in a list of these contacts, sorted by `is_primary DESC, contact_id`, the first contact in that list is represented in `civicrm_uf_match.contact_id`; and
3. The WP user email (_a2@example.com_) is represented in `civicrm_uf_match.uf_name`.
**Relevant code:**
This all seems to be primarily handled by `CRM_Core_DAO_UFMatch::synchronizeUFMatch()`. The above "requisite data conditions" are a summary of the logical path in that method that leads to the stated problem.
Interestingly, the code seems to be aware of this problem, as in [line 284](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/UFMatch.php#L284) it defines a variable `$msg` which would read along the lines of (using values from my data-state above) "Contact ID 162 is a match for WordPress user 64 but has already been matched to 65" -- but that message is never used or logged anywhere.
**Workarounds:**
My simplest fix has been simply to update civicrm_uf_match via SQL to link the right user with the right contact, like so (again using values from my real data above): `update civicrm_uf_match set uf_id = 64 where contact_id = 75512;`. And then of course to remove all of the duplicate contacts.
I thought _Synchronize Users to Contacts_ might do the trick, but it has no affect on the relevant data, and the bad behavior persists.
(Joinery reference: F#1180, F#1339)https://lab.civicrm.org/dev/core/-/issues/4402Change unsupervised Household dedupe rule to email only2023-07-06T23:20:28ZlarsssandergreenChange unsupervised Household dedupe rule to email onlyAs @DaveD [pointed out](https://github.com/civicrm/civicrm-core/pull/26673#issuecomment-1613302861), the default unsupervised Household dedupe rule that matches on name or email doesn't make a lot of sense. Presumably, you could easily h...As @DaveD [pointed out](https://github.com/civicrm/civicrm-core/pull/26673#issuecomment-1613302861), the default unsupervised Household dedupe rule that matches on name or email doesn't make a lot of sense. Presumably, you could easily have multiple households with the name "Jones family" or similar in whatever format you choose for household names. You wouldn't want these to be merged automatically.
I think the easiest and clearest solution is only to merge households with the same email, but then that won't help those without emails. We could do something like threshold 20, email 20, name 10, street address 10, phone 10, but I'm not sure we gain much from that. We can keep name or email as the supervised rule.https://lab.civicrm.org/dev/core/-/issues/4399Unable to merge incomplete memberships due to missing end_date2023-07-06T06:38:24Zfreeform.stephUnable to merge incomplete memberships due to missing end_dateWhen a contribution fails when purchasing a membership, a membership remains (as either pending or cancelled) that does not have an end date. When merging contacts any memberships are expected to have an end date.
`"UPDATE civicrm_membe...When a contribution fails when purchasing a membership, a membership remains (as either pending or cancelled) that does not have an end date. When merging contacts any memberships are expected to have an end date.
`"UPDATE civicrm_membership SET end_date = '' WHERE id=ID [nativecode=1292 ** Incorrect date value: '' for column `civicrm`.`civicrm_membership`.`end_date` at row 1]"`https://lab.civicrm.org/dev/core/-/issues/4397What should the Name and Address reserved general Individual dedupe rule do?2023-06-30T00:14:21ZlarsssandergreenWhat should the Name and Address reserved general Individual dedupe rule do?We have a reserved dedupe rule on new installs for Individuals called Name and Address.
What it actually does is matches contacts who have the same first name, last name and street address. What it claims to do is the following:
![image]...We have a reserved dedupe rule on new installs for Individuals called Name and Address.
What it actually does is matches contacts who have the same first name, last name and street address. What it claims to do is the following:
![image](/uploads/d427acb2b1c3ce07c994b68a2371ac62/image.png)
[This rule](https://github.com/civicrm/civicrm-core/blob/master/sql/civicrm_data/civicrm_dedupe_rule/IndividualGeneral.sqldata.php) also includes suffix_id and middle_name with weights of 1, which cannot influence the matches (threshold 15, all other items have weight 5), so these don't do anything.
There is a [hard-coded query](https://github.com/civicrm/civicrm-core/blob/master/CRM/Dedupe/BAO/QueryBuilder/IndividualGeneral.php) for this rule that should match up with the above (right now we are querying middle_name, suffix and birthdate for no reason, which is kind of ironic since this query claims to be optimized).
None of this has changed in at least ten years.
Personally, I don't think matching on first, last and street address is useful (as street addresses are often written slightly differently so are not that likely to match). Maybe we should just eliminate this reserved dedupe rule, since I can't see that it is used for anything. If not, maybe we should make it more useful by making it just first and last name. Or maybe there is some reason this is useful as is and we should simply make this all consistent so it just matches on first, last and address and nothing more.https://lab.civicrm.org/dev/core/-/issues/4237Count is inacurate in Find and Merge Duplicates2024-02-27T01:12:33ZStoobCount is inacurate in Find and Merge DuplicatesIn the attached example has only 800 contacts in the entire Civi although the same person has **several _dozen_ duplicates of themselves**, for whatever reason. The side effect is what appears to be an exponentially inaccurate duplicate ...In the attached example has only 800 contacts in the entire Civi although the same person has **several _dozen_ duplicates of themselves**, for whatever reason. The side effect is what appears to be an exponentially inaccurate duplicate count as well as in the batch merge screen.
![du](/uploads/c74e365a75d2fe01fcca2c39f07b1579/du.png)
![batcha](/uploads/46f2a517bbabadbd953c9b8c7e05661e/batcha.png)https://lab.civicrm.org/dev/core/-/issues/4194Proposal - remove some fields from dedupe field options2023-03-27T02:42:05ZeileenProposal - remove some fields from dedupe field optionsWhen creating dedupe rules there are some fields in the drop down that don't make sense to me
![image](/uploads/87e8fe511a5e795ce362dd7027705505/image.png)
Specifically
**Irrational (technical term)**
(if these are present the dedupe...When creating dedupe rules there are some fields in the drop down that don't make sense to me
![image](/uploads/87e8fe511a5e795ce362dd7027705505/image.png)
Specifically
**Irrational (technical term)**
(if these are present the dedupe rule functionality won't apply)
- 'id' => 'Contact ID',
- 'external_identifier' => 'External Identifier',
**Dumb (technical term)**
- Contact.is_deceased
- 'addressee_id' => 'Addressee',
- 'addressee_custom' => 'Addressee Custom',
- 'do_not_email' => 'Do Not Email',
- 'do_not_mail' => 'Do Not Mail',
- 'do_not_phone' => 'Do Not Phone',
- 'do_not_sms' => 'Do Not Sms',
- 'do_not_trade' => 'Do Not Trade',
- 'email_greeting_id' => 'Email Greeting',
- 'email_greeting_custom' => 'Email Greeting Custom',
- 'external_identifier' => 'External Identifier',
- 'image_URL' => 'Image Url',
- 'is_opt_out' => 'No Bulk Emails (User Opt Out)',
- 'postal_greeting_id' => 'Postal Greeting',
- 'postal_greeting_custom' => 'Postal Greeting Custom',
- 'preferred_communication_method' => 'Preferred Communication Method',
- 'communication_style_id' => 'Communication Style',
- 'signature_html' => 'Signature Html',
- 'signature_text' => 'Signature Text',
**Marginal (laymans' term) **
- 'geo_code_1' => 'Latitude',
- 'geo_code_2' => 'Longitude',
- 'master_id' => 'Master Address ID',
<details>
<summary>Full list - excluding custom fields</summary>
```
/**
* Get the list of supportedFields to test against.
*
* This is a statically maintained (in this test list).
*
*/
public function getSupportedFields() {
return [
'civicrm_address' =>
[
'name' => 'Address Name',
'city' => 'City',
'country_id' => 'Country',
'county_id' => 'County',
'geo_code_1' => 'Latitude',
'geo_code_2' => 'Longitude',
'master_id' => 'Master Address ID',
'postal_code' => 'Postal Code',
'postal_code_suffix' => 'Postal Code Suffix',
'state_province_id' => 'State',
'street_address' => 'Street Address',
'supplemental_address_1' => 'Supplemental Address 1',
'supplemental_address_2' => 'Supplemental Address 2',
'supplemental_address_3' => 'Supplemental Address 3',
],
'civicrm_contact' =>
[
'addressee_id' => 'Addressee',
'addressee_custom' => 'Addressee Custom',
'id' => 'Contact ID',
'source' => 'Contact Source',
'contact_sub_type' => 'Contact Subtype',
'do_not_email' => 'Do Not Email',
'do_not_mail' => 'Do Not Mail',
'do_not_phone' => 'Do Not Phone',
'do_not_sms' => 'Do Not Sms',
'do_not_trade' => 'Do Not Trade',
'email_greeting_id' => 'Email Greeting',
'email_greeting_custom' => 'Email Greeting Custom',
'external_identifier' => 'External Identifier',
'image_URL' => 'Image Url',
'legal_identifier' => 'Legal Identifier',
'legal_name' => 'Legal Name',
'nick_name' => 'Nickname',
'is_opt_out' => 'No Bulk Emails (User Opt Out)',
'organization_name' => 'Organization Name',
'postal_greeting_id' => 'Postal Greeting',
'postal_greeting_custom' => 'Postal Greeting Custom',
'preferred_communication_method' => 'Preferred Communication Method',
'preferred_language' => 'Preferred Language',
'sic_code' => 'Sic Code',
'user_unique_id' => 'Unique ID (OpenID)',
'sort_name' => 'Sort Name',
'communication_style_id' => 'Communication Style',
],
'civicrm_email' =>
[
'email' => 'Email',
'signature_html' => 'Signature Html',
'signature_text' => 'Signature Text',
],
'civicrm_im' =>
[
'name' => 'IM Screen Name',
],
'civicrm_note' =>
[
'note' => 'Note',
],
'civicrm_openid' =>
[
'openid' => 'OpenID',
],
'civicrm_phone' =>
[
'phone_numeric' => 'Phone',
'phone_ext' => 'Phone Extension',
],
'civicrm_website' =>
[
'url' => 'Website',
],
];
}
```
</details>
'sic_code' => 'Sic Code',
'user_unique_id' => 'Unique ID (OpenID)',https://lab.civicrm.org/dev/core/-/issues/3148Dedupe with multi-select custom fields can trigger IDS2023-03-18T04:20:40ZJonGoldDedupe with multi-select custom fields can trigger IDSWhen deduping contacts that have multi-select custom fields, and selecting to move the custom fields to the new contact, the IDS is triggered.
### Steps to replicate
* Create a custom field that allows saving multiple values (e.g. a che...When deduping contacts that have multi-select custom fields, and selecting to move the custom fields to the new contact, the IDS is triggered.
### Steps to replicate
* Create a custom field that allows saving multiple values (e.g. a checkbox). Note that you need several of these to trigger the "kick" on the IDS (3, I think).
* Create two contacts that are duplicates.
* Find and merge the records.
### Expected result
Contacts merged successfully.
### Actual result
"Your activity is a bit suspicious, hence aborting"
The issue is the POST request, which is passing arguments like `move_custom_12` with the `VALUE_SEPARATOR` control character. This triggers the IDS filter labeled "Detects nullbytes and other dangerous characters".
I'm really not certain what the correct answer is here - I can exempt users from the IDS, and maybe that's the solution to pursue, but it seems like there should be another solution available. Is it possible to exempt certain paths from the IDS, or use an alternate set of rules for a certain path?
Keyword: Intrusion Detection Systemhttps://lab.civicrm.org/dev/core/-/issues/2966Duplicate contacts when custom field value is 'email', 'phone', etc.2023-03-18T04:08:01Zrita_compucorpDuplicate contacts when custom field value is 'email', 'phone', etc.**Issue**:
when existing contacts are donating (without being logged in) with the same details (email, first name, last name) that are registered in the system, most of the times there is a new contact created instead of merging it to t...**Issue**:
when existing contacts are donating (without being logged in) with the same details (email, first name, last name) that are registered in the system, most of the times there is a new contact created instead of merging it to the existing contact automatically.
**Investigation**:
When a custom field with a checkbox had its title and value set to ‘email’ or 'phone' and the unsupervised dedupe rule was prepared to check for email or phone as well causing the problem. So the problem occurs when:
- the unsupervised dedupe rule has email in it AND
- the custom field’s value is set to ‘email’
However not only the email option can cause duplications, but if you prepare an:
- unsupervised dedupe rule with phone ![screenshot-dmaster.demo.civicrm.org-2021.11.22-08_34_24](/uploads/758592a6d5330c1133dcd1206e714daa/screenshot-dmaster.demo.civicrm.org-2021.11.22-08_34_24.png) AND
- the custom field’s value is set to ‘phone’ ![screenshot-dmaster.demo.civicrm.org-2021.11.22-08_35_12](/uploads/df40ee69692fda55f51e946b2c841b9d/screenshot-dmaster.demo.civicrm.org-2021.11.22-08_35_12.png)
And even though the clients enter the same email/phone numbers on the donation form, the dedupe rule will be skipped and a new contact with the same information will be created. Probably this can be reproduced with many fields in the system, but only tried these two.
I checked on a few **different civi versions:**
- 4.7.26 - couldn’t reproduce
- 5.35.2 - issue reproducible
- 5.45.alpha1 (core demo civi) - issue reproducible
**Reproduction steps:**
1. create an unsupervised individual rule with the following details: ![screenshot-dmaster.demo.civicrm.org-2021.11.22-08_34_24](/uploads/758592a6d5330c1133dcd1206e714daa/screenshot-dmaster.demo.civicrm.org-2021.11.22-08_34_24.png)
2. create a custom field set for Contacts with checkboxes like this: ![screenshot-dmaster.demo.civicrm.org-2021.11.22-08_35_12](/uploads/df40ee69692fda55f51e946b2c841b9d/screenshot-dmaster.demo.civicrm.org-2021.11.22-08_35_12.png)
3. add the custom field set that you created in previous step to a profile that can be added to a contribution page
4. create a new (or use an old) contribution page and add the profile that you created in previous step to it in the Profiles tab
5. create a new contact, and make sure it has a First name, Last name and Phone number
6. open the contribution page as anonymous and donate to it, using the exact same First name, Last name and Phone number that you entered in previous step AND select the ‘phone’ option at the custom field you created → _after you submit the donation, a new contact will be created instead of merging it to the existing one, which is wrong behaviour_
7. donate again on the same form, with the same details as before, but instead of selecting ‘phone’ select either the ‘email’ or ‘post’ options → _the contribution will be merged to the original contact, which is the correct behaviour. It is because email and post are not added to the unsupervised dedupe rule in this case._
I think most of the time civi admins create custom fields with values set as numbers, but in some cases they might configure it to be the same as the label name and in that case duplications might occur. I think it might be happening when the value of the custom field is the same as the name of the field in the database (just a thought, can't say for sure).https://lab.civicrm.org/dev/core/-/issues/2357CiviCRM Dedupe Rules, default rules are incorrectly labelled as "and" when ea...2023-03-18T04:18:24Zjustinfreeman (Agileware)CiviCRM Dedupe Rules, default rules are incorrectly labelled as "and" when each rule is actually "or" eg. "Name and Email" should be "Name OR Email". Use of Name is ambiguous. Add "Nickname" to default Organisation dedupe rulesCiviCRM Dedupe Rules, default rules are incorrectly labelled as "and" when each rule is actually "or" eg. "Name and Email" should be "Name OR Email". Use of Name is ambiguous. Add "Nickname" to default Organisation dedupe rules.
Additio...CiviCRM Dedupe Rules, default rules are incorrectly labelled as "and" when each rule is actually "or" eg. "Name and Email" should be "Name OR Email". Use of Name is ambiguous. Add "Nickname" to default Organisation dedupe rules.
Additionally, Name is ambiguous in the context of Household and Organisation Contacts. Should be Household Name and Organisation Name. Organisations for example have Organisation Name and Nickname.
Suggested changes:
1. Change label to use "or" to match the dedupe criteria when or logic applies.
2. Remove ambiguity and be explicit about Name, ie. Household Name, Organisation Name and for Individuals: First Name and Last Name.
3. Add Nickname field to default Organisation dedupe rules.
![Screenshot_20210204_090434](/uploads/0c5b3b687825535aea7e8f0fdc814bf7/Screenshot_20210204_090434.png)
Agileware Ref: CIVICRM-1660https://lab.civicrm.org/dev/core/-/issues/1783Wrong Employer Relationship retained on Merge.2023-03-18T06:41:18ZtommyboboWrong Employer Relationship retained on Merge.Overview
----------------------------------------
If Current Employer record is update to a duplicate that is later merged this results in an inactive relationship being the only employer relationship retained.
Tested on 5.25 but I am ...Overview
----------------------------------------
If Current Employer record is update to a duplicate that is later merged this results in an inactive relationship being the only employer relationship retained.
Tested on 5.25 but I am seeing evidence of this issue going back to 2017.
Reproduction steps
----------------------------------------
1. Contact A has a Current Employer of "Organization 1"
1. They make a contribution and set employer to "Organization One"
1. This sets the relationship to 1 to inactive.
1. CiviCRM Admin notices the error and merges "Organization One" into "Organization 1"
1. CiviCRM Merge saves the inactive "Organization 1" relationship deletes the active "Organization One" to prevent a duplicate, but saves "Organization One" to the Current Employer field.
1. Contact Record is left with inactive employer relationship.
Current behavior
----------------------------------------
CiviCRM is giving preference to Relationships in the retained record during a merge.
It should give preference to Active relationships if there is a conflict.
This may be minor, but a Current Employer fields are a significant source of duplicate records.https://lab.civicrm.org/dev/core/-/issues/960Proposal: Change supervised dedupe rules to name(s) OR email2023-03-18T04:52:01ZJonGoldProposal: Change supervised dedupe rules to name(s) OR emailI've done countless Civi trainings on deduping, many at CiviCamps and other "official" places. And each time, I need to explain that "yes, unsupervised rules should be more strict than supervised rules. Also yes, the default individual...I've done countless Civi trainings on deduping, many at CiviCamps and other "official" places. And each time, I need to explain that "yes, unsupervised rules should be more strict than supervised rules. Also yes, the default individual supervised rule is far more strict than the default unsupervised rule."
Surely I'm not the only one who feels the same - and yet none of us noticed, because before Civi 5.3/CRM-20565, the supervised rule was basically unused.
Now, there's a code comment that says, [CRM-20565 - Need a good default matching rule before using the dedupe engine for checking on-the-fly.](https://github.com/civicrm/civicrm-core/blob/1eca040f3f6efa0a8a43575cd0a08bae242a95f3/templates/CRM/Contact/Form/Contact.tpl#L334).
I'm proposing we fix this by changing the default supervised rule. The current on-the-fly checking is both a) a default, and b) very poor UX.
I'm also proposing that we do this as the new default for everyone. I'm mindful of the changes to existing systems, and we should probably put in an upgrade note or something - but honestly anyone who's never changed the default supervised rules isn't very likely to be using them.JonGoldJonGold