CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-09-05T13:38:59Zhttps://lab.civicrm.org/dev/core/-/issues/1891"applyLocale()" does not apply desired locale when "inheritLocale" is set2023-09-05T13:38:59Zhaystack"applyLocale()" does not apply desired locale when "inheritLocale" is setFollowing up on #1890 it seems that the locale string in the `language` column in the `civicrm_uf_match` table is also redundant.
It is set [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM...Following up on #1890 it seems that the locale string in the `language` column in the `civicrm_uf_match` table is also redundant.
It is set [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/ConfigSetting.php#L173) when there is a locale requested in a URL that uses the `lcMessages` query param or when there's an existing locale set in the session.
The session locale is set from the `$ufm->language` locale [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/ConfigSetting.php#L187) when there's a logged-in user and the locale hasn't been determined by the `lcMessages` query param or there's no locale set in the session.
I cannot find anywhere else in the CiviCRM Core code where `$ufm->language` is read or set, so this appears to be circular logic that seems redundant to me.
Can we remove it since it's never actually used for anything practical?
**Correction:** both the `$ufm->language` and `lcMessages` session variable are set [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Admin/Form/Setting/Localization.php#L336-L338), but this only sets the locale for the Contact/User that saves that particular form. It doesn't alter the circularity of the logic in `applyLocale()`.5.29.0haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/1890Remove `ufUniqID` from Core2023-09-05T13:38:55ZhaystackRemove `ufUniqID` from CoreI'm auditing the `synchronize()` procedure with the aim of rationalising what happens during page loads in WordPress - due to reports of multiple Contacts being created (see [this Mattermost thread](https://chat.civicrm.org/civicrm/pl/iu...I'm auditing the `synchronize()` procedure with the aim of rationalising what happens during page loads in WordPress - due to reports of multiple Contacts being created (see [this Mattermost thread](https://chat.civicrm.org/civicrm/pl/iurq3k4pkj8mpbxmb7kttyg5xo) for example) and have found that the `ufUniqID` session variable is only ever *set* and never *read* in CiviCRM.
It is set in Core in:
* `CRM_Core_BAO_UFMatch::synchronize()` [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/UFMatch.php#L96) and [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/UFMatch.php#L128)
And in CiviCRM WordPress by the REST API (presumably for consistency with Core) in:
* `CiviCRM_WP_REST\Civi\Mailing_Hooks\Plugin::set_civi_user_session()` [here](https://github.com/civicrm/civicrm-wordpress/blob/7fc81f0289d63dd6577d7e7046303cc6dc850f8f/wp-rest/Plugin.php#L355)
Can we remove it since it's never actually used?5.29.0https://lab.civicrm.org/dev/core/-/issues/1858User account form action not passing along contact id correctly possibly lead...2022-08-17T13:52:08ZseamusleeUser account form action not passing along contact id correctly possibly leading to duplicate contactsOverview
----------------------------------------
When submitting the back office user account creation user contact action the contact id of the user you are creating the account for is not properly passed along and can depending on you...Overview
----------------------------------------
When submitting the back office user account creation user contact action the contact id of the user you are creating the account for is not properly passed along and can depending on your unsupervised dedupe rule create duplicate contact record
Reproduction steps
----------------------------------------
1. Click on Contacts -> Find and Merge Duplicate Contacts and edit the Unsupervised Individual rule to change it from just email to use first and last name as well
1. Navigate to an individual's record that doesn't have a CMS user account
1. Select Actions -> Create User Record
1. Possibly / likely receive a fatal error due to duplicate record in civicrm_uf_match, find that a duplicate contact has been created
Current behaviour
----------------------------------------
Duplicate contact is created when the CMS record is created
Expected behaviour
----------------------------------------
No Duplicate contact is created and the CMS account is properly connected to the contact you are creating the user account for
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __CiviCRM:__ _5.26.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.1__
* __CMS:__ _Drupal 8_5.29.0https://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/3385Event cart hidden/enabled in buildkit 5.29 RC2022-04-22T16:22:30ZAndie HuntEvent cart hidden/enabled in buildkit 5.29 RCWhen viewing an event info page, there's a "Add to Cart" button. It looks like the eventcart extension is enabled (looking via the API) but it is not visible through the UI.
I don't know if this is for buildkit only or something that w...When viewing an event info page, there's a "Add to Cart" button. It looks like the eventcart extension is enabled (looking via the API) but it is not visible through the UI.
I don't know if this is for buildkit only or something that will take effect for everyone when they download the tarball, but it shouldn't be the default for buildkit to enable the event cart.5.29.0https://lab.civicrm.org/dev/core/-/issues/3379Can't meaningfully disable self-service transfer/cancellation once enabled2022-04-22T16:22:15ZJonGoldCan't meaningfully disable self-service transfer/cancellation once enabledTo replicate:
* Create an event. Enable self-service transfer/cancellation.
* Register a participant, receive the email to the self-service update page.
* Disable self-service transfer/cancellation.
* Click the self-service link. Note t...To replicate:
* Create an event. Enable self-service transfer/cancellation.
* Register a participant, receive the email to the self-service update page.
* Disable self-service transfer/cancellation.
* Click the self-service link. Note that you can still load the self-service page even though self-service has been disabled.
This is an easy fix, but given the many self-service issues, I think a refactor is in order first, so I'll submit that before proceeding.5.29.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3350Event registration form has inconsistent labelling2022-04-22T16:21:16ZJonGoldEvent registration form has inconsistent labellingFollowing on from core#1613 - [PR 16651](https://github.com/civicrm/civicrm-core/pull/16651) updated the button text but nor corresponding instructions.
Hat tip to Bryan for discovering this and [posting on Stack Exchange](https://civic...Following on from core#1613 - [PR 16651](https://github.com/civicrm/civicrm-core/pull/16651) updated the button text but nor corresponding instructions.
Hat tip to Bryan for discovering this and [posting on Stack Exchange](https://civicrm.stackexchange.com/questions/35964/misleading-instructions-in-civievent-registration-template-for-multiple-particip).
https://github.com/civicrm/civicrm-core/pull/176955.29.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3334Option to update expired memberships as part of the job.process_membership2022-04-22T16:17:32ZMichael McAndrewOption to update expired memberships as part of the job.process_membershipIt looks like *expired* memberships are excluded from job.process_membership for performance reasons.
There are (edge) cases where this is problematic. For example, lets say that I increased the grace membership period from 3 to 6 month...It looks like *expired* memberships are excluded from job.process_membership for performance reasons.
There are (edge) cases where this is problematic. For example, lets say that I increased the grace membership period from 3 to 6 months. People whose membership ended 4 months ago will not have their membership status updated from expired to grace.
The other three membership statuses that are excluded from membership updates are 'Deceased', 'Pending' and 'Cancelled'.
Not sure if there is a use case for also re-calculating these but interested in people's thoughts.
Proposed solution: add an option to process normally excluded membership statuses (maybe just expired) from job.process_membership.5.29.0https://lab.civicrm.org/dev/core/-/issues/3283Contribution Summary Report: The "general total" row does not take the curren...2022-04-22T15:53:43ZdmunioContribution Summary Report: The "general total" row does not take the currency filteredWhen the contribution summary report is used by filtering for a currency other than the site's default currency, the "grand total" row shows the sign of the default currency instead of the filtered currency.
![image](/uploads/e65afcbdde...When the contribution summary report is used by filtering for a currency other than the site's default currency, the "grand total" row shows the sign of the default currency instead of the filtered currency.
![image](/uploads/e65afcbdde35490ab7602d21161c13f0/image.png)
This issue is resolved by changing the code of the following line: https://github.com/civicrm/civicrm-core/blob/2235525e475edd2573a1ad71897cd42d2ea3cdfd/templates/CRM/Report/Form/Layout/Table.tpl#L139
By the following code:
```php
{if $currencyColumn}
{$grandStat.$field|crmMoney:$row.$currencyColumn}
{else}
{$grandStat.$field|crmMoney}
{/if}
```5.29.0https://lab.civicrm.org/dev/core/-/issues/3260Icon in status message after saving a civireport is misleading2022-04-22T15:53:01ZDaveDIcon in status message after saving a civireport is misleadingIt's the 'alert' icon instead of success.
1. Go to any CiviReport.
1. From the Actions dropdown choose Save.
1. Icon indicates a warning but it's all good.
Also for "save a copy".It's the 'alert' icon instead of success.
1. Go to any CiviReport.
1. From the Actions dropdown choose Save.
1. Icon indicates a warning but it's all good.
Also for "save a copy".5.29.0https://lab.civicrm.org/dev/core/-/issues/2705CiviCRM not wrapping long lines in emails2021-07-28T01:08:46ZSandor SemseyCiviCRM not wrapping long lines in emailsOverview
----------------------------------------
CiviMail (and FlexMailer) does not break lines in emails. The SMTP protocol only allows 1000 chars per line. So on a mailserver this wrapping is enforced and it can cause DKIM signatures ...Overview
----------------------------------------
CiviMail (and FlexMailer) does not break lines in emails. The SMTP protocol only allows 1000 chars per line. So on a mailserver this wrapping is enforced and it can cause DKIM signatures to get invalid.
Further [details](https://civicrm.stackexchange.com/questions/39172/line-wrapping-breaking-lines-longer-than-998-characters-in-civicrm-civimail).
Reproduction steps
----------------------------------------
1. Go to **Mailings >> New Mailing**
1. Create Email with a line with more than 1000 chars.
1. Send Email (you can redirect to DataBase)
1. Inspect sent email
Current behaviour
----------------------------------------
Lines are not wrapped.
Expected behaviour
----------------------------------------
Lines should be hard-wrapped (inserting a line break) after a specified number of characters (I would suggest a default for 990).
Comments
----------------------------------------
If this gets confirmed, we are to happy to jump in and implement this functionality.5.29.0Sandor SemseySandor Semseyhttps://lab.civicrm.org/dev/core/-/issues/1113Decimal Separator - Invalid value "total_amount" (NaN,N) creating or editing ...2021-05-05T13:51:47ZCésarDecimal Separator - Invalid value "total_amount" (NaN,N) creating or editing a membershipHello,
I see a error with one field associated with "Membership Payment and Receipt" but i think error is a "Decimal Separator"
Steps to reproduce this error:
1. Change the decimal separator to "," for example (Thousands Separator nee...Hello,
I see a error with one field associated with "Membership Payment and Receipt" but i think error is a "Decimal Separator"
Steps to reproduce this error:
1. Change the decimal separator to "," for example (Thousands Separator needs diferent format):
* ![image](/uploads/20f9093fbb84d217900f1a553f5bca0c/image.png)
2. Create a new membership or edit, but dont complete all fields required:
* ![image](/uploads/5f4c966831a5846c67dd952c161948c9/image.png)
3. Click submit button and show correct validation:
* ![image](/uploads/54f806bce74a26f8995fe59882ef825c/image.png)
4. Next complete the field required and click submit:
* ![image](/uploads/689e7656c42da0cda0d0162d93bba5f1/image.png)
5. In this point appears the validation of "total_amount"
* ![image](/uploads/23d1501cc3dc0d8e16c5ba04fb600674/image.png)
6. If click in "Record Membership Payment?" checkbox you see the incorrect value.
* ![image](/uploads/3596b91ddf641a4fc00501e1f710d4ce/image.png)
7. In this point, you need clear the value and uncheck checkbox for save the membership.
Its observed in CiviCRM 5.15.15.29.0https://lab.civicrm.org/dev/core/-/issues/1795Using Parent tag in search form doesn't pull contacts marked with child tag i...2021-04-01T11:40:23ZMonish DebUsing Parent tag in search form doesn't pull contacts marked with child tag in search form resultReproduction steps
----------------------------------------
Steps to replicate:
1. Create a parent tag A and child tag A1
2. Create/update contact and tag with A1
3. Go to 'Find Contacts' or 'Find Contributions' and search by Tag - A
...Reproduction steps
----------------------------------------
Steps to replicate:
1. Create a parent tag A and child tag A1
2. Create/update contact and tag with A1
3. Go to 'Find Contacts' or 'Find Contributions' and search by Tag - A
Current behaviour
----------------------------------------
```
1. In 'Find Contact' result, it doesn't show contact which is tagged with child tag A1
2. In 'Find Contributions' result, it doesn't pull contribution(s) of contact tagged with child tag A1
```
Expected behaviour
----------------------------------------
Searching using a parent tag should automatically include the contacts which are in parent tag A and in its n child tag(s) - An. In this use-case it should show contact tagged with child A1 tag.
Comments
----------------------------------------
ping @JoeMurray @eileen @seamuslee @lcdweb5.29.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/1880custom data insert/update error if using reserved words2021-01-03T21:18:35Zlcdwebcustom data insert/update error if using reserved wordsRan into a situation where a client had created a custom field titled "use", which resulted in a column in the corresponding value table with that name. Because it is a reserved word, it triggered errors during insert/update. This is eas...Ran into a situation where a client had created a custom field titled "use", which resulted in a column in the corresponding value table with that name. Because it is a reserved word, it triggered errors during insert/update. This is easily remedied with the use of backticks (which we're starting to use more consistently anyway).
One could argue we should address this upstream and prevent the creation of fields with reserved names. But that won't address previously created fields, and adding backticks to our SQL is a good policy anyway.
PR forthcoming.5.29.0lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/1280On behalf label / Honoree Title / Honoree Description not translatable on con...2020-12-16T20:57:39ZsamuelsovOn behalf label / Honoree Title / Honoree Description not translatable on contribution pageIn the contribution page, Title tab configuration, it's not possible to translate the content of :
* Honoree Section Title
* Honoree Introductory Message
To clarify a bit :
* There are no i18n `fa-language` icon (like in footer messa...In the contribution page, Title tab configuration, it's not possible to translate the content of :
* Honoree Section Title
* Honoree Introductory Message
To clarify a bit :
* There are no i18n `fa-language` icon (like in footer message above)
* When switching language, it displays the proper language value for those fields but it updates the default language anyway
![Screenshot_2019-10-01_Title_and_Settings__Make_a_Donation_](/uploads/9a69e874a0aaa744864bb67ca57cb793/Screenshot_2019-10-01_Title_and_Settings__Make_a_Donation_.png)
The information is not stored in a typical database column so we can't use the standard way of translating :
```sql
SELECT * from civicrm_uf_join
WHERE entity_table = 'civicrm_contribution_page';
+----+-----------+----------------+---------------------------+-----------+--------+-------------+-----------------------------------------------------------------------------------------------------------------------------+
| id | is_active | module | entity_table | entity_id | weight | uf_group_id | module_data |
+----+-----------+----------------+---------------------------+-----------+--------+-------------+-----------------------------------------------------------------------------------------------------------------------------+
| 45 | 1 | soft_credit | civicrm_contribution_page | 1 | 1 | 13 | {"soft_credit":{"soft_credit_types":["1","2"],"en_US":{"honor_block_title":"Dedicate Your Donation","honor_block_text":""}}} |
+----+-----------+----------------+---------------------------+-----------+--------+-------------+-----------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.00 sec)
```5.29.0https://lab.civicrm.org/dev/core/-/issues/1928Collapsed custom field set for activities with a required radio makes case ac...2020-09-18T15:11:46ZDaveDCollapsed custom field set for activities with a required radio makes case activity buttons seem disabledMight be from the recent jquery radio validation update. Haven't followed it through yet. Not even sure if it's specific to radio yet.
1. Create a custom fieldset for activities.
1. Make it apply to all activity types (not relevant just...Might be from the recent jquery radio validation update. Haven't followed it through yet. Not even sure if it's specific to radio yet.
1. Create a custom fieldset for activities.
1. Make it apply to all activity types (not relevant just makes this quicker).
1. Make it collapsed by default.
1. Add a radio field.
1. Make it required.
1. Administer - Customize - Display Prefs - Turn off popups (near the bottom). (Only relevant because then you can see the issue for all case activities - when it's on you only notice it for open case/creating a case.)
1. Create a case.
1. Fill out the client, subject, and case type but leave the collapsed custom field section collapsed.
1. Click Save. It appears as though nothing happened, but if you open the custom fieldset you can see why.5.29.0https://lab.civicrm.org/dev/core/-/issues/1855Allow different output formats for CiviReport results, like native excel form...2020-09-03T15:17:35ZDaveDAllow different output formats for CiviReport results, like native excel format, and untangle codeThis [started as a question](https://github.com/civicrm/civicrm-core/pull/17145) like "without having to patch core or adding another `if outputformat == 'x'` into some already awkward code in core, how can an extension implement a new o...This [started as a question](https://github.com/civicrm/civicrm-core/pull/17145) like "without having to patch core or adding another `if outputformat == 'x'` into some already awkward code in core, how can an extension implement a new output format for civireport results?"
My own motivation for this is a couple things:
1. I've had to look at the related code blocks more than once and it takes at least 15 minutes just to wade through and get to a point where you can start looking into what you were originally trying to look into. Then you get lost again while circling back.
1. I like the idea of being able to prevent people sending me listings of contacts in *pdf* format. No I will not import or analyze this data you've sent me in pdf format. (You can prevent this currently, it would just be easier after.)
1. The email body when sent by the mail_report job is hardcoded. There's been one or two requests to have it be more configurable. You can sort of do it with hook_alterMailParams now but it's not the most robust. I'm not fully addressing that here with any UI changes, but the proposed changes set the stage for it being easier to get there. At the very least you would now be able to write an extension that simply extends the existing handler class (e.g. csv) and overrides the small function that returns the text.
1. I'm currently doing this a different way and don't know if I would switch, but it opens up the possibility for an output handler that provides templates into which the data is inserted which then automatically is available in the existing UI and mail_report job. For most people this would mean a pdf template, but for people like me this means something like an excel template with a prebuilt pivot table and the handler would update the source rows so the pivot would automatically update.
And then beyond my own motivation some other possibilities which are theoretical:
1. A variation of the last point above would be an outputhandler where when run by mail_report it connects to another network service and sends the data there server-to-server. You could set this up via cron exactly the same way you normally use the mail_report job. The equivalent download would then still also be automatically available to users to do manually the same as any other civireport.
## So...
After doing some investigating, can summarize how the current output code works as
* type `sendmail`, which gets the output as a string and sends an email, OR
* type `not sendmail`, which starts a download. Note that "download" technically is also a string, but sent to the browser instead of used in an email.
Then further
* Some of the convoluted nature of the existing code is partly because how to get either of those is different depending on the output format (e.g. csv/pdf/etc).
* Also note that "download" for type 'print' is actually the same as other downloads it's just that you don't need to change http headers first. So that's also adding to the awkwardness a bit in the current code because the way it's written it almost seems like a different code path.
**THEREFORE --->**: My thinking is to start on this by having a common interface to get the string. I mean interface in the general sense of the word, not necessarily OO Interface but maybe. But **then it reduces the number of if/else's to just one**:
* If sendmail,
* Get string (delegated to the output handler).
* Send email (for now extract this to its own function just for readability).
* Else
* Delegate to output handler to set headers and send string to browser (aka download).
There's a little more to it, and it can borrow a bit from the existing PRs, but that's what I'm thinking in terms of first steps to untangling. I will work on a PR.
Then the next steps after that would be to allow for other output handlers, whether it be by a new hook or existing hook or other.
#### Misc notes
* save/copy/delete are handled in beginPostProcess and do nothing in endPostProcess
* there's a difference between compileContent() and the output content. compileContent() is not used for csv, but is used for pdf and 'print'.
* endPostProcess has 4 different "categories":
1. "add contacts to group", which doesn't output anything
2. _sendmail, which uses the other output handlers but requests the results as a string.
* defaults to print, but also does csv or pdf and then exits
* There is also some hardcoding of the email body, partly because it includes a computed url, but it would be nice not to hardcode this.
* Note pdf is called with TRUE for 3rd param, so that it returns the pdf as a string.
3. Download, which uses the other output handlers but requests the results as a download.
* Note that print is a download technically, it just goes to the browser window. Csv or pdf starts an attachment download.
* Here pdf is the default, but at the point in the code where that happens it has to be either print or pdf and print would have been already handled.
* Note pdf is called with FALSE for 3rd param.
* csv is done by a wrapper around the same function that is used in _sendmail
4. Tests that extend CiviReportTestCase use _resultSet/getResultSet() and have _outputMode blank, so endPostProcess (which gets called from preProcess because force=1 here) does none of the above and just stores the results in an array.5.29.0https://lab.civicrm.org/dev/core/-/issues/1922Downloaded Invoice activity attaches non wkhtmltopdf invoice2020-09-02T17:39:25ZDevAppDownloaded Invoice activity attaches non wkhtmltopdf invoiceWhen using wkhtmltopdf as the PDF engine, the invoices are emailed / printed correctly.
However, when an invoice is downloaded, it creates an activity against the contact with a copy of the invoice attached to the activity. This invoic...When using wkhtmltopdf as the PDF engine, the invoices are emailed / printed correctly.
However, when an invoice is downloaded, it creates an activity against the contact with a copy of the invoice attached to the activity. This invoice appears to not use the wkhtmltopdf engine, so the copy displays wrong.
When I turned off wkhtmltopdf, the invoice then appears the same. Bug appears to be downloaded invoice activity isn't using the wkhtmltopdf engine when specified.
![invoice_-_printed_emailed](/uploads/cc3ed15c0470d91f8ba57a187221f0bc/invoice_-_printed_emailed.png)
![invoice_-_downloaded](/uploads/646eef8b8a96949d8fbafd7a1df10290/invoice_-_downloaded.png)
![invoice_downloaded_activity](/uploads/049377a00c4c67db09b6b41f75a8002d/invoice_downloaded_activity.png)5.29.0https://lab.civicrm.org/dev/core/-/issues/1803Update guzzle to d8 latest2020-09-02T07:13:33ZeileenUpdate guzzle to d8 latestI discovered that there was an incompatibility between the guzzle version in Omni vs Civi. It is an error handling issue so it was showing up in the fileExists function in one of our status checks & is fairly low impact.
On digging it s...I discovered that there was an incompatibility between the guzzle version in Omni vs Civi. It is an error handling issue so it was showing up in the fileExists function in one of our status checks & is fairly low impact.
On digging it seems the issue was due to Omnipay having guzzle 6.5.x & CiviCRM having 6.3.x & the Omnipay one getting picked up for a core civi call but then picking up one class from the core civi one.
Obviously composer & extensions continues to be a challenge but here I think the immediate fix is to update CiviCRM Guzzle to the one that ships with latest Drupal 8 - currently version": "6.5.4",`
https://git.drupalcode.org/project/drupal/-/blob/8.9.x/composer.lock#L1062
For now I'm downgrading Omnipay guzzle to match current CiviCRM
@seamuslee5.29.0https://lab.civicrm.org/dev/core/-/issues/1982Case open: doesn't respect case roles "creator" param if unset2020-09-01T22:57:35ZlcdwebCase open: doesn't respect case roles "creator" param if unsetto replicate:
1. create a new case type
2. in the list of case roles, uncheck the "assign to creator" checkbox for the default case coordinator role
3. create a new case on a contact record
**expected result:** no case roles created
*...to replicate:
1. create a new case type
2. in the list of case roles, uncheck the "assign to creator" checkbox for the default case coordinator role
3. create a new case on a contact record
**expected result:** no case roles created
**actual result:** case coordinator role is created and assigned to the logged in user5.29.0lcdweblcdweb