CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-07-01T05:03:24Zhttps://lab.civicrm.org/dev/core/-/issues/2386Support chain-select elements in .setting.php files2023-07-01T05:03:24ZJonGoldSupport chain-select elements in .setting.php filesOverview
----------------------------------------
As we move to metadata-based settings, we need to support existing use cases such as chain-select.
Example use-case
----------------------------------------
1. Go to **Administer » Local...Overview
----------------------------------------
As we move to metadata-based settings, we need to support existing use cases such as chain-select.
Example use-case
----------------------------------------
1. Go to **Administer » Localization » Languages, Currencies, Locations**.
1. The `defaultContactStateProvince` setting can't be represented accurately via metadata.
Current behaviour
----------------------------------------
No way to define either an `onclick` value or a chain-select.
Proposed behaviour
----------------------------------------
A new property `chain_select_settings` contains properties that are passed to the `addChainSelect` method.
Comments
----------------------------------------
There's partial support, and I suspect work on this stopped because `addChainSelect` has a syntax that's tangled up in Smarty. I'll submit a PR to be a conversation piece.
This will also need documentation.JonGoldJonGoldhttps://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/2201PHP 8.0 Compatibility2021-12-09T16:32:47ZJoeMurrayPHP 8.0 CompatibilityPHP 8.0.0 is scheduled for release Nov 26, 2020.
Backward incompatible changes are listed at https://github.com/php/php-src/blob/php-8.0.0RC5/UPGRADING#L20 for 8.0.0RC5. As one would expect for a major version, it is a long list.
1. [...PHP 8.0.0 is scheduled for release Nov 26, 2020.
Backward incompatible changes are listed at https://github.com/php/php-src/blob/php-8.0.0RC5/UPGRADING#L20 for 8.0.0RC5. As one would expect for a major version, it is a long list.
1. [Create edge CI for PHP8](https://lab.civicrm.org/dev/core/-/issues/2200)https://lab.civicrm.org/dev/core/-/issues/2197afform_html - Include Monaco dependencies2020-11-19T04:54:20Ztottenafform_html - Include Monaco dependenciesOverview
----------------------------------------
The extension `afform_html` has a dependency on Monaco, but it's not included by default with either (a) tarballs or (b) civibuild sites.
Reproduction steps
----------------------------...Overview
----------------------------------------
The extension `afform_html` has a dependency on Monaco, but it's not included by default with either (a) tarballs or (b) civibuild sites.
Reproduction steps
----------------------------------------
1. Enable core extension `afform_html`
2. View system status
Current behaviour
----------------------------------------
See a warning that the `node_modules` are missing.
Expected behaviour
----------------------------------------
Don't show a warning. Instead, the Monaco JS should be available by default.5.33.0https://lab.civicrm.org/dev/core/-/issues/2189Activity Type cleanup2023-06-15T05:03:16ZJonGoldActivity Type cleanupCurrently, activity types can have a `component_id`, so they're not displayed unless that component is enabled. However, 4 activities definitively tied to components ("Bulk Email", "Mass SMS" for CiviMail; "Downloaded Invoice", "Emailed...Currently, activity types can have a `component_id`, so they're not displayed unless that component is enabled. However, 4 activities definitively tied to components ("Bulk Email", "Mass SMS" for CiviMail; "Downloaded Invoice", "Emailed Invoice" for CiviContribute) don't have a `component_id` assigned.
It also seems that "Meeting" and "Phone Call" are set as `is_reserved`, but there aren't any references to those in the codebase such that disabling or deleting them should affect a Civi install.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2178Cannot manually add contacts immediately after group creation2020-11-20T00:02:45ZandrewcormickdockeryCannot manually add contacts immediately after group creationOverview
----------------------------------------
In Civi 5.31.0, there is difficulty in assigning contacts immediately after a static group creation. This is a regression compared to Civi 5.28.3 (I haven't tested later versions of Civi...Overview
----------------------------------------
In Civi 5.31.0, there is difficulty in assigning contacts immediately after a static group creation. This is a regression compared to Civi 5.28.3 (I haven't tested later versions of Civi than this).
Reproduction steps
----------------------------------------
1. Contacts/New Group, add name, set group type as mailing list, save.
2. Add contacts to group, choose name to find, ensure results have about 10 entries or so.
3. Select all contacts, add. No contacts added. Strange formatting on messages.
Current behaviour
----------------------------------------
Contacts not added to group. Strange formatting in messages, see images.
![image](/uploads/42a94da16ced4f9b6397133cd4b3a4b7/image.png)
![image](/uploads/90ac3eff22ecc5fff1ba4daa3133a99c/image.png)
Note that contacts can still be added to static groups in other ways, I have noticed this problem specifically with the "add contact" screen shown immediately after creating the static group.
Expected behaviour
----------------------------------------
Contacts should be added to the group as indicated by the user.
Environment information
----------------------------------------
* __CiviCRM:__ _5.31.0_
* __PHP:__ _7.3_
* __CMS:__ _Drupal 7.73_
* __Database:__ _MariaDB 10.3.20_
* __Web Server:__ _Nginx 1.10.3_5.31.1https://lab.civicrm.org/dev/core/-/issues/2177Recent drush requires updated symfony/finder2023-08-19T00:28:39ZfkohrtRecent drush requires updated symfony/finderWhile [installing](https://docs.civicrm.org/installation/en/latest/drupal8/#download) CiviCRM 5.31 on Drupal 8, composer had a problem during `composer require civicrm/civicrm-{core,packages,drupal-8}:'~5.31'`.
<details>
<summary>Consol...While [installing](https://docs.civicrm.org/installation/en/latest/drupal8/#download) CiviCRM 5.31 on Drupal 8, composer had a problem during `composer require civicrm/civicrm-{core,packages,drupal-8}:'~5.31'`.
<details>
<summary>Console output</summary>
```
./composer.json has been updated
Running composer update civicrm/civicrm-core civicrm/civicrm-packages civicrm/civicrm-drupal-8
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.
Problem 1
- civicrm/civicrm-core[5.31.0, ..., 5.32.x-dev] require symfony/finder ~3.0 || ~4.4 -> found symfony/finder[v3.0.0-BETA1, ..., 3.4.x-dev, v4.4.0-BETA1, ..., 4.4.x-dev] but the package is fixed to v5.1.8 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- Root composer.json requires civicrm/civicrm-core ~5.31 -> satisfiable by civicrm/civicrm-core[5.31.0, 5.31.x-dev, 5.32.x-dev].
Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
```
</details>
I had previously installed `drush/drush:10.3.6` which requires `symfony/finder:5.1.8`. However, `civicrm/civicrm-core:~5.31` requires `symfony/finder ~3.0 || ~4.4`. This leads to the problem above. I had to use `composer require drush/drush:10.3.5` to proceed with the installation.
Maybe `civicrm-core` should be updated to require `symfony/finder:~5.1` as well?https://lab.civicrm.org/dev/core/-/issues/2140Do not manually construct the site path during Drupal8+ setup2020-10-22T23:27:02ZmglamanDo not manually construct the site path during Drupal8+ setupOverview
----------------------------------------
I am working on writing tests that allow testing the Drupal CiviCRM integration. However, the installation is broken due to an assumption of the site directory path.
```
// Compute s...Overview
----------------------------------------
I am working on writing tests that allow testing the Drupal CiviCRM integration. However, the installation is broken due to an assumption of the site directory path.
```
// Compute settingsPath.
$siteDir = \Civi\Setup\DrupalUtil::getDrupalSiteDir($cmsPath);
$model->settingsPath = implode(DIRECTORY_SEPARATOR, [$cmsPath, 'sites', $siteDir, 'civicrm.settings.php']);
```
In a PHPUnit test the path is actually `sites/simpletest/$siteDir/`. This is causing CiviCRM to write files to `sites/$siteDir` and prevent a test run.
In the `\Civi\Setup\DrupalUtil::getDrupalSiteDir` the basename is fetched, when really the entire path should be returned and trusted:
```
elseif (class_exists('Drupal')) {
- return basename(\Drupal::service('site.path'));
+ return \Drupal::service('site.path');
}
```
Then the computed path is just
```
// Compute settingsPath.
$siteDir = \Civi\Setup\DrupalUtil::getDrupalSiteDir($cmsPath);
$model->settingsPath = implode(DIRECTORY_SEPARATOR, [$cmsPath, $siteDir, 'civicrm.settings.php']);
```
Reproduction steps
----------------------------------------
1. Attempt to write a Functional test
Current behaviour
----------------------------------------
```
1) Drupal\Tests\drupal_civicrm\Functional\InstallTest::testInstall
include_once(sites/simpletest/34927510/civicrm.settings.php): failed to open stream: No such file or directory
```
Expected behaviour
----------------------------------------
No error, beyond any other testing errors.5.32.0https://lab.civicrm.org/dev/core/-/issues/2121Option to rename the file before downloading2022-02-13T20:28:19Zshahrukh_compucorpOption to rename the file before downloadingOverview
----------------------------------------
CiviCRM has functionality to allow you to generate PDF letters.
The files that are being created throughout the system has a specific name depending on the nature of the file and does n...Overview
----------------------------------------
CiviCRM has functionality to allow you to generate PDF letters.
The files that are being created throughout the system has a specific name depending on the nature of the file and does not provide any option to rename the file.
As such the file downloaded and the file recorded on an activity record against a contact record is always called "CiviLetter.pdf".
This makes it difficult for users to know what the letter was for.
Problem statement
----------------------------------------
The key point is **not** the name of the file that is downloaded to your Computer, a user can obviously always change this after it is downloaded. The problem is that CiviCRM creates an activity with the file in the activity listing and the filename of the file that is created automatically by CiviCRM is also named "CiviLetter.pdf". This makes it impossible for a user to know what the file was once it was created. There is no way for the user to change this.
Example use-case
----------------------------------------
1. Go to activities tab in contact detail page.
2. Choose Print/Merge Document from New Activity menu.
3. Fill the form and Proceed to download or preview the document.
4. The name of the file will be CiviLetter.pdf
5. CiviCRM will create an activity with the new CiviLetter.pdf attached
6. Users will not know what the CiviLetter.pdf was about after it was created and there is no way to change the name of that file as a user.
Current behaviour
----------------------------------------
The downloaded file has always the same specific name and the PDF attached to the activity always has that name.
Proposed behaviour
----------------------------------------
The `postProcess` method in class `CRM/Contact/Form/Task/PDFLetterCommon.php` can be changed such that it looks for the filename field being posted and if it does find that field then it uses the field value for naming the downloading file otherwise it uses the activity subject and even that is empty then it falls back to default 'CiviLetter'. This way the processing for the filename will be added as a work in progress and the ui for it can be added later.5.42.0https://lab.civicrm.org/dev/core/-/issues/2064Address inconsistencies on "Cleanup Caches and Reset Paths" page in UI2023-05-07T05:03:25ZJonGoldAddress inconsistencies on "Cleanup Caches and Reset Paths" page in UIThere's a few issues here that are tangentially related:
* "Cleanup Caches" and "Reset Paths" have identical UX - the buttons look the same, there's no additional "are you sure" dialogs on either. However, one is always a harmless opera...There's a few issues here that are tangentially related:
* "Cleanup Caches" and "Reset Paths" have identical UX - the buttons look the same, there's no additional "are you sure" dialogs on either. However, one is always a harmless operation, the other can break your instance. They should NOT have an identical UX. In fact, I think there's an argument that "Reset Paths" shouldn't exist anymore. Folks on Stack Exchange looking to fix their site will clear their cache based on some online advice, then click "Reset Paths" to see if it will help, and now they have two problems.
* "Cleanup Caches" should either a) function identically to `cv flush`, or b) additional operations should be added to this page so that all the actions of `cv flush` are available. I'm particularly thinking of reconciling managed entities.
* I don't think "Rebuild Menus" is part of `cv flush`, but that should also be an option on this page. The current approach for doing so is unfriendly.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2063Eliminate "No extensions available for this version of CiviCRM"2020-09-29T20:07:08ZJonGoldEliminate "No extensions available for this version of CiviCRM"This error is a possible outcome of the "checkExtensions" system check. I propose we eliminate it:
* There's never going to be another version of CiviCRM that has no extensions available, so the message is wrong.
* The error pretty much...This error is a possible outcome of the "checkExtensions" system check. I propose we eliminate it:
* There's never going to be another version of CiviCRM that has no extensions available, so the message is wrong.
* The error pretty much exclusively happens when there's an error on the c.o side, like an outage.
* There are no actionable steps for someone receiving this message.
* My personal gripe: When c.o goes down, I get this message from a gazillion sites at once.
While I'm aware it's theoretically possible that someone could define an alternate extension directory source from c.o, to my knowledge that a) has never been done, b) if you do that, you shouldn't need a warning in the UI to tell you no extensions are available.
Happy to take this on if folks approve.5.31.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2062activity_contact.record_type_id should be required in the database?2023-05-08T05:03:25ZDaveDactivity_contact.record_type_id should be required in the database?Is there a use case where null in this field makes sense?
https://github.com/civicrm/civicrm-core/blob/6777cd9378333d3c4e38e7ce5ae7a396f6fb0a6e/xml/schema/Activity/ActivityContact.xml#L54Is there a use case where null in this field makes sense?
https://github.com/civicrm/civicrm-core/blob/6777cd9378333d3c4e38e7ce5ae7a396f6fb0a6e/xml/schema/Activity/ActivityContact.xml#L54https://lab.civicrm.org/dev/core/-/issues/2049use default membership status rule rather than hard-coded "New"2023-05-10T05:03:26Zlcdwebuse default membership status rule rather than hard-coded "New"In CRM_Contribute_BAO_Contribution::updateMembershipBasedOnCompletionOfContribution() we update the membership status when a linked contribution is completed (the method name says it all...). The code that determines the calculated statu...In CRM_Contribute_BAO_Contribution::updateMembershipBasedOnCompletionOfContribution() we update the membership status when a linked contribution is completed (the method name says it all...). The code that determines the calculated status defaults to a hard coded value of "New". I believe it should instead default to whatever status rule has been flagged as default... since that's kind of the point of having a default flag.
https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/BAO/Contribution.php#L5190
I'd like to add a method "getDefaultStatus()" to CRM_Member_BAO_MembershipStatus to retrieve whichever status rule has been flagged as default. Interestingly, there's a class static "$_defaultMembershipStatus" that as far as I can see is never used. I'll populate that and return the value for some caching love.
Looking for concept approval.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/2028Obsolete wkhtmltopdfPath causes hard fail in event registration due to intern...2023-07-14T05:03:22ZMonish DebObsolete wkhtmltopdfPath causes hard fail in event registration due to internal fatal error for the missing packageThis occurred to us after migration, as on new server the wkhtmltopdfPath is not installed/or it might be changed and as result of which alternate executable path of wkhtmltopdfPath becomes obsolete. This causes hard fail on any of the f...This occurred to us after migration, as on new server the wkhtmltopdfPath is not installed/or it might be changed and as result of which alternate executable path of wkhtmltopdfPath becomes obsolete. This causes hard fail on any of the following operations which involves PDF generation from html content:
1. attaching confirmation mail to participant and attaching PDF of the content on it.
2. same with #1 but in case of online donation.
3. Manual print document for contacts
ETC.
In our case its #1 which prevents the event registration process with an internal error
```
Sep 02 14:03:16 [error]
$Fatal Error Details = array(3) {
["message"]=>
string(424) "The exit status code '127' says something went wrong:
stderr: "sh: /old/path/wkhtmltox/bin/wkhtmltopdf: not found
"
stdout: ""
command: /old/path/wkhtmltox/bin/wkhtmltopdf --lowquality --margin-bottom '0.75in' --margin-left '0.75in' --margin-right '0.75in' --margin-top '0.75in' --orientation 'portrait' --page-height '792pt' --p
age-width '612pt' '/tmp//knp_snappy5f4fec74637de.html' '/tmp//knp_snappy5f4fec74638cf.pdf’.
“
```
To resolve this I would propose the following approach:
1. In case, if the wkhtmltopdf executable path is not working for various reason, throw an error message on civicrm status page.
2. Prevent the code to use the wkhtmltopdf executable path and fallback to use the default pdf package tcpdf which is bundled with CiviCRM
ping @eileen @JoeMurray @seamuslee5.34.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/2020Revert 20202022-10-11T14:54:01ZeileenRevert 2020Entirely. PleaseEntirely. Please2020-01-01https://lab.civicrm.org/dev/core/-/issues/1975Add pre/post hook for FinancialTrxn2023-04-20T05:03:26ZyashodhaAdd pre/post hook for FinancialTrxnAdd pre/post hook for FinancialTrxn entity.Add pre/post hook for FinancialTrxn entity.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3550Email to activity processing: New feature to make the creation of new contact...2022-06-11T14:50:44ZJamie Novick - CompucoEmail to activity processing: New feature to make the creation of new contacts "optional"**User story:**
- As an administrator
- When filing inbound emails
- I would like to configure whether CiviCRM will create a new contact where a contact does not already exist within the system
- So that I can ensure that new contacts a...**User story:**
- As an administrator
- When filing inbound emails
- I would like to configure whether CiviCRM will create a new contact where a contact does not already exist within the system
- So that I can ensure that new contacts are not created in the system when filing an email.
- In the situation of a case email where the email has a valid Case ID or Case token in the subject line the email should still be filed to a case, even if no contacts are matched.
**How it works currently:**
Currently, when CiviCRM performs email to activity processing, Civi will search CiviCRM for a contact with the relevant email address in the From / To / CC fields and then assign the created activity accordingly.
When CiviCRM cannot find a contact with a relevant email address, it simply creates a new "stub" contact with the email address.
**The problem**
For multiple reasons this is might not be desirable behaviour:
This is a security risk, as in most cases CiviCRM email-activity processing works off a mailbox, that might need to be public. As such it is possible that an unscrupulous third party may chose to spam your mailbox and thus spam your CRM with unwanted emails and content. Whilst this can be mitigated by having your automated filing on a separate mailbox, it might be preferable to simply only file the emails for contacts who already exist in your system, and to selectively add the rest.
Also, from a GDPR perspective it may not be desirable to hold the details of the persons who sent an email, whilst the contents of the email might be important (i.e. the attachments) especially in a casework context.
**Proposed solution:**
Add an additional option to the email to activity processing configurations (civicrm/admin/mailSettings?action=add&reset=1)
- When "Used For?" = Email to activity processing
- Show an additional option:
- "Do not create new contacts when filing emails"
- Checkbox
- Default null
- Help:
- If this option is enabled, CiviCRM will not create new contacts when filing emails.
- The email should also always be filed as an activity.
If checked:
- When CiviCRM checks for a matching contact, if no matching contact is found it will not create one and the email is skipped
- unless the email has a valid Case ID or Case token in the subject line, in which it will still be filed against the case, but no contacts will be linked to the email.5.31.0https://lab.civicrm.org/dev/core/-/issues/3581Email to activity processing: New feature to skip emails which do not have a ...2022-06-11T14:54:48ZJamie Novick - CompucoEmail to activity processing: New feature to skip emails which do not have a Case ID or Case token- As a CiviCRM administrator
- I would like to configure whether CiviCRM will process emails without a case ID (or case “token”) in the subject line
- so that I can ensure that emails which do not have a case ID are not filed on the con...- As a CiviCRM administrator
- I would like to configure whether CiviCRM will process emails without a case ID (or case “token”) in the subject line
- so that I can ensure that emails which do not have a case ID are not filed on the contact record outside the case by accident.
**How it works currently**
For those a little less familiar with email to activity processing:
CiviCRM will connect to a users MS exchange mailbox and create the following folder structure:
- Inbox
- /CiviCRM
- //CiviMail
- ///ignored
- ///processed
Notes:
- Users simply copy or move emails into the /civicrm folder in their inbox. CiviCRM has a scheduled job that can be configured to run periodically (say every hour) and poll the mailbox folder (Civimail) by IMAP in order to read and process the emails.
- By default CiviCRM will match any email from, to, cc fields to contacts in the CRM and file the email as an activity against those contacts (including recording any attachments as files).
- If however there is a case ID in the subject line (or a case ID "token"*) then CiviCRM will instead file the email straight onto the case itself. The format is: [case #1234] (see: https://issues.civicrm.org/jira/browse/CRM-21446)
- If the email is processed successfully it will be moved to the processed folder.
- If for any reason CiviCRM cannot file the email it will be moved to the ignored folder. This normally happens if the email address is invalid for some reason (please note: emails that are sent internally between staff on exchange server can sometimes have this problem as exchange doesn't always use the external email address but instead uses some local username/domain combination - this maybe something to test and see if it maybe a problem for NEU).
- Note: *When sending out emails from CiviCRM from CiviCase it appends a case ID token - which is a string of characters and not the exact Case ID. This is done to obscure the case ID number in the email. In effect you can have either this token or the case id in the subject line and CiviCRM will file the email correctly.
- More background: https://docs.civicrm.org/sysadmin/en/latest/setup/civimail/inbound/#autofiling-email-activities-via-emailprocessor
**Problem**
For multiple clients they want to use email to activity processing for their casework teams. However sometimes they forget to add the case ID to the subject line of the email and the system incorrectly files the email outside the case - which is a "security" risk as the emails can be sensitive.
As such they would like to be able to specify that the emails being filed from the casework team inbox will only be filed if there is a valid Case ID in the subject line and are skipped if not, and hence there is no risk of the email being filed outside of the case.
**Proposed improvement**
Approach:
When "Used For?" = Email to activity processing
Show an additional option:
- Skip emails which do not have a Case ID or Case token:
- Checkbox
- Help text:
- CiviCRM has functionality to file emails which contain the Case ID or Case Hash in the subject line in the format [case #1234] against a case record.
- Where the Case ID or Case Hash is not included CiviCRM will file the email against the contact record, by matching the email addresses on the email with any email addresses of Contact records in CiviCRM.
- Enabling this option will have CiviCRM skip any emails that do not have the Case ID or Case Hash so that the system will only process emails that can be placed on case records.
- Any emails that are not processed will be moved the ignored folder.
- Default null
- If checked:
- Emails which do not have a valid case ID or case token should be moved into the “ignored” folder. (See folders above) after processing and no Activity should be created.
Would be great to know if we can get the magical "concept approved" flag.
We need to work on this quite urgently so if there are no great concerns that would be much appreciated...5.31.0https://lab.civicrm.org/dev/core/-/issues/1921Remove unneccessary isoToDate function2023-03-20T01:39:56ZeileenRemove unneccessary isoToDate function**[CQ] Let's celebrate the recent 6 year anniversary of making isoToData unnecessary by getting it out of the code**
Prior to July 2014 the following would fail
```
$contribution->fetch();
$contribution->save();
```
because the fetch ...**[CQ] Let's celebrate the recent 6 year anniversary of making isoToData unnecessary by getting it out of the code**
Prior to July 2014 the following would fail
```
$contribution->fetch();
$contribution->save();
```
because the fetch format for dates was invalid for save.
However, that all changed once this was merged https://github.com/civicrm/civicrm-packages/commit/283da6111677fc2b0176902b4c9a5cbcf668a258
Except for the bits that provide handling for it still litter our codehttps://lab.civicrm.org/dev/core/-/issues/1912Weird "null" in mailing recipient group list2023-06-23T03:51:55ZDaveDWeird "null" in mailing recipient group list![null](/uploads/0c8e6691c31580ceb2cc621df015fe93/null.png)
Can reproduce on dmaster.demo. I don't see it in 5.22 but do see it in 5.24 and up. Don't have a 5.23 handy.
1. Create at least 2 groups with the mailing list checkbox checked...![null](/uploads/0c8e6691c31580ceb2cc621df015fe93/null.png)
Can reproduce on dmaster.demo. I don't see it in 5.22 but do see it in 5.24 and up. Don't have a 5.23 handy.
1. Create at least 2 groups with the mailing list checkbox checked.
1. Go to New Mailing.
1. Pick one group.
1. Open the group dropdown again and scroll down.
1. It even lets you select it.
In drupal watchdog there is this:
`Location: http://example.com/civicrm/ajax/rest?entity=Mailing&action=getlist&json=%7B%22input%22%3A%22%22%2C%22page_num%22%3A1%2C%22params%22%3A%7B%22is_hidden%22%3A0%2C%22is_active%22%3A1%2C%22options%22%3A%7B%22sort%22%3A%22is_archived+asc%2C+scheduled_date+desc%22%7D%7D%2C%22api.MailingRecipients.getcount%22%3A%7B%7D%7D`
`Notice: Undefined index: name in _civicrm_api3_generic_getlist_output() (line 191 of .../api/v3/Generic/Getlist.php).`
This might be violating a higher mathematical law here too - it's not possible to exclude the null set, since the null set is a subset of every set. (Source: Math)5.64.0