CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-08-04T21:07:47Zhttps://lab.civicrm.org/dev/core/-/issues/3774Can't submit backend credit card contribution unless you have at least one pa...2022-08-04T21:07:47ZJonGoldCan't submit backend credit card contribution unless you have at least one payment processor that supports a future start dateIf you don't have a payment processor that supports a future start date, you can't submit a credit card contribution.
### Steps to replicate
* On a buildkit site, add a PayPal Pro payment processor. The creds don't have to be valid.
* S...If you don't have a payment processor that supports a future start date, you can't submit a credit card contribution.
### Steps to replicate
* On a buildkit site, add a PayPal Pro payment processor. The creds don't have to be valid.
* Submit a backend credit card contribution with PayPal Pro. Should go through (or tell you invalid credentials).
* Delete the default processor of type "Dummy Payment Processor".
* Submit another backend credit card contribution with PayPal Pro.
### Expected Result
Absence of a dummy test processor shouldn't affect the ability to submit a credit card processor.
### Actual result
```
Please correct the following errors in the form fields below:
Date Received is a required field.
```
### Why
In `CRM_Contribution_Form_AbstractEditPayment::assignProcessors()` is this line:
```
$this->assign('processorSupportsFutureStartDate', CRM_Financial_BAO_PaymentProcessor::hasPaymentProcessorSupporting(['FutureRecurStartDate']));
```
This will return `TRUE` if *any* payment processor supports a future start date. Which in turn causes the `receive_date` to appear on `templates/CRM/Contribute/Form/Contribution.tpl`.
Without the `receive_date` on the form, even hidden, you can't submit the form.
The workaround is to create a dummy processor on your site. I have to run, but tomorrow I'll try to put together a PR that fixes this at the template level.
Is this a regression? I mean, technically yes, but it's two years old. And tricky to catch because the test suite creates the dummy processor in `setUp()`. To catch this we might have to move that out of `setUp()` and into its own helper function.5.52.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3644Delivery summary doesn't show2022-06-11T14:58:02ZLoganBearDelivery summary doesn't showUpdated to CiviCRM 5.19 - ran one of our biweekly mailings last night and I wanted to check the open count. But Civi says that the mailing isn't completed,![Screen_Shot_2019-11-08_at_10.23.56_AM](/uploads/9723b265e4f977ffebce0033575d5291...Updated to CiviCRM 5.19 - ran one of our biweekly mailings last night and I wanted to check the open count. But Civi says that the mailing isn't completed,![Screen_Shot_2019-11-08_at_10.23.56_AM](/uploads/9723b265e4f977ffebce0033575d5291/Screen_Shot_2019-11-08_at_10.23.56_AM.png)
but the summary shows it's completed.![Screen_Shot_2019-11-08_at_10.23.41_AM](/uploads/24352601bef0fce245cc4198826cb937/Screen_Shot_2019-11-08_at_10.23.41_AM.png)5.19.1https://lab.civicrm.org/dev/core/-/issues/3599Test mailings create new contacts even when "Add Contacts" permission is not ...2022-06-11T14:55:17ZJonGoldTest mailings create new contacts even when "Add Contacts" permission is not present.### Overview
When sending a test mail, CiviCRM will check if the email matches an existing contact in the database. If it does, it uses that contact ID; if not, it creates a contact. However, it creates a contact without regard for wh...### Overview
When sending a test mail, CiviCRM will check if the email matches an existing contact in the database. If it does, it uses that contact ID; if not, it creates a contact. However, it creates a contact without regard for whether a user has permission to add contacts.
### Steps to replicate
* Create a user that does not have the "Add Contacts" permission.
* With that user, create a new mailing (traditional or Mosaico, doesn't matter).
* Send a test ("draft") mail to an email address that doesn't exist in the database.
### Expected behavior
No new contact is created.
### Actual behavior
A new contact is created.5.29.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3589Report on scheduled mailing fails with Notice: Undefined property: CRM_Mailin...2022-06-11T14:55:03ZspalmstromReport on scheduled mailing fails with Notice: Undefined property: CRM_Mailing_BAO_Mailing::$mailing_job_start_date in <joomla_root>/administrator/components/com_civicrm/civicrm/CRM/Mailing/BAO/Mailing.php on line 2031This occurs in Joomla after upgrading to CiviCRM 5.19.0. Line 175 in /administrator/components/com_civicrm/civicrm/CRM/Mailing/DAO/MailingJob.php should read:
'start_date' => [
not
'mailing_job_start_date' => [This occurs in Joomla after upgrading to CiviCRM 5.19.0. Line 175 in /administrator/components/com_civicrm/civicrm/CRM/Mailing/DAO/MailingJob.php should read:
'start_date' => [
not
'mailing_job_start_date' => [5.19.1https://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/3579Add pause/resume functionality to civicrm bulk mailing.2022-06-11T14:54:43ZjitendraAdd pause/resume functionality to civicrm bulk mailing.Scenario
Site admin is sending out a big blast but want to send out a press release without waiting for first job to end.Scenario
Site admin is sending out a big blast but want to send out a press release without waiting for first job to end.5.4.0https://lab.civicrm.org/dev/core/-/issues/3566Public View link does not show from Scheduled and Sent screen2022-06-11T14:54:15ZseamusleePublic View link does not show from Scheduled and Sent screenWhen you view a list of scheduled and sent mailings you cannot access the Public View url link even tho the code suggests it should be availableWhen you view a list of scheduled and sent mailings you cannot access the Public View url link even tho the code suggests it should be available5.10https://lab.civicrm.org/dev/core/-/issues/3553Preview as HTML doesn't open window at all2022-06-11T14:50:54ZscardiniusPreview as HTML doesn't open window at allCRM_Mailing_BAO_TrackableURL::getTrackerURL() requires id of mailing but after https://lab.civicrm.org/dev/mail/issues/20 mailing_id is removed from params to Mailing.preview
https://github.com/civicrm/civicrm-core/commit/0075b0cb75e542...CRM_Mailing_BAO_TrackableURL::getTrackerURL() requires id of mailing but after https://lab.civicrm.org/dev/mail/issues/20 mailing_id is removed from params to Mailing.preview
https://github.com/civicrm/civicrm-core/commit/0075b0cb75e5422660366acf280538167369d8ba#diff-d08e5d3ceca1972df6d467b2824ffab5R279
errors from api rest
```
{"error_code":"unknown error","sql":"INSERT INTO civicrm_mailing_trackable_url (url ) VALUES ('https:\/\/onet.pl' )
[nativecode=1364 ** Field 'mailing_id' doesn't have a default value]",
"tip":"add debug=1 to your API call to have more info about the error",
"is_error":1,
"error_message":"DB Error: unknown error",
"debug_information":"INSERT INTO civicrm_mailing_trackable_url (url ) VALUES ('https:\/\/onet.pl' ) [nativecode=1364 ** Field 'mailing_id' doesn't have a default value]"}
```5.12.3https://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/3544Bounce processing doesn't catch pattern "user doesn't exist"2022-06-11T14:50:31ZDetlev SieberBounce processing doesn't catch pattern "user doesn't exist"CiviCRM bounce processing analyzes the bounce text patterns, and decides what kind of bounce type it is. This is a fragile process, but there seems to be no better solution, since there is no general standardization of bounce patterns.
...CiviCRM bounce processing analyzes the bounce text patterns, and decides what kind of bounce type it is. This is a fragile process, but there seems to be no better solution, since there is no general standardization of bounce patterns.
Some email providers throw the bounce pattern "user doesn't exist", which is not found, and therefore results in bounce_type "syntax". However, this bounce pattern should result in immediately switching the email address to "inactive".
Solution is:
> insert into civicrm_mailing_bounce_pattern (bounce_type_id, pattern) values (6, 'user doesn\'t exist');
5.9Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3542Move the cache for `CRM_Extension_Browser` out of the filesystem and use a `S...2022-06-16T02:21:42ZtiotsopMove the cache for `CRM_Extension_Browser` out of the filesystem and use a `SqlGroup` insteadThe current code in `CRM_Extension_Browser` is coded specifically for an adhoc, file-based caching logic. The recommendation standard is basically to change the backing/storage from a JSON file to the civicrm_cachetable (at least, for th...The current code in `CRM_Extension_Browser` is coded specifically for an adhoc, file-based caching logic. The recommendation standard is basically to change the backing/storage from a JSON file to the civicrm_cachetable (at least, for the typical usage).
Ref [#2](https://lab.civicrm.org/dev/cloud-native/issues/2#note_4790)5.52.0tiotsoptiotsophttps://lab.civicrm.org/dev/core/-/issues/3522Soften messages for read-only extensionsDir2022-06-11T14:41:07ZtiotsopSoften messages for read-only extensionsDirImprove messaging when someone has a different policy for managing `extensionsDir`.This a continuation of this [PR](https://github.com/civicrm/civicrm-core/pull/11895). Most of the messaging update has already been done. There is only on...Improve messaging when someone has a different policy for managing `extensionsDir`.This a continuation of this [PR](https://github.com/civicrm/civicrm-core/pull/11895). Most of the messaging update has already been done. There is only one message ("Read-Only Extensions"). It still encourages web-writable policy, but it lowers the severity and presents it a choice ("if you want X, do Y").
Probably, changing the `warning` into a `notice` is the only thing to update:- a `warning` implies something is wrong, while a `notice` says it's merely out of the ordinary.5.9tiotsoptiotsophttps://lab.civicrm.org/dev/core/-/issues/3231Correct Mailing Report unique Count2022-04-22T15:51:27ZsunilCorrect Mailing Report unique CountMailing -> Scheduled and Sent Mailings -> Report
Unique Opens -> Report
Total Opens -> Report
Both Report show same count.Mailing -> Scheduled and Sent Mailings -> Report
Unique Opens -> Report
Total Opens -> Report
Both Report show same count.5.10https://lab.civicrm.org/dev/core/-/issues/3224Search Kit doesn't display related contact custom fields2022-04-22T15:51:13ZJonGoldSearch Kit doesn't display related contact custom fieldsIf you have a Search Kit that includes a related contact, displaying the related contact's custom data will actually show the main contact's custom data.
See screenshots below. Teresa has a most important issue of "Education", Santina'...If you have a Search Kit that includes a related contact, displaying the related contact's custom data will actually show the main contact's custom data.
See screenshots below. Teresa has a most important issue of "Education", Santina's is "Social Justice". When I build a search and include both the `Constituent Information: Most Important Issue` and `Contact Related Contacts: Constituent Information: Most Important Issue` columns, they both have the same value.
![Selection_1184](/uploads/ba7c2f496b001f8bd86536d9419b0035/Selection_1184.png)
![Selection_1185](/uploads/d28c833e256a6dcc091d5f1629a124f2/Selection_1185.png)
![Selection_1186](/uploads/65af3fd4f21cb09b60274a700ee2f580/Selection_1186.png)5.42.0https://lab.civicrm.org/dev/core/-/issues/2977When adding custom data set change default selected option2021-12-14T22:43:19ZBarijohnWhen adding custom data set change default selected optionOverview
----------------------------------------
Currently when adding a custom data set I always swap the default settings for showing the set. So I untick the Collapse this set on initial display and tick Collapse this set in Advanced...Overview
----------------------------------------
Currently when adding a custom data set I always swap the default settings for showing the set. So I untick the Collapse this set on initial display and tick Collapse this set in Advanced Search.
In my experience if I kept the default settings my Advanced Search can get out of control quite quickly but when looking at a summary page I have to keep clicking to open up the data set.
Current behaviour
----------------------------------------
![Screenshot_2021-12-02_at_13.32.34](/uploads/0ddb75a1bfa2571771c69fdd1a923e17/Screenshot_2021-12-02_at_13.32.34.png)
Proposed behaviour
----------------------------------------
![Screenshot_2021-12-02_at_13.32.57](/uploads/3de94103ee8053082d5da96bac3f092c/Screenshot_2021-12-02_at_13.32.57.png)
Comments
----------------------------------------
This might be something unique to how I like to set custom data sets up. So would be good to find the community consensus.5.46.0https://lab.civicrm.org/dev/core/-/issues/2910Remove the CiviCRM Connections functionality (Task 1 of 2) - Remove the menu ...2022-08-09T14:44:38Zjustinfreeman (Agileware)Remove the CiviCRM Connections functionality (Task 1 of 2) - Remove the menu item**CiviCRM Connections** is available under the System Settings menu. From what I can tell this feature is an artefact that is no longer being used. Happy to be educated on the subject if this is not the case.
Cannot find any references ...**CiviCRM Connections** is available under the System Settings menu. From what I can tell this feature is an artefact that is no longer being used. Happy to be educated on the subject if this is not the case.
Cannot find any references to it in the documentation:
- https://docs.civicrm.org/user/en/latest/
- https://docs.civicrm.org/sysadmin/en/latest/
Googling doesn't reveal anything relevant either.
So can we remove this code from the system?
![Screenshot_20211013_091315](/uploads/724bb11ee0a345f31be5b369b22af959/Screenshot_20211013_091315.png)
Agileware Ref: CIVIBLD-2865.44.0https://lab.civicrm.org/dev/core/-/issues/2730Consider replacing fopen() call in CRM_Utils_File::isIncludable with stream_r...2021-08-09T12:58:54ZDaveDConsider replacing fopen() call in CRM_Utils_File::isIncludable with stream_resolve_include_path()The problem is depending on how strict your setup is, some code that uses the error suppression operator (e.g. `@unlink('file_which_may_not_exist')`) behaves differently in php 8 and doesn't get supressed, either flooding your logs or ma...The problem is depending on how strict your setup is, some code that uses the error suppression operator (e.g. `@unlink('file_which_may_not_exist')`) behaves differently in php 8 and doesn't get supressed, either flooding your logs or making civi unusable in some cases.
In particular the api magic function provider uses an algorithm for e.g. getfields, where often the first guess is wrong, leading to an error.
isIncludable was added in 2011, and while stream_resolve_include_path was available at that time, it was introduced into php in 2010, so it's possible not a lot of sites had it.5.41.0https://lab.civicrm.org/dev/core/-/issues/2650Use consistent token syntax for pseudoconstants2022-09-01T07:55:13ZeileenUse consistent token syntax for pseudoconstantsAt some point we want to have consolidated token code. One thing that is missing at the moment is agreement as to what tokens we are working towards. (this came out of discussion fixing for php8 in https://github.com/civicrm/civicrm-core...At some point we want to have consolidated token code. One thing that is missing at the moment is agreement as to what tokens we are working towards. (this came out of discussion fixing for php8 in https://github.com/civicrm/civicrm-core/pull/20591) I want to constrain this issue to the very narrow question of syntax for pseudoconstants & unique names in tokens.
If we look at [the test](https://github.com/civicrm/civicrm-core/blob/275686a34ca7bf5e9c4d6653cd8cca5cf15e36cf/tests/phpunit/CRM/Contribute/Form/Task/PDFLetterCommonTest.php#L264) we can see the current tokens supported by the existing code. A somewhat different set is supported by the [TokenProcessor class for contributions](https://github.com/civicrm/civicrm-core/blob/c2a33d9c890f81bf2287351f0a830ef58b1dc98c/CRM/Contribute/Tokens.php#L26)
So we can see that in one place you would pass
{contribution.contribution_status_id} to get 'Pending'
and in the other it would be {contribution.status}
We are also 'promoting' (by presenting in the UI selector) {contribution.contribution_source} over {contribution.source} in how we present tokens, even though in this case I think both work.
I would propose that our preferred tokens adhere to apiv4 style conventions as much as possible. Preferring means that we work towards the following (on an ad hoc basis).
1) the tokens that are selectable in the UI on the form return the preferred variants
2) we support the preferred variants in tested code on both token methods
3) we run db update scripts to replace the less preferred with the preferred in the msg_template and action_schedule tables as we feel safe doing so
4) we deprecate less preferred variants by adding deprecation notices to places where they are used, when we feel safe doing so.
Proposed conventions
1) deprecate unique name prefixing - ie prefer {contribution.source} over {contribution.contribution_source}
2) actual field name returns the value of that field - ie {contribution.contribution_status_id} would return a number rather than a string
3) we use apiv4 style tokens for labels - ie {contribution.contribution_status_id:label}
(out of scope for this issue = apiv4 style custom field names or custom fields in general, returning calculated values for eg. contribution.check_number)
If we go with the above the specific action I will add to my (long) todo list is to engage with fixing contribution_status_id to make it consistent between the 2 classes and the selector - ie
1) Replace the 'advertised' token from
``` 'contribution.contribution_status_id:label' => 'Contribution Status'```
'contribution.contribution_status_id:label' => 'Contribution Status'
2) add tested support for ```'contribution.contribution_status_id:label'``` to both classes
3) fix any core message templates to use 'contribution.contribution_status_id:label'
4) fix the upgrade script to str_replace 'contribution.contribution_status_id' in the message template table (only)
The other fields in this space that are currently inconsistent are
- financial_type_id, campaign, payment instrument id, cancel_date, source
@colemanw @totten @seamuslee @mattwire5.43.0https://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/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.1