Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-07-28T23:27:08Zhttps://lab.civicrm.org/dev/core/-/issues/3749Scheduled Job, Process Pledges reports an error when executed - Scheduled Job...2022-07-28T23:27:08Zjustinfreeman (Agileware)Scheduled Job, Process Pledges reports an error when executed - Scheduled Job Failure: Finished execution of Process Pledges with result: Failure, Error message: invalid criteria for INScheduled Job, Process Pledges reports an error when executed.
`Scheduled Job Failure: Finished execution of Process Pledges with result: Failure, Error message: invalid criteria for IN.`
The CiviPledge component is not installed on thi...Scheduled Job, Process Pledges reports an error when executed.
`Scheduled Job Failure: Finished execution of Process Pledges with result: Failure, Error message: invalid criteria for IN.`
The CiviPledge component is not installed on this site.
Environment: CiviCRM 5.51.1
Agileware Ref: CIVICRM-20185.53.0https://lab.civicrm.org/dev/backdrop/-/issues/10Warning: in_array() expects parameter 2 to be array, null given in civicrm_us...2023-01-05T23:39:33ZRobert J. LangWarning: in_array() expects parameter 2 to be array, null given in civicrm_user_admin_permissions_submit()Also posted in [the GitHub queue](https://github.com/civicrm/civicrm-backdrop/issues/160), where there is [a PR](https://github.com/civicrm/civicrm-backdrop/pull/161).
In the Backdrop version of CiviCRM, there is a check when the Backdr...Also posted in [the GitHub queue](https://github.com/civicrm/civicrm-backdrop/issues/160), where there is [a PR](https://github.com/civicrm/civicrm-backdrop/pull/161).
In the Backdrop version of CiviCRM, there is a check when the Backdrop permissions are edited to see if the anonymous user is getting dangerous permissions; the check is carried out by `civicrm_user_admin_permissions_submit()`.
This works fine if one is editing the entire permissions matrix, but if one edits any other single permission (e.g., at path `admin/config/people/permissions/authenticated`), then submission stuffs watchdog with many warnings like this:
`Warning: in_array() expects parameter 2 to be array, null given in civicrm_user_admin_permissions_submit() (line 1041 of /mysite/modules/contrib/civicrm/backdrop/civicrm.module).`
The problem is that the code is expecting the form to contain the anonymous permissions, but it doesn't. If the form doesn't contain anonymous permissions, then this function should simply exit.https://lab.civicrm.org/dev/core/-/issues/3748Form Builder: Exceptions don't bubble up2024-03-16T05:03:27ZJonGoldForm Builder: Exceptions don't bubble upIf you submit a form that causes the underlying CRUD API to return an error, the error isn't recorded anywhere, displayed on screen, etc. You can replicate this by creating a FB form for an individual and submitting it without entering ...If you submit a form that causes the underlying CRUD API to return an error, the error isn't recorded anywhere, displayed on screen, etc. You can replicate this by creating a FB form for an individual and submitting it without entering any values.
The relevant code comment says:
> // What to do here? Sometimes we should silently ignore errors, e.g. an optional entity
intentionally left blank. Other times it's a real error the user should know about.
But a few lines above, we say:
```
if (empty($record['fields'])) {
continue;
}
```
So I'm guessing that comment predates the `if` statement, since blank entities shouldn't get saved. So I think we should always be notifying the user.
In addition to showing a message on screen, I think errors should be saved to the AfformSubmission record, that's a killer feature that would make troubleshooting form submission errors in production much easier than Webform.https://lab.civicrm.org/dev/core/-/issues/3747Custom field values not updating with APIv4 update action on Mailing entities2022-07-26T14:07:08ZjensschuppeCustom field values not updating with APIv4 update action on Mailing entitiesOverview
----------------------------------------
When adding *Mailing* entities to the `cg_extend_objects` option group for them to be extendable with custom fields, those custom fields will not be updated with `\Civi\Api4\Mailing::upda...Overview
----------------------------------------
When adding *Mailing* entities to the `cg_extend_objects` option group for them to be extendable with custom fields, those custom fields will not be updated with `\Civi\Api4\Mailing::update()`, whereas with APIv3 this was working.
Reproduction steps
----------------------------------------
1. ```php
civicrm_api3('OptionValue', 'create', array(
'option_group_id' => 'cg_extend_objects',
'label' => 'Mailing',
'value' => 'Mailing',
'name' => 'civicrm_mailing',
'is_reserved' => 1,
));
2. Add a custom field to the *Mailing* entity (ex. `custom_group.custom_field`, `custom_789`)
3. Create a mailing (ex. ID `123`)
4. ```php
Mailing::update(FALSE)
->addWhere('id', '=', 123)
->addValue('custom_group.custom_field', 456)
->execute();
Current behaviour
----------------------------------------
The custom field is not being updated to the value `456`.
If you do the same with
```php
civicrm_api3('Mailing', 'create', array(
'id' => 123,
'custom_789' => 456,
));
```
the custom field will be updated to the value `456`.
Expected behaviour
----------------------------------------
The custom field should have been updated to the value `456`.
Environment information
----------------------------------------
A real-world scenario can be found in the [`de.systopia.mailboxmailing`](https://github.com/systopia/de.systopia.mailboxmailing) extension which uses a custom field on *Mailing* entities for tracking whether bounce notifications have been sent, see [here](https://github.com/systopia/de.systopia.mailboxmailing/blob/fc0992f18a5401eb16200ce1bbd60568e2076b12/CRM/Utils/Mailboxmailing/BouncesReportProcessor.php#L107-L117).
Comments
----------------------------------------
Of course, *Mailing* entities are not meant to be extended by custom fields in Core, but since the `update` action is using generic code, I can't see why this shouldn't work. Also, as doing the same with APIv3 works, this could be considered a regression. Also, this might apply to other entities. I suspect it's about the entity BAO not reporting custom fields attached to it and thus the API not updating them.https://lab.civicrm.org/dev/core/-/issues/3746Supervised rule works when manually run but not automarically2024-03-15T05:03:27ZcdestrieuxSupervised rule works when manually run but not automaricallyI'm running CiviCRM 5.51.0 (the problem was the same with 5.50.4) on WordPress 6.0
I defined a supervised dedupe rule using personalized fields which is properly working (i.e. finds duplicates on one of the 3 selected fieds) when manual...I'm running CiviCRM 5.51.0 (the problem was the same with 5.50.4) on WordPress 6.0
I defined a supervised dedupe rule using personalized fields which is properly working (i.e. finds duplicates on one of the 3 selected fieds) when manually run
When duplicate contacts are created or edited via the administrative CiviCRM interface, they are not detected by this supervised
Is it a known bug; I was not able to find any info on this?
I did t get any answer hEre : https://civicrm.stackexchange.com/questions/42264/supervised-dedupe-rule-finds-duplicate-when-manually-run-but-not-automatically; the problem was just confirmed
Many thanks for your helphttps://lab.civicrm.org/dev/core/-/issues/3745Search Kit Tokens only returns first value for multi-selects2022-09-21T23:27:08ZbrienneSearch Kit Tokens only returns first value for multi-selectsOverview
While using the Rewrite option for editing a display in Search Kit, I noticed a bug that the tokens only retrieve the first value for fields that have a multi-select (i.e. multiple values).
Reproduction steps
-------------------...Overview
While using the Rewrite option for editing a display in Search Kit, I noticed a bug that the tokens only retrieve the first value for fields that have a multi-select (i.e. multiple values).
Reproduction steps
----------------------------------------
1. Go to **Administer > Custom Data and Screens > Custom Fields**
1. Add a set of custom fields (that applies to contacts) that has a multi select option
1. Edit (or create) a contact so that they have multiple values in that custom field
1. Go to **Search Kit**, click **New Search**, search for Contacts, Where the custom field that you made is Not Empty, name and **Save** your search
1. Click **Add...** to add a display (I used Table)
1. In the box related to the custom field, check the **Rewite** box. The token should auto populate.
1. Click **Preview**
Current behaviour
----------------------------------------
Currently, when the above steps are preformed, only the first value for the multi-select custom field is displayed in the column
Expected behaviour
----------------------------------------
The token should return all the values relating to that field.
(Using CiviCRM 5.51.alpha1)https://lab.civicrm.org/dev/core/-/issues/3744Afform Submissions: record submitted data2023-09-13T14:40:55Zaydunsaidan.saunders@squiffle.ukAfform Submissions: record submitted dataOverview
----------------------------------------
When Afforms are submitted they can be logged resulting in an AfformSubmission entity. This records the result of the submission but not the data submitted. Often when investigating prob...Overview
----------------------------------------
When Afforms are submitted they can be logged resulting in an AfformSubmission entity. This records the result of the submission but not the data submitted. Often when investigating problems with any forms it is useful to know what data was entered.
Example use-case
----------------------------------------
1. From the Form Builder page, click 'New Submission Form'
2. Use the default 'Individual' entity - add a title, check 'Log submissions', add a 'Page' eg civicrm/test, Save
3. Go to the URL civicrm/test, enter 'Test99' for last name and first name, Submit
4. Go back to the Form Builder page, note there is 1 submission logged. Click on '1 Submission'. Note the id
5. In Api Explorer 4, use `AfformSubmission` `get` with a `where id = ` and the id from the previous line.
Current behaviour
----------------------------------------
Example result:
```
[
'id' => 11,
'contact_id' => 203,
'afform_name' => 'afformTest',
'data' => [
'Individual1' => [
[
'id' => 205,
],
],
],
'submission_date' => '2022-07-20 08:49:30',
],
```
Proposed behaviour
----------------------------------------
As above but including the entered data:
```
'submitted' => [
'Individual1' => [
[
'first_name' => 'Test99',
'middle_name' => '',
'last_name' => 'Test99',
],
],
]
```
Comments
----------------------------------------
This would also facilitate taking actions based on logged results.5.55.0https://lab.civicrm.org/dev/core/-/issues/3743Form Builder: Load contact summary blocks on Print Summary page2024-03-16T05:03:26ZJonGoldForm Builder: Load contact summary blocks on Print Summary page### Replication Steps
* Create a Search Kit search and corresponding Form Builder form.
* Check the box indicating the FB form should appear as a block on the contact summary.
* Go to a contact and select **Actions menu » Print Summary**...### Replication Steps
* Create a Search Kit search and corresponding Form Builder form.
* Check the box indicating the FB form should appear as a block on the contact summary.
* Go to a contact and select **Actions menu » Print Summary**.
### Expected Result
Print Summary includes the FB block
### Actual Result
Nope.
I have a partial fix - I can load the block, but only if someone cancels the initial `window.print()`. I'm not sure how best to tackle the issue otherwise. I don't know that there's a way to delay the print until all the blocks load - if there is, that's ideal.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3741afform: breadcrumbs present when flagged for frontend2022-08-01T23:12:05Zlcdwebafform: breadcrumbs present when flagged for frontendIf a form has been flagged for use on the frontend, breadcrumb links should not be visible, as we do with other frontend-facing forms.
Currently they are present, even for non-admin role users.If a form has been flagged for use on the frontend, breadcrumb links should not be visible, as we do with other frontend-facing forms.
Currently they are present, even for non-admin role users.5.53.0https://lab.civicrm.org/dev/core/-/issues/3739Advanced search - unable to search by payment processor2023-02-07T21:35:41ZKurund JalmiAdvanced search - unable to search by payment processorReplicated on dmaster 5.53.alpha1 and 5.49.5
Steps to replicate:
* Advanced Search
* Display results as Contributions
* Expand 'Recurring contributions' tab
* Open dropdown for Payment Processor
List shown as per below and unable to s...Replicated on dmaster 5.53.alpha1 and 5.49.5
Steps to replicate:
* Advanced Search
* Display results as Contributions
* Expand 'Recurring contributions' tab
* Open dropdown for Payment Processor
List shown as per below and unable to select any item
![search-post](/uploads/87af49bb7a42293f4b6aaab7aa5d7136/search-post.png)https://lab.civicrm.org/dev/core/-/issues/3737E_NOTICEs from CRM_Contribute_Task::permissionedTaskTitles() - undefined / nu...2024-03-17T05:03:31ZAdam WoodE_NOTICEs from CRM_Contribute_Task::permissionedTaskTitles() - undefined / null array errorsNot a major issue, but our log file is filling up with messages of the following nature:
```
[Thu Jul 14 13:28:43.516413 2022] [fcgid:warn] [pid 52056] [client 92.40.175.17:63990] mod_fcgid: stderr: PHP Notice: Undefined offset: 8 in /...Not a major issue, but our log file is filling up with messages of the following nature:
```
[Thu Jul 14 13:28:43.516413 2022] [fcgid:warn] [pid 52056] [client 92.40.175.17:63990] mod_fcgid: stderr: PHP Notice: Undefined offset: 8 in /home/cses_org_uk/public_html/administrator/components/com_civicrm/civicrm/CRM/Contribute/Task.php on line 190, referer: https://cses.org.uk/administrator/?option=com_civicrm&task=civicrm/event/search&reset=1&force=1&status=true&event=364
[Thu Jul 14 13:28:43.516486 2022] [fcgid:warn] [pid 52056] [client 92.40.175.17:63990] mod_fcgid: stderr: PHP Notice: Trying to access array offset on value of type null in /home/cses_org_uk/public_html/administrator/components/com_civicrm/civicrm/CRM/Contribute/Task.php on line 190, referer: https://cses.org.uk/administrator/?option=com_civicrm&task=civicrm/event/search&reset=1&force=1&status=true&event=364
[Thu Jul 14 13:28:43.516486 2022] [fcgid:warn] [pid 52056] [client 92.40.175.17:63990] mod_fcgid: stderr: PHP Notice: Undefined offset: 9 in /home/cses_org_uk/public_html/administrator/components/com_civicrm/civicrm/CRM/Contribute/Task.php on line 191, referer: https://cses.org.uk/administrator/?option=com_civicrm&task=civicrm/event/search&reset=1&force=1&status=true&event=364
[Thu Jul 14 13:28:43.516486 2022] [fcgid:warn] [pid 52056] [client 92.40.175.17:63990] mod_fcgid: stderr: PHP Notice: Trying to access array offset on value of type null in /home/cses_org_uk/public_html/administrator/components/com_civicrm/civicrm/CRM/Contribute/Task.php on line 191, referer: https://cses.org.uk/administrator/?option=com_civicrm&task=civicrm/event/search&reset=1&force=1&status=true&event=364
[Thu Jul 14 13:28:43.516486 2022] [fcgid:warn] [pid 52056] [client 92.40.175.17:63990] mod_fcgid: stderr: PHP Notice: Undefined offset: 402 in /home/cses_org_uk/public_html/administrator/components/com_civicrm/civicrm/CRM/Contribute/Task.php on line 190, referer: https://cses.org.uk/administrator/?option=com_civicrm&task=civicrm/event/search&reset=1&force=1&status=true&event=364
[Thu Jul 14 13:28:43.516486 2022] [fcgid:warn] [pid 52056] [client 92.40.175.17:63990] mod_fcgid: stderr: PHP Notice: Trying to access array offset on value of type null in /home/cses_org_uk/public_html/administrator/components/com_civicrm/civicrm/CRM/Contribute/Task.php on line 192, referer: https://cses.org.uk/administrator/?option=com_civicrm&task=civicrm/event/search&reset=1&force=1&status=true&event=364
```
(Running CiviCRM 5.50.4)
The issue seems to be that in `CRM_Contribute_Task::permissionedTaskTitles()`, there is a code path where the internal `$_task` array is not initialised by calling the `tasks()` method beforehand.
```php
public static function permissionedTaskTitles($permission, $params = []) {
if (!isset($params['softCreditFiltering'])) {
$params['softCreditFiltering'] = FALSE;
}
if (($permission == CRM_Core_Permission::EDIT)
|| CRM_Core_Permission::check('edit contributions')
) {
$tasks = self::taskTitles();
}
else {
/*** ISSUE IS HERE - NO PRIOR CALL TO self::tasks() OR self::taskTitles() ETC ***/
$tasks = [
self::TASK_EXPORT => self::$_tasks[self::TASK_EXPORT]['title'],
self::TASK_EMAIL => self::$_tasks[self::TASK_EMAIL]['title'],
self::PDF_RECEIPT => self::$_tasks[self::PDF_RECEIPT]['title'],
];
//CRM-4418,
if (CRM_Core_Permission::check('delete in CiviContribute')) {
$tasks[self::TASK_DELETE] = self::$_tasks[self::TASK_DELETE]['title'];
}
}
if ($params['softCreditFiltering']) {
unset($tasks[self::BATCH_UPDATE], $tasks[self::PDF_RECEIPT]);
}
$tasks = parent::corePermissionedTaskTitles($tasks, $permission, $params);
return $tasks;
}
```
Looks like a pretty easy fix (call `self::tasks()`), but I need to do some further digging to be sure of the implications and think about how we would test this. Will have to pick this up again in a couple of weeks, but raising the issue now so it's on file.
If someone else comes in with a fix in the meantime, then great :smile:https://lab.civicrm.org/dev/core/-/issues/3734Afform - Contacts are missing when editing the activity2024-03-14T05:03:19ZCésarAfform - Contacts are missing when editing the activityOverview
----------------------------------------
Hello, when editing an activity with afform, the contacts do not appear in contact ref field.
I'm not sure if this has been seen before, but it seems like undesirable behavior.
Example:...Overview
----------------------------------------
Hello, when editing an activity with afform, the contacts do not appear in contact ref field.
I'm not sure if this has been seen before, but it seems like undesirable behavior.
Example:
![activity_edit](/uploads/47ec6499b8874651673803358cd790c1/activity_edit.gif)
Reproduction steps
----------------------------------------
1. Create new activity sub form: https://dmaster.demo.civicrm.org/civicrm/admin/afform#create/form/Activity
2. Accept ID from URL in activity settings.
3. Add contact ref fields
4. Create activity and assign some contacts
5. Refresh the edit page.
Environment information
----------------------------------------
* Tested on https://dmaster.demo.civicrm.org/
* CiviCRM 5.53.alpha1https://lab.civicrm.org/dev/core/-/issues/3733Importing Data: field "source" is updated instead of filled2022-08-10T01:07:08ZfastermannSGBImporting Data: field "source" is updated instead of filledWhen importing contacts you can choose wether to skip duplicates or update them or to just fill the data that does not exist.
That works fine. If the existing contact does not have a phone number and the imported data includes one, the c...When importing contacts you can choose wether to skip duplicates or update them or to just fill the data that does not exist.
That works fine. If the existing contact does not have a phone number and the imported data includes one, the contact will be filled. If the existing contact already has a phone number, it will remain and the imported number will be ignored.
But...
... that does not work on the data field "source".
Example:
--------
The contact Max Example exists. The field "source" already has a content, i.e. "Newsletter-Subscription"
Then we import new data from another campaign. Max Example is also in this list, with his postal adress, a phone number and a new source "Orders May 2022".
Import-Options for duplicate contacts is set to "Fill".
Duplicate will be recognized correctly, postal adresse and phone number will be added - but the source will be updated to "Orders May 22". So the information where the first data was generated ("Newsletter-Subscription") will be lost.
Question:
---------
Is it a bug or a feature? And if it's a feature, is there a workaround to not lose the existing data?
Best regards
Thomas5.53.0https://lab.civicrm.org/dev/core/-/issues/3732Show billing address on Edit contribution screen as well2022-09-26T16:47:07ZyashodhaShow billing address on Edit contribution screen as wellWe currently show billing address on _View Contribution_ screen.
I propose to show billing address on _Edit Contribution_ screen as well for consistency.We currently show billing address on _View Contribution_ screen.
I propose to show billing address on _Edit Contribution_ screen as well for consistency.5.55.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3731Edit-in-place not working for custom field on search-display2022-07-16T07:07:07ZeileenEdit-in-place not working for custom field on search-displayI wanted to blog about [cool stuff people might not realise they can do](https://docs.google.com/document/d/1v0DNthPE-F_ACJ_fy82W7VZQ_p_QKsSLFEetHc2Oa8A/edit) with search kit et al - but found that edit in place for custom fields didn't ...I wanted to blog about [cool stuff people might not realise they can do](https://docs.google.com/document/d/1v0DNthPE-F_ACJ_fy82W7VZQ_p_QKsSLFEetHc2Oa8A/edit) with search kit et al - but found that edit in place for custom fields didn't work.
I created this extension https://github.com/eileenmcnaughton/custom_custom - to create the relevant config - you wind up with a search display of custom fields where one of the field is a custom field that extends the entity 'Custom Field'
![image](/uploads/cefafd92941fc01b5cbe5a17524a2c11/image.png)
The update ajax call does NOT appear to be passing out the custom field value to be updated
![image](/uploads/bb8c72d94157b27e4a1a5263e6d6f2c4/image.png)https://lab.civicrm.org/dev/wordpress/-/issues/127Using afform components via WordPress shortcodes on non-Pages/Posts2023-03-01T11:53:24ZflantascienceUsing afform components via WordPress shortcodes on non-Pages/PostsI'm trying to use a shortcode to display a Search Kit Form on the Thank You page for a Petition that contains the Date, First Name, and Comment of all the petition signers.
When I input the shortcode, I get an error message: "This Short...I'm trying to use a shortcode to display a Search Kit Form on the Thank You page for a Petition that contains the Date, First Name, and Comment of all the petition signers.
When I input the shortcode, I get an error message: "This Shortcode could not be handled. It could be malformed or used incorrectly."
It works fine on pages/posts, but not on the Petition Thank You Page.
(this is a bit of a follow up to [#82](https://lab.civicrm.org/dev/report/-/issues/82).)https://lab.civicrm.org/dev/core/-/issues/3729Form Builder doesn't use dedupe2023-02-16T22:18:18ZJonGoldForm Builder doesn't use dedupeIdeally Form Builder would allow you to select a dedupe rule on a per-contact basis, but on a basic level contacts should get deduped.Ideally Form Builder would allow you to select a dedupe rule on a per-contact basis, but on a basic level contacts should get deduped.https://lab.civicrm.org/dev/core/-/issues/3724hook_managed(...CaseType,APIv4...): Exhausts memory (>256m)2022-07-07T21:12:23Ztottenhook_managed(...CaseType,APIv4...): Exhausts memory (>256m)Overview
----------------------------------------
If you export a `CaseType` with a real `definition` and then try to import it by way of `hook_managed(...CaseType,APIv4...)`, then it crashes due to memory exhaustion.
Reproduction step...Overview
----------------------------------------
If you export a `CaseType` with a real `definition` and then try to import it by way of `hook_managed(...CaseType,APIv4...)`, then it crashes due to memory exhaustion.
Reproduction steps
----------------------------------------
Install https://gist.github.com/totten/3ec8164c3f8ca9d3c51e768feab946da
(*Note: https://github.com/civicrm/civicrm-core/pull/23961 also includes a way to reproduce the problem within a test; but some of the key bits are commented-out, and it requires a `mixer` test harness. The gist may be easier for most folks to play with.*)
Current behaviour
----------------------------------------
```
$ cv en shimmy
Enabling extension "shimmy"
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 69632 bytes) in /Users/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Error.php on line 818
```
Note: 256m is plenty generous for the task.
Expected behaviour
----------------------------------------
The extension should be enabled -- and the full/valid `CaseType` should be setup.
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. -->
* __Browser:__ Firefox
* __CiviCRM:__ Master
* __PHP:__ 7.4
* __CMS:__ D7
* __Database:__ MySQL 5.7
* __Web Server:__ Apache 2.4
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/3723SearchKit: HTML fields display2022-08-18T16:28:35ZfrancescbassasSearchKit: HTML fields displayFields containing HTML code are displaying as plain text in the SearchKit results. For example, activity details
![htmlfields-as-plain-text](/uploads/61d34edd4d6a761ed5dad7c79866042d/htmlfields-as-plain-text.png)Fields containing HTML code are displaying as plain text in the SearchKit results. For example, activity details
![htmlfields-as-plain-text](/uploads/61d34edd4d6a761ed5dad7c79866042d/htmlfields-as-plain-text.png)colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3722CaseType managed entity in mgd.php file gets caught in an infinite loop2023-09-16T13:59:04ZherbdoolCaseType managed entity in mgd.php file gets caught in an infinite loopOverview
----------------------------------------
When using mgd.php file for a CaseType managed entity it creates an infinite loop when flushing the cache (which is when managed entities get checked). In `CRM_Case_BAO_CaseType::add()` ...Overview
----------------------------------------
When using mgd.php file for a CaseType managed entity it creates an infinite loop when flushing the cache (which is when managed entities get checked). In `CRM_Case_BAO_CaseType::add()` it calls `CRM_Core_ManagedEntities::scheduleReconciliation()` which seems to create the loop.
Some chat here https://chat.civicrm.org/civicrm/pl/pmcn6sa9zpboigkh7f4ukxt8yr
Reproduction steps
----------------------------------------
1. Create a new Case Type in the UI.
1. Go to API4 and export the Case Type to PHP definition.
1. Save to mgd.php file in an extension.
2. Delete the custom case type.
3. Enable the extension and flush cache (`cv flush`).
Current behaviour
----------------------------------------
Gets caught in an infinite loop, where it keeps trying to create the same case type (as I've noticed when going over it in XDebug).
Expected behaviour
----------------------------------------
Just create it once and stop.
Environment information
----------------------------------------
* __CiviCRM: 5.50.0 and up