CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-06-19T14:08:48Zhttps://lab.civicrm.org/dev/core/-/issues/2342Search builder (NOT search kit) - Contribution search uses deprecated functio...2023-06-19T14:08:48ZDaveDSearch builder (NOT search kit) - Contribution search uses deprecated function CRM_Core_BAO_Query::getFieldName1. Search - Search Builder (not Search kit)
1. Do a contribution search. Let's say for Financial Type = Donation.
1. User deprecated function: Deprecated function CRM_Core_BAO_Query::getFieldName, use These parameters should be standardi...1. Search - Search Builder (not Search kit)
1. Do a contribution search. Let's say for Financial Type = Donation.
1. User deprecated function: Deprecated function CRM_Core_BAO_Query::getFieldName, use These parameters should be standardised before we get here. in CRM_Core_Error::deprecatedWarning() (line 1053 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Error.php).
1. The way deprecatedWarning works it loses the backtrace, but if you trace it it looks like this:
```
2 ...\CRM\Core\BAO\Query.php(97): CRM_Core_Error::deprecatedFunctionWarning("These parameters should be standardised before we get here")
3 ...\CRM\Contribute\BAO\Query.php(140): CRM_Core_BAO_Query::getFieldName((Array:5))
4 ...\CRM\Contribute\BAO\Query.php(114): CRM_Contribute_BAO_Query::whereClauseSingle((Array:5), Object(CRM_Contact_BAO_Query))
5 ...\CRM\Core\Component.php(284): CRM_Contribute_BAO_Query::where(Object(CRM_Contact_BAO_Query))
6 ...\CRM\Contact\BAO\Query.php(2061): CRM_Core_Component::alterQuery(Object(CRM_Contact_BAO_Query), "where")
7 \CRM\Contact\BAO\Query.php(574): CRM_Contact_BAO_Query->whereClause(FALSE)
8 ...\CRM\Contact\BAO\Query.php(523): CRM_Contact_BAO_Query->initialize(NULL)
9 ...\CRM\Contact\Selector.php(218): CRM_Contact_BAO_Query->__construct((Array:1), (Array:4), (Array:114), FALSE, FALSE, 1, FALSE, FALSE, FALSE, NULL, (Array:3))
10 ...\CRM\Contact\Form\Search.php(829): CRM_Contact_Selector->__construct(NULL, (Array:8), (Array:1), (Array:4), 8192, FALSE, FALSE, "builder", (Array:11))
11 ...\CRM\Contact\Form\Search\Builder.php(399): CRM_Contact_Form_Search->postProcess()
12 ...\CRM\Core\Form.php(513): CRM_Contact_Form_Search_Builder->postProcess()
```https://lab.civicrm.org/dev/core/-/issues/2317CiviMail, Tracked Opens and Unique Opens should also be counted when click-th...2023-06-17T00:00:49Zjustinfreeman (Agileware)CiviMail, Tracked Opens and Unique Opens should also be counted when click-through events occurs to workaround issues where the tracked open, pixel is blocked by the email clientCiviMail, Tracked Opens and Unique Opens should also be counted when click-through events occurs to workaround issues where the tracked open, pixel is blocked by the email client. Thus enabling some statistics to be captured and avoid si...CiviMail, Tracked Opens and Unique Opens should also be counted when click-through events occurs to workaround issues where the tracked open, pixel is blocked by the email client. Thus enabling some statistics to be captured and avoid situations where Tracked Opens and Unique Opens have a statistic of 0 but all the other metrics have non-zero numbers.
PS. I had always thought that this was already the case, but discovered otherwise whilst investigating a support request. Quite surprised.
This would also require a documentation change.
Agileware Ref: CIVICRM-1649https://lab.civicrm.org/dev/core/-/issues/2290Look at REMOVING id column from cache tables2022-12-13T11:58:44ZjitendraLook at REMOVING id column from cache tablesThis is a continuation of the "In Progress" JIRA https://issues.civicrm.org/jira/browse/CRM-19385
which aimed at removing the id from the cache tables but unfortunately was never completed since I see we still have id column in all the ...This is a continuation of the "In Progress" JIRA https://issues.civicrm.org/jira/browse/CRM-19385
which aimed at removing the id from the cache tables but unfortunately was never completed since I see we still have id column in all the cache tables.
```
civicrm_acl_cache
civicrm_acl_contact_cache
civicrm_cache
civicrm_group_contact_cache
civicrm_prevnext_cache
civicrm_relationship_cache
```
Related PRs -
- https://github.com/civicrm/civicrm-core/pull/9743 (Closed)
- https://github.com/civicrm/civicrm-core/pull/9801 (Closed)
- https://github.com/civicrm/civicrm-core/pull/10019 (Merged) - This removed the dependency in the code so think we can start by removing the column directly.
Thoughts @eileen @johnkhttps://lab.civicrm.org/dev/core/-/issues/2266Wording beside on-behalf-of checkbox isn't required, but has no default eithe...2023-11-23T07:25:09ZDaveDWording beside on-behalf-of checkbox isn't required, but has no default either, so appears as a mysterious checkboxI'm not sure yet if this is recent. I remember there being a default but it's not a strong memory.
1. Create a contribution page.
1. On the title page there's a choice to "Allow individuals to contribute and / or signup for membership o...I'm not sure yet if this is recent. I remember there being a default but it's not a strong memory.
1. Create a contribution page.
1. On the title page there's a choice to "Allow individuals to contribute and / or signup for membership on behalf of an organization". Check it.
1. In the section that appears there's a box for a label that has no default and is not required. Leave it blank.
1. Finish off the rest of the settings - doesn't matter too much what.
1. Visit the contribution page. It looks like this:
![Untitled](/uploads/4776b6636a1ea3fb9106face184bd545/Untitled.png)
It's easily fixable by adding words in the label box, but it just a seems a wrong default and I don't remember it coming up as a problem before.
I notice the label box is a textarea for some reason. Maybe it used to be a normal textbox and so the default now isn't getting set correctly?
Also ignore the decimal places in the dollar amounts in the screenshot - that's a known windows issue with civi.https://lab.civicrm.org/dev/core/-/issues/2255Proposal, Allow the CiviCRM CKEditor to be disabled for specific components a...2023-06-07T05:38:36Zjustinfreeman (Agileware)Proposal, Allow the CiviCRM CKEditor to be disabled for specific components as there is only a global on/off capability currently. We need CKEditor to be disabled for Message Templates, but not for Mailings, Events etc.Proposal, Allow the CiviCRM CKEditor to be disabled for specific components as there is only a global on/off capability currently. We need CKEditor to be disabled for Message Templates, but not for Mailings, Events etc.
CKEditor is alwa...Proposal, Allow the CiviCRM CKEditor to be disabled for specific components as there is only a global on/off capability currently. We need CKEditor to be disabled for Message Templates, but not for Mailings, Events etc.
CKEditor is always displayed for custom Message Templates which in our experience reliably mangles the HTML and Smarty Tags. CKEditor is NOT disabled for "System" Message Templates and therefore does not have this issue.
Agileware Ref: CIVICRM-1609 CIVICRM-1608https://lab.civicrm.org/dev/core/-/issues/2237Provide some way for an extension's database tables to automatically get incl...2022-08-24T18:56:45ZDaveDProvide some way for an extension's database tables to automatically get included when a site runs utf8mb4 conversionThere's an option in the api call / api explorer when running the utf8mb4 conversion to specify some tablename patterns, but this requires the user to know what the tables are that all their extensions create.
One idea is a hook that le...There's an option in the api call / api explorer when running the utf8mb4 conversion to specify some tablename patterns, but this requires the user to know what the tables are that all their extensions create.
One idea is a hook that lets an extension advertise the names of tables it creates. If it wants to manage the charset itself for a table then it can just not list it.
Another is a standard naming like civicrm_ext_FOO, which then core knows not to conflict for its own tables, but which starts with civicrm so gets picked up by default.
Open to other ideas. The status quo is also technically an option. And it's only important if there's some connection between text data in the extension's tables and core tables, or it stores emojis and such.https://lab.civicrm.org/dev/core/-/issues/2195Custom fields of type money and drop-down list with round numbers don't updat...2023-07-04T12:55:04ZDaveDCustom fields of type money and drop-down list with round numbers don't update existing values when you change the option valueCame up reviewing https://github.com/civicrm/civicrm-core/pull/18959
For example:
1. Edit or create a custom field group for contacts.
1. Add a custom field of type money and make it a drop-down select list.
1. For the values, make cho...Came up reviewing https://github.com/civicrm/civicrm-core/pull/18959
For example:
1. Edit or create a custom field group for contacts.
1. Add a custom field of type money and make it a drop-down select list.
1. For the values, make choice 1 have value 10 and choice 2 have value 20.
1. Create a contact and pick one of the choices. Save.
1. Note that in the database in the civicrm_value_XX table this has been stored as 10.00, with the decimals. Note that in civicrm_option_value that the choice is stored as 10, without the decimals.
1. Go and edit the option value and change the value to anything else.
1. What's supposed to happen is that the contact's custom field values should be updated to match. But because of the mismatch above it doesn't change it in civicrm_value_XX and it now appears blank when viewing the contact.
I don't think this is recent.https://lab.civicrm.org/dev/core/-/issues/2163log_date is missing on logging detail report2023-05-26T16:05:01ZDaveDlog_date is missing on logging detail report1. Turn on logging at Admin - System Settings - Misc.
2. Update a contact.
3. Go to the logging summary civireport.
4. Click on "Update" in the row for your update.
5. At the top of the detail report it will say something like `Change to...1. Turn on logging at Admin - System Settings - Misc.
2. Update a contact.
3. Go to the logging summary civireport.
4. Click on "Update" in the row for your update.
5. At the top of the detail report it will say something like `Change to blah made by somebody on :`
6. It's supposed to show the modified date at the end.
It's coming from [this check](https://github.com/civicrm/civicrm-core/blob/4d660b8e1e6ac980a06b096fbc4cde1e1666e0b9/CRM/Report/Form/Contact/LoggingSummary.php#L193) which decides the log date isn't needed. The comment when that check was added says it can make the report less accurate because of some older data that used to be the way things were logged. So I'm hesitant to just remove that check.
Some other options include passing it but with a different name, and then in the detail report know that that new name is just used in intro text. Or looking it up in the detail report.
TBD.
@VangelisP just FYI.https://lab.civicrm.org/dev/core/-/issues/2157Array to string conversion in DB_DataObject when doing on behalf of and no st...2023-05-26T16:13:04ZDaveDArray to string conversion in DB_DataObject when doing on behalf of and no state/provinceIf you submit a contribution on behalf of an org and leave the state/province blank, you get `Notice: Array to string conversion in DB_DataObject->_build_condition() (line 2903 of .../web/sites/all/modules/civicrm/packages/DB/DataObject....If you submit a contribution on behalf of an org and leave the state/province blank, you get `Notice: Array to string conversion in DB_DataObject->_build_condition() (line 2903 of .../web/sites/all/modules/civicrm/packages/DB/DataObject.php)`
(At the moment to see this you need to make the field not required on the profile, but it happens either way it's just there's currently a separate issue when the field is required and the country has no state/provinces.)
What happens is that at that code line `$this->name` and `$this->abbreviation` contain a big long list of numbers and letters, including, oddly, the strings "_A", "_B", "_C", etc, but ONLY up to "_P".https://lab.civicrm.org/dev/core/-/issues/2107scheduled reminders incorrectly exclude emails with on_hold = opt-out2023-05-20T05:50:59Zlcdwebscheduled reminders incorrectly exclude emails with on_hold = opt-outTo reproduce:
1. create a contact with an email and flag it on_hold = opt out
2. create a scheduled reminder that can be easily triggered. e.g. on creation of a scheduled activity
3. create the conditions for the scheduled reminder (e.g....To reproduce:
1. create a contact with an email and flag it on_hold = opt out
2. create a scheduled reminder that can be easily triggered. e.g. on creation of a scheduled activity
3. create the conditions for the scheduled reminder (e.g. create a scheduled activity of the selected type)
4. run the scheduled reminder job
Result: the contact will not receive the scheduled reminder because it skips email addresses with on_hold of either type (either bound or opt out).
Expected result: contact receives email.
This is worth some discussion as I know scheduled reminders sometimes fall into a grey area between bulk email and transactional email. Personally I believe they are more transactional than bulk, and believe we have historically viewed them that way.
The offending code is in: CRM_Contact_BAO_Contact::getPrimaryEmail(). That method has a parameter $polite = (bool) which is only used once in the codebase when called by CRM_Core_BAO_ActionSchedule::sendReminderEmail(). When that is true we condition on civicrm_email.on_hold = 0. I believe it should be civicrm_email.on_hold != 1 (doesn't equal bounce). As it's the only place that parameter/condition is used, we just need to decide if scheduled reminders are indeed transactional and should not exclude opt outs.
It's worth noting that the condition in that function also excludes civicrm_contact.do_not_email but does NOT exclude civicrm_contact.is_opt_out. We're not currently treating it like a bulk email at the contact level -- just at the email level.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/2083If using the email processor to file inbound emails on cases via subject, it ...2022-09-27T16:29:36ZDaveDIf using the email processor to file inbound emails on cases via subject, it can file it on the wrong case on even moderately large sitesCame up as a side-thought while testing https://github.com/civicrm/civicrm-core/pull/18624.
On Manage Case, in the case roles section, you can send an outbound email to people by clicking the mail icon. In this context, civi will add a ...Came up as a side-thought while testing https://github.com/civicrm/civicrm-core/pull/18624.
On Manage Case, in the case roles section, you can send an outbound email to people by clicking the mail icon. In this context, civi will add a hash to the subject. If you've set up the inbound email processor, you can autofile responses onto cases since it will try to match the hash.
The problem is the algorithm used for the hash stops being unique at some point, and so matches a different case. It turns out you're almost guaranteed hash collisions on a site with 20000 cases. The exact first collision depends on CIVICRM_SITE_KEY which is different for every site. In fact for the site_key on a dev site where I was testing the PR you get the first collision around 11000 cases.
The easy solution is stop using substrings of hashes and just use case id as has been requested several times over the years and there's an extension that does this (self-promo): https://lab.civicrm.org/extensions/caseidinsubject
(Further promo: It also lets you remove the hash completely.)
Civi would still need to accept the 7-character version for inbound emails since there will be a (possibly lengthy) period of time where external recipients will still reply to older emails with the 7-character hash in the subject. But eventually that could be moved to an extension for anyone who wants to support it for longer.
For some background on why it's a hash, I've mentioned in several places that I vaguely recall this being a misunderstanding during initial development. Well-meant, as a privacy thought, but not necessary.
If there's desire to still have a hash, an obvious alternate solution is use a bigger substring or the whole string. In theory this could also be done by an extension.https://lab.civicrm.org/dev/core/-/issues/2081Proposal: Extension upgrades should reconcile managed entities2023-01-19T22:49:26ZJonGoldProposal: Extension upgrades should reconcile managed entitiesWhen you install a new extension, `CRM_Extension_Manager::install()` contains this line:
```php
CRM_Core_Invoke::rebuildMenuAndCaches(TRUE);
```
However, no equivalent code runs on extension upgrade.
I propose that on extension up...When you install a new extension, `CRM_Extension_Manager::install()` contains this line:
```php
CRM_Core_Invoke::rebuildMenuAndCaches(TRUE);
```
However, no equivalent code runs on extension upgrade.
I propose that on extension upgrade, we run this code.
Recently, I've had two different extensions fail to work on deployment because the upgrade process doesn't reconcile managed entities. I imagine I'm not alone.https://lab.civicrm.org/dev/core/-/issues/2074Case activity assignees receive an email copy every time activity is edited2023-05-16T12:45:13ZDaveDCase activity assignees receive an email copy every time activity is editedNot sure yet when this changed. It used to only send newly added assignees an email. Investigating...Not sure yet when this changed. It used to only send newly added assignees an email. Investigating...https://lab.civicrm.org/dev/core/-/issues/2048Rename crmStripAlternatives function and its friend CRM_Utils_String::stripAl...2023-05-05T14:13:30ZDaveDRename crmStripAlternatives function and its friend CRM_Utils_String::stripAlternativesIt's not used much at least in core, and it's not clear from the name what it does, and there's potential for it to be mistaken as a security function.
I'd suggest something like getFirstEmailMultipart or stripAlternativeEmailMultiparts.It's not used much at least in core, and it's not clear from the name what it does, and there's potential for it to be mistaken as a security function.
I'd suggest something like getFirstEmailMultipart or stripAlternativeEmailMultiparts.https://lab.civicrm.org/dev/core/-/issues/2021Contribution receipt has donor's name printed twice, once with non-printable ...2023-11-23T07:22:03ZBobSContribution receipt has donor's name printed twice, once with non-printable charactersOverview
----------------------------------------
Contribution receipts, notably those created with the Stripe extension, display the donor's information as follows:
```
Jane�Mary�Smith <$first . \x01 . $middle . \x01 . $last>
...Overview
----------------------------------------
Contribution receipts, notably those created with the Stripe extension, display the donor's information as follows:
```
Jane�Mary�Smith <$first . \x01 . $middle . \x01 . $last>
Jane Mary Smith <$first . \x20 . $middle . \x20 . $last>
123 Main St
...
```
The two \x01 characters (ASCII SOH, CRM_Core_DAO::VALUE_SEPARATOR) are displayed as boxes in some email clients, although they aren't displayable in this bug report.
The message template "Contributions - Receipt (on-line)" includes:
```
{if $billingName}
<tr>
<th {$headerStyle}>
{ts}Billing Name and Address{/ts}
</th>
</tr>
<tr>
<td colspan="2" {$valueStyle}>
{$billingName}<br />
{$address|nl2br}<br />
{$email}
</td>
</tr>
{elseif $email}
```
For Stripe contributions, $billingName contains the first/middle/last names separated by SOH characters, as found in civicrm_address.name. The {if $billingName} block therefore gets printed, including both $billingName and the $address variable which contains the second instance of the donor's name, followed by their address.
The SOH characters in the first line of $address (the donor's name) are replaced with spaces in CRM_Core_BAO_Address::addDisplay().
Contributions via Paypal standard, in contrast, do not display the $billingName block as addresses created that way store NULL in civicrm_address.name.
Reproduction steps
----------------------------------------
1. Create a contribution with CiviCRM Stripe extension v. 6.4.2.
1. Observe the Billing Name and Address section of the emailed receipt.
Current behaviour
----------------------------------------
The donor's name is printed twice. Once with SOH separators, and again with spaces. If the middle name is blank, the second instance contains two spaces between first and last name.
Expected behaviour
----------------------------------------
The name should be printed once, with a single space between non-blank name components.
Additional comments
----------------------------------------
1. Perhaps the fix is to simply remove "$billingName\<br \/\>" from the template(s). Ideally, the double spaces in the case of a null middle name should be corrected also.
2. Event and Membership templates seem to have the same structure as the template shown above.
3. The Thank You page displays the donor's name as expected -- only once, with a single \x20 character between first and last name.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __CiviCRM:__ 5.28.2
* __CiviCRM Stripe extension__ v. 6.4.2
* __mjwshared extension__ v. 0.8.1
* __PHP:__ 7.3
* __CMS:__ Drupal 7.72https://lab.civicrm.org/dev/core/-/issues/1984Sometimes Custom fields missing on profile2023-06-05T20:22:11ZPradeep Nayakpradpnayak@gmail.comSometimes Custom fields missing on profileCustom fields are not rendered on profile front end pages like contribution or event pages. As soon as civi cache is cleared they start appearing.
```
Php - 7.3
opcahe disabled
Clean-up Temporary Data and Files schedule job executed hou...Custom fields are not rendered on profile front end pages like contribution or event pages. As soon as civi cache is cleared they start appearing.
```
Php - 7.3
opcahe disabled
Clean-up Temporary Data and Files schedule job executed hourly by cron job
```https://lab.civicrm.org/dev/core/-/issues/1948Print Report from Manage Case shows relationships from client's other cases2023-07-03T18:38:08ZDaveDPrint Report from Manage Case shows relationships from client's other casesNot sure yet when it started.
1. Create two cases for a client with different case managers assigned.
2. Click on Print Report on Manage Case for either case.
3. It lists the case manager from the other case in the Client Relationships ...Not sure yet when it started.
1. Create two cases for a client with different case managers assigned.
2. Click on Print Report on Manage Case for either case.
3. It lists the case manager from the other case in the Client Relationships section.https://lab.civicrm.org/dev/core/-/issues/1931Paypal Standard IPNs not being correctly handled leaving contributions as Pen...2023-06-01T19:13:12ZUpperholmePaypal Standard IPNs not being correctly handled leaving contributions as Pending (incomplete transaction)Overview
----------------------------------------
My client recently reported that payment records in CiviCRM were not being automatically marked as paid/completed despite the fact that they were successfully completed and listed in the ...Overview
----------------------------------------
My client recently reported that payment records in CiviCRM were not being automatically marked as paid/completed despite the fact that they were successfully completed and listed in the Paypal account. On investigating the issue it was clear that the IPNs were failing.
I updated the CiviCRM install to 5.27.0 to see if this would resolve the issue. It didn't. Yesterday I updated again to 5.27.4. Still no change.
The issue appears identical to this case reported on Stackexchange: https://civicrm.stackexchange.com/questions/37277/paypal-standard-payments-are-being-accepted-but-marked-as-incomplete-transaction
I tried adding the patch referred to in Eileen's comment, but it looks like the effect of that has been to remove any information from the log pertaining to the IPN.
I've double checked the IPN URL provided to Paypal. If I point my browser to this URL I get the message:
```
Failure: Missing Parameter
module
```
The CMS is Wordpress 5.3.25.31.1haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/1926Finish allowing use of SSL to connect to database2023-07-24T03:44:31ZDaveDFinish allowing use of SSL to connect to databaseFollowing on to complete what's left for https://lab.civicrm.org/dev/core/-/issues/1137, there are a couple confusing things so I'm listing them to try to get a handle on them:
| thing | comment
| ---- | ----
| [CRM_Utils_File](https://...Following on to complete what's left for https://lab.civicrm.org/dev/core/-/issues/1137, there are a couple confusing things so I'm listing them to try to get a handle on them:
| thing | comment
| ---- | ----
| [CRM_Utils_File](https://github.com/civicrm/civicrm-core/blob/6eced9e6cedd66769757a30415a4c6c99fd0d231/CRM/Utils/File.php#L327) | This block seems to do almost the same thing as CRM_Core_DAO::init(), but not completely, but I think also has a "bug" where it wipes the sql_mode instead of updating it. This is called from e.g. the upgrade process, but it's not clear yet why that would require its own thing, since civi is already installed. Will test this out and see.
| [CRM_Utils_System::authenticate](https://github.com/civicrm/civicrm-core/blob/da6c68c61ab13ba434a5061701c3acfd8676cc29/CRM/Utils/System.php#L727) | It calls DB::connect assuming it's already available, and then does nothing with it, and then a couple milliseconds later the UF class does it again. Is this just leftover from refactoring, maybe as suggested in the comment a couple lines above. Additionally, only drupal 7 seems to use it, but it's not clear if it's really necessary and why can't it just use cms functions in the cms class, which it does in drupal 8 and the others.
| install/ | Would like to leave this out if the future plan is to move to a civicrm-setup variant. Otherwise it means adding fields to the form for example.https://lab.civicrm.org/dev/core/-/issues/1807on hold is not respected when two contacts have duplicate email2022-10-10T09:16:44ZIan Kellingon hold is not respected when two contacts have duplicate emailOverview
----------------------------------------
If you have group with two contacts that have the same email, a mailing
will only send to one of them. Then, if that email bounces with the
right classification, one of contacts will hav...Overview
----------------------------------------
If you have group with two contacts that have the same email, a mailing
will only send to one of them. Then, if that email bounces with the
right classification, one of contacts will have their email put on
hold. The next mailing will then ignore that status and send an email to
the other contact which has the same email address.
Reproduction steps
----------------------------------------
Create two contacts that both have a email that doesn't exist and will
produce a bounce that civi understands. Create a group with those two
contacts. Send one or more mailings, processing the bounce until the
contact goes on hold. Then send another mailing.
Current behavior
----------------------------------------
The mailing goes out to the email address that is on hold.
Expected behavior
----------------------------------------
The mailing does not go to the on hold email address.
Environment information
----------------------------------------
* __CiviCRM:__ 5.24.3 with patches that don't affect this issue,
available at https://agpl.fsf.org/crm.fsf.org/CURRENT/
Comments
----------------------------------------
We have many duplicate contacts our database, often 10+ duplicates, thus
making bounce processing require 10+ times more bounces, making bounce
processing very broken. Civi allows users to create contacts with
duplicate emails with the right profile settings, etc, so it should be
able to handle the result without breaking bounce processing.
We are using a rule in our email system to detect these emails
and avoid sending them, it checks if this count is greater than 0:
```
select count(*) FROM civicrm_email where email = REPLACEME and on_hold = 1;
```