CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-03-25T20:55:29Zhttps://lab.civicrm.org/dev/core/-/issues/5061New structure for getFields array in `.entityType.php`2024-03-25T20:55:29ZcolemanwNew structure for getFields array in `.entityType.php`Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
No...Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
Note: This will not affect the output of `DAO::fields()` or `APIv(3|4).getFields`, as we'll add a compatibility layer and tests to ensure those remain unchanged. But since we're replacing the underlying source of the data with something new, we get to clean that up.
Here are all the current keys in the schema/xml files, and what we plan to do with it in the new file. Many of the proposed changes would improve consistency with APIv4.getFields.
| Old key from `xml` | What to do | New key in `php` | Notes |
| ------ | ------ | ------ | ------ |
| `<name>` | ⚠️ index by | | Use name as array key, omit from array values |
| `<title>` | ✅ keep | `title` | |
| `<required>` | ✅ keep | `required` | |
| `<add>` | ✅ keep | `add` | |
| `<pseudoconstant>` | ✅ keep | `pseudoconstant` | snake_case all values in array |
| `<default>` | ✅ keep | `default` | |
| `<contactType>` | ✅ keep | `contact_type` | |
| `<deprecated>` | ✅ keep | `deprecated` | |
| `<readonly>` | ✅ keep | `readonly` | |
| `<serialize>` | ✅ keep | `serialize` | |
| `<localizable>` | ✅ keep | `localizable` | |
| `<usage>` | ✅ keep | `usage` | |
| `<component>` | ✅ keep | `component` | Ok, but it smells bad to have columns belonging to one component in another component's table :nose: (fixme for another day) |
| `<localize_context>` | ✅ keep | `localize_context` | Obscure property only used by 3 fields, but it's easier to keep it. |
| `<type>` | ⚠️ rename | `sql_type` | |
| `<crmType>` | ⚠️ rename | `data_type` | Historically this was inferred by `<type>` but a few fields explicitly declare `<crmType>` |
| `<uniqueName>` | ⚠️ deprecate | `unique_name` | We can't get rid of it yet but we can discourage it & stop indexing by it at every layer except `DAO::fields()` |
| `<uniqueTitle>` | ⚠️ deprecate | `unique_title` | Are title & attributes[label] not enough? |
| `<comment>` | ⚠️ rename | `description` | |
| `<html>` | ⚠️ rename/reorganize | `attributes` | `type` gets moved out (see `<html><type>` below), while `length` gets moved in as `maxlength` |
| `<html><type>` | ⚠️ move/rename | `input_type` | |
| `<length>` | ⚠️ rename | `attributes[maxlength]` | That seems better. |
| `<import>` | ⚠️ move | `usage[import]` | |
| `<export>` | ⚠️ move | `usage[export]` | |
| `<foreignKey>` | ⚠️ move+reformat | `entity_reference` | This tag is outside of `<fields>` in the xml but doesn't need to be. Let's move it into the getFields array. |
| `<dynamicForeignKey>` | ⚠️ move+reformat | `entity_reference` | Conceptually the same as above so can share the same name. |
| `<permission>` | ⚠️ reformat | `permission` | Convert `<or>` tags to nested array format used by `CRM_Core_Permisison::check()`. |
| `<drop>` | ❌ remove | | `<drop>` designates a field has been dropped, but in that case let's just [remove it](https://github.com/civicrm/civicrm-core/pull/18244) from the array as nothing else was being done with it. |
| `<rule>` | ❌ remove | | Unused as of [PR#29611](https://github.com/civicrm/civicrm-core/pull/29611). |
| `<headerPattern>` | ❌ remove | | Unused as of [PR#29612](https://github.com/civicrm/civicrm-core/pull/29612). |
| `<dataPattern>` | ❌ remove | | Appears to be unused in `universe`. |
| `<fulltext/>` | ❌ remove | | Apparently unused. Ignored by GenCode when writing DAOs. |https://lab.civicrm.org/dev/core/-/issues/5028Add CKEditor/WYSIWYG to the Event Confirmation Email Text Field2024-02-28T12:47:28ZpbarmakAdd CKEditor/WYSIWYG to the Event Confirmation Email Text FieldPer a discussion with Eileen, it would be great to finally get the Confirmation Email Text field of Event Online Registrations to use CKEditor. That will allow admins to create much nicer confirmation emails (with embedded graphics and b...Per a discussion with Eileen, it would be great to finally get the Confirmation Email Text field of Event Online Registrations to use CKEditor. That will allow admins to create much nicer confirmation emails (with embedded graphics and branding) without the need to learn HTML. Given the Registration Screen Introductory Text and Thank-you Screen text both have this option, it seems like a good idea to also have it for the confirmation email.https://lab.civicrm.org/dev/core/-/issues/5020Provide support for the Peppol standard to send invoices from CiviCRM to othe...2024-03-18T15:29:58Zjustinfreeman (Agileware)Provide support for the Peppol standard to send invoices from CiviCRM to other organisationsThis is just a placeholder to see if there is any interest in providing support for the Peppol standard. Did some searching and couldn't find any mentions about this in Lab.
Basically, the idea is to provide support for the Peppol stand...This is just a placeholder to see if there is any interest in providing support for the Peppol standard. Did some searching and couldn't find any mentions about this in Lab.
Basically, the idea is to provide support for the Peppol standard to send invoices from CiviCRM to other organisations. See https://peppol.org/ and participating organisations will be listed here, https://directory.peppol.eu/publichttps://lab.civicrm.org/dev/core/-/issues/5015'Clean-up Temporary Data and Files' doesn't empty the tplCache by default2024-02-23T15:18:23ZAndrew West'Clean-up Temporary Data and Files' doesn't empty the tplCache by defaultThe 'Clean-up temporary data and files' scheduled job [doesn't clean the tpl directory by default](https://github.com/civicrm/civicrm-core/blob/06540d39dc2cedcadb19be5c351ef831a9133534/api/v3/Job.php#L631). Should it? We see this balloon...The 'Clean-up temporary data and files' scheduled job [doesn't clean the tpl directory by default](https://github.com/civicrm/civicrm-core/blob/06540d39dc2cedcadb19be5c351ef831a9133534/api/v3/Job.php#L631). Should it? We see this ballooning to tens of gigabytes when sending large mailings.
Workaround is to add the parameter, but it seems like this might catch some people out.
![image](/uploads/85b4275fb08070a8995fe094e32d466e/image.png)https://lab.civicrm.org/dev/core/-/issues/5000SearchKit: Allow formatting of the totals in the footer2024-02-14T10:06:39Zsimon.hermannSearchKit: Allow formatting of the totals in the footerSearchKit allows to create a footer row, where the total of a column can be displayed. However, this total does not allow for any formatting or reproduces the formatting of the columns it sums.
It would be great if there would be either ...SearchKit allows to create a footer row, where the total of a column can be displayed. However, this total does not allow for any formatting or reproduces the formatting of the columns it sums.
It would be great if there would be either an option to choose a formatting (decimal separators, thousand separators, currencies if applicable etc) or if the total would reflect the formatting of the column it sums.https://lab.civicrm.org/dev/core/-/issues/4982Form builder - Extension provided entity settings2024-02-14T09:53:44ZseamusleeForm builder - Extension provided entity settingsJMA is in the progress of working on a geographically targeted petition extension
At the moment we have some additional settings that we get a user to set when creating the petition page in Form Builder. These get injected by the alter ...JMA is in the progress of working on a geographically targeted petition extension
At the moment we have some additional settings that we get a user to set when creating the petition page in Form Builder. These get injected by the alter angular hook https://lab.jmaconsulting.biz/extensions/geotargetedpetitions/-/blob/main/geotargetedpetitions.php?ref_type=heads#L76 however this means that even on non petition related form builder forms they will show up.
This is about seeing if there is a better way to achieve this and or see if we can get them put onto the specific settings page for say GeotargetedPetition Entity.
@JoeMurray @Edselopez @colemanwhttps://lab.civicrm.org/dev/core/-/issues/4979Should `die()` be called when a DB Query fails?2024-02-14T09:49:16ZhaystackShould `die()` be called when a DB Query fails?Overview
----------------------------------------
As the title says, when a DB Query fails, `CRM_Utils_File::runSqlQuery()` [calls](https://github.com/civicrm/civicrm-core/blob/fd4913060d8e944a99abe30c22ba670ed0e51a9a/CRM/Utils/File.php#...Overview
----------------------------------------
As the title says, when a DB Query fails, `CRM_Utils_File::runSqlQuery()` [calls](https://github.com/civicrm/civicrm-core/blob/fd4913060d8e944a99abe30c22ba670ed0e51a9a/CRM/Utils/File.php#L327) `die()` and all script execution stop *ahem* dead. Is this intentional?
Reproduction steps
----------------------------------------
1. Install the "Deduper" Extension (v1.7) via the API (sorry @eileen :dove:)
1. See the unrecoverable error "**Cannot execute INSERT INTO civicrm_contact_name_pair_family (id, name_a, name_b, is_most_common_form, is_active) VALUES (65, 'Takahashi', '髙𣘺', 0, 1)**".
Current behaviour
----------------------------------------
There's no way to trap this and continue with a script that installs Extensions via the API.
Edit: apparently there [is a way](https://stackoverflow.com/a/16925225) but this seems a less than sensible way to go about trapping the error.
Expected behaviour
----------------------------------------
A script that installs Extensions via the API should be able to trap the error as an `Exception` with `try/catch` and act accordingly.https://lab.civicrm.org/dev/core/-/issues/4955Upgrade to Smarty52024-02-01T10:45:19ZeileenUpgrade to Smarty5Now that we have upgraded many sites to Smarty3 Smarty5 is on the cusp of being release....
See related issue https://lab.civicrm.org/dev/core/-/issues/4954 on getting to Smarty4
The upgrade from Smarty 3 or 4 to Smarty 5 has some mino...Now that we have upgraded many sites to Smarty3 Smarty5 is on the cusp of being release....
See related issue https://lab.civicrm.org/dev/core/-/issues/4954 on getting to Smarty4
The upgrade from Smarty 3 or 4 to Smarty 5 has some minor challenges.
https://smarty-php.github.io/smarty/5.x/upgrading/
1) assign_by_ref needs to be replaced with assign wherever it appears (yay I've been wanting to get rid of those)
2) some php-language modifiers will stop working without intervention (not sure how affected we are but if some are common it is easy to 'make them work')
3) before we can see / address the above there is a problem with our Smarty compatibility class. Our Smarty class has functions like `getTemplateVars()` to allow sites still on Smarty2 to call the v3 functions. That particular function has a different signature in Smarty5 so overriding it causes fatals
Proposal
1) Check Smarty5 into packages like Smarty4 - see https://github.com/civicrm/civicrm-packages/pull/380
2) the path fix in Smarty4 will allow easy switch to Smarty5 for developers
3) Move `getTemplateVars()` & any other functions in the same boat from being on our Smarty compatibility class to being 'hacked onto' the Smarty 2 code in our packages folder.
4) replace assign-by-ref with assign
- That should be enough to get us to the point where we can get dev sites to load and from there we can figure out if we have to scale a mountain or a molehill to move to Smarty5 instead of 3 or 4 when we do our force changehttps://lab.civicrm.org/dev/core/-/issues/4947Proposal: Store Contribution Page ID in the `civicrm_contribution_recur` table2024-02-01T10:23:33ZjaapjansmaProposal: Store Contribution Page ID in the `civicrm_contribution_recur` tableOverview
----------------------------------------
When a recurring contribution is created with a contribution page. Also store the contribution page ID in the `civicrm_contribution_recur` table.
This works already for 'normal' contrib...Overview
----------------------------------------
When a recurring contribution is created with a contribution page. Also store the contribution page ID in the `civicrm_contribution_recur` table.
This works already for 'normal' contribution.
Example use-case
----------------------------------------
1. CiviRules can be used when a new Contribution Recur is added and a condition can then be used which Contribution Page this came from.
Current behaviour
----------------------------------------
Currently for the 'normal' contributions the contribution page ID is stored in the `civicrm_contribution` table.
Proposed behaviour
----------------------------------------
1. Add a column to the `civicrm_contribution_recur` table called `contribution_page_id`
2. When a contribution recur is added through a Contribution Page then store the contribution page id into this column
3. Optional we can show the data from this field in the user interface when a user views a contribution recur
Workaround
----------------------------------------
There is a workaround with an extension: https://lab.civicrm.org/extensions/storecontributionpageidoncontribrecurjaapjansmajaapjansmahttps://lab.civicrm.org/dev/core/-/issues/4940Proposal to Change the Invoice date in the default Invoice message template t...2024-02-08T10:45:03ZeileenProposal to Change the Invoice date in the default Invoice message template to contribution.receive_dateThis spins off one discussion topic from https://lab.civicrm.org/dev/core/-/issues/1403 -
As part of our general effort to make the WorkflowMessage templates operate independently of the quickform layer (ie be available as actions from ...This spins off one discussion topic from https://lab.civicrm.org/dev/core/-/issues/1403 -
As part of our general effort to make the WorkflowMessage templates operate independently of the quickform layer (ie be available as actions from SearchKit etc) we should clarify which value is used for the invoice_date in the default message template that we ship from \`{$invoice_date}\`
```html
{domain.now|crmDate:"Full"}
or
{contribution.receive_date|crmDate:"Full"}
```
If we change the default it will affect new installs and un-customised templates. I'm not proposing any push upgrade on the customised templates at this stage so for most invoice-using sites this will be no change at this point. However, I am going to try to 'complete' the variable to token changes in this template so that anyone who is updating their customised template or installing a new site is using the tokens (& hence will be able to benefit from message previewability via MessageAdmin now & sending & rendering from outside QF if they install a relevant extension /when we add to core).
Potentially if we want to make it clear to people that they can change it we can use one of
```html
{domain.now|crmDate:"Full"}{* Code comment: - You can replace the domain.now token with this to show the contribution date instead {contribution.receive_date|crmDate:"Full"} *}
OR
{contribution.receive_date|crmDate:"Full"}{* Code comment: - You can replace the domain.now token with this to show the current date instead with {domain.now|crmDate:"Full"} *}
```
Note that the assumption in this gitlab is that any change would be opt in for existing sites (since basically everyone who uses invoices puts a logo in there). There is a proposal at https://github.com/civicrm/civicrm-core/pull/28630 that would force a change on everyone. I'm not convinced we should do a force update because it is pretty clear from the code & code history that the use of now was a deliberate attempt to meet a use case. However I have added an option to the emjoi poll below to allow people to vote for a forced update - basically a string_replace on upgrade.
EMOJI POLL Options
1) :boom: Change to {domain.now|crmDate:"Full"}
2) :man_dancing_tone2: Change to {contribution.receive_date|crmDate:"Full"}
3) :avocado: Change to 1 with additional in-code comments per above
4) :bellhop: Change to 2 with additional in code comments per above
5) :pick: Do 2 with a forced upgrade to replace {$invoice_date} with the above with {contribution.receive_date|crmDate:"Full"}https://lab.civicrm.org/dev/core/-/issues/4923Possible performance improvement: When a custom field is disabled, automatica...2024-02-08T14:11:58ZDaveDPossible performance improvement: When a custom field is disabled, automatically uncheck the searchable box and remove the db indexSuppose you have about 20 fields in the custom group and they were almost all searchable (had the searchable box checked). Over time let's say half get disabled. The indexes are still in the db, and the searchable checkbox is meaningless...Suppose you have about 20 fields in the custom group and they were almost all searchable (had the searchable box checked). Over time let's say half get disabled. The indexes are still in the db, and the searchable checkbox is meaningless because they don't appear anywhere anyway.
If the table is large, those indexes potentially cause trouble with no benefit.
If you go to re-enable, it's true it won't automatically re-check the searchable box and recreate the index, but there's no real harm, you just go back in and check the box.
An alternative to automatically doing this would be a status check: "The following fields are disabled but marked searchable. Consider making them unsearchable to improve performance on large databases."https://lab.civicrm.org/dev/core/-/issues/4915Sending an invoice per email goes to primary address, not to billing2024-02-09T23:08:39ZMariaVSending an invoice per email goes to primary address, not to billingI have found this post on StackExchange:
https://civicrm.stackexchange.com/questions/9094/sending-an-invoice-per-email-goes-to-primary-address-not-to-billing
I tested on CiviCRM 5.68.1 and it seems that CiviCRM still only sends the invo...I have found this post on StackExchange:
https://civicrm.stackexchange.com/questions/9094/sending-an-invoice-per-email-goes-to-primary-address-not-to-billing
I tested on CiviCRM 5.68.1 and it seems that CiviCRM still only sends the invoice to the primary address.
What do you think about a setting 'send invoice email to Billing if it exists, otherwise send it to Primary'?
The setting could be optional so that nothing changes for users who want to keep it as it is.
Or is there any knowing extension already that I could not find?
Thanks in advance!https://lab.civicrm.org/dev/core/-/issues/4908Integrate Angular calendar for better usability2024-01-15T11:36:56ZshaneonabikeIntegrate Angular calendar for better usabilityI don't mind the existing calendar date picker, but I was wondering if there are other solutions that might work a bit better for usability. I came across this [Angular version](https://laros.io/using-angular-material-calendar-with-date-...I don't mind the existing calendar date picker, but I was wondering if there are other solutions that might work a bit better for usability. I came across this [Angular version](https://laros.io/using-angular-material-calendar-with-date-ranges-and-range-presets) (maybe there is an alternative)
Since we are already starting to use a lot of Angular I thought it could be something to consider. There is even a date range option, which could be interesting for other areas.
You can spin a demo on this stackblitz https://stackblitz.com/edit/angular-material-calendar-with-date-ranges-and-presets?file=package.json
What I like about it:
* When choosing a different year it automatically prompts to choose the month which is fairly logical and usable
* There is the possibility to set ranges (future integration with Events?)
* There is the option to have quick options like Last 30 days, Last 12 months, etc.
![Angular Material Calendar with Date Range and Range Presets](https://laros.io/images/angular-material-calendar-date-range.png)
Anyway it was just something I wanted to raise but it's not a high priority but could be a great enhancement.https://lab.civicrm.org/dev/core/-/issues/4902Unnecessary Event Breadcrumb When Editing Event2024-02-01T10:45:52ZthemakUnnecessary Event Breadcrumb When Editing EventWhen editing an event - the breadcrumbs that display are:
CiviCRM > CiviEvent Dashboard > Manage Events > Manage Events
The first 3 make sense, but the last one actually links to the edit event page that you are editing. While I have se...When editing an event - the breadcrumbs that display are:
CiviCRM > CiviEvent Dashboard > Manage Events > Manage Events
The first 3 make sense, but the last one actually links to the edit event page that you are editing. While I have seen breadcrumbs include the current page you are on, usually they are not linked and sometimes greyed out. To stay consistent with other parts of civi, I would remove the last breadcrumb. If we decide to keep for some reason - at very least it should say Configure Event - not Manage Event.
5.69.1 - also replicated in 5.71.alpha1
![Screenshot_2024-01-10_at_12.52.30_PM](/uploads/d6048cb7a5167aab82e3dca9c2aba45d/Screenshot_2024-01-10_at_12.52.30_PM.png)https://lab.civicrm.org/dev/core/-/issues/4899Modelling many to many relationships with Entity reference, SearchKit, FormBu...2024-01-17T18:18:18ZMichael McAndrewModelling many to many relationships with Entity reference, SearchKit, FormBuilder, ECK, etc.Creating this issue as a way to keep track of different bits of functionality that can be used together to model many to many relationships in CiviCRM as when you put this all together, I think it is quite a game changer for data modelli...Creating this issue as a way to keep track of different bits of functionality that can be used together to model many to many relationships in CiviCRM as when you put this all together, I think it is quite a game changer for data modelling in CiviCRM :grinning:
Might make sense to document this at some point soon, and it would be good to collect feedback on how people are finding this functionality, ideas for improvement, etc.
Also, if you have any budget that you would like to put towards this work: to improve it or build out more features, etc. please get in contact with @colemanw or me :heart:.
* Entity Reference fields - allows you to reference other entities in custom data fields effectively creating **one to many** relationships.
* Multivalue custom data sets - [now available to all entities](https://github.com/civicrm/civicrm-core/pull/27549) allowing you to model **many to many** relationships _with additional meta data_ about the relationship
* Searchkit support for [joining via EntityRef fields in multivalue custom data](https://github.com/civicrm/civicrm-core/pull/28721) - allows you to create searches that span many to many joins
* FormBuilder support - allowing for editing of many to many relationships in entities (could probably do with some improvement)
* [ECK](https://github.com/systopia/de.systopia.eck) which allows people to make arbitrary new entities that can be joined via these relationshipshttps://lab.civicrm.org/dev/core/-/issues/4895Can't delete unused financial types2024-01-15T11:38:54ZJonGoldCan't delete unused financial typesOverview
----------------------------------------
Not a regression!
Financial types associated with quick config price sets can never be deleted.
Reproduction steps
----------------------------------------
1. Create a new financial typ...Overview
----------------------------------------
Not a regression!
Financial types associated with quick config price sets can never be deleted.
Reproduction steps
----------------------------------------
1. Create a new financial type.
1. Create a new event.
1. Select the financial type as the default for the event and save.
1. Delete the event.
1. Delete the financial type.
Current behaviour
----------------------------------------
Obtuse error.
```
The following tables have an entry for this financial type: CRM_Price_DAO_PriceSet, CRM_Price_DAO_PriceFieldValue
```
Expected behaviour
----------------------------------------
Financial type should be deletable.
When the warning `Deleting this event will also delete associated Event Registration Page and Event Fee configurations. This action cannot be undone. Do you want to continue?` appears - continuing should delete the price set if it's a quick-config. But since I hope quick config dies a painful death, let's generalize to "deleting an event
Comments
----------------------------------------
Tangentially - you can't delete a price set that has any payments associated with it. This should be doable IMO and I believe is an artifact of pre-CiviAccounts (Civi 4.3) behavior when line items didn't exist.https://lab.civicrm.org/dev/core/-/issues/4848Nuance logging on API Authorization fails2023-12-07T00:07:32ZeileenNuance logging on API Authorization failsWhen an api request fails authorization one of 2 things happens
1) too much information is logged to our logs
2) too little information is logged.
In the former case some things like SearchKit rely on authorization failing appropriatel...When an api request fails authorization one of 2 things happens
1) too much information is logged to our logs
2) too little information is logged.
In the former case some things like SearchKit rely on authorization failing appropriately and logging can cause people to spend time debugging & trying to fix issues that are normal operation - ultimately both https://github.com/civicrm/civicrm-core/pull/28259 and https://github.com/civicrm/civicrm-core/pull/28260 fall in this category & nearly wound up opening up security to fix log noise
In the latter case an api call is failing authorization but it is hard to tell where. We recently hit this where the logged output was unhelpful because the backtrace being logged only got as far as the api call - we were not getting the trace from the exception itself (and the fail was happening on something the api called, not the main api). Hence we wound up altering the code to
```
\CRM_Core_Error::backtrace('API Request Authorization failed' . $apiRequest['action'] . " " . $apiRequest['entity'], TRUE);
\CRM_Core_Error::debug_var('backtrace', $e->getTraceAsString());
```
I think that it makes sense to be able to specify at the api call level when you don't care about logging exceptions (ie searchkit) but also to get some more info when you dohttps://lab.civicrm.org/dev/core/-/issues/4842Allow bulk-enabling extensions through UI2023-12-08T13:17:56ZnoahAllow bulk-enabling extensions through UICurrent behaviour
----------------------------------------
On Administer > System Settings > Extensions, only one extension can be acted on at a time.
Proposed behaviour
----------------------------------------
It should be possible to...Current behaviour
----------------------------------------
On Administer > System Settings > Extensions, only one extension can be acted on at a time.
Proposed behaviour
----------------------------------------
It should be possible to select multiple extensions and perform the same action (Install, Disable, Uninstall) on all of them.https://lab.civicrm.org/dev/core/-/issues/4824Ship Cors with Core2023-12-06T23:25:46ZeileenShip Cors with CoreIssue for tracking this proposal https://github.com/civicrm/civicrm-core/pull/24767Issue for tracking this proposal https://github.com/civicrm/civicrm-core/pull/24767https://lab.civicrm.org/dev/core/-/issues/4823Prevent more api calls from being added to the upgrader2023-12-06T23:23:32ZeileenPrevent more api calls from being added to the upgraderTicket created for tracking this initiative https://github.com/civicrm/civicrm-core/pull/24364Ticket created for tracking this initiative https://github.com/civicrm/civicrm-core/pull/24364