Development issueshttps://lab.civicrm.org/groups/dev/-/issues2021-10-16T13:37:50Zhttps://lab.civicrm.org/dev/wordpress/-/issues/72register_rest_route was called incorrectly, missing permission_callback argum...2021-10-16T13:37:50Zryan_cogregister_rest_route was called incorrectly, missing permission_callback argument via wp-cliSeveral CiviCRM REST endpoints are being registered incorrectly with WordPress. The following messages occur when using wp-cli with Wordpress 5.5 and CiviCRM 5.28.3:
```
PHP Notice: register_rest_route was called <strong>incorrectly</s...Several CiviCRM REST endpoints are being registered incorrectly with WordPress. The following messages occur when using wp-cli with Wordpress 5.5 and CiviCRM 5.28.3:
```
PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/url</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/url</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/open</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/open</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/authorizeIPN</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/authorizeIPN</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/ipn</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/ipn</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/pxIPN</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/pxIPN</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/cxn</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/cxn</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/widget</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/widget</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/soap</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>civicrm/v3/soap</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/htdocs/wp-includes/functions.php on line 5225
```https://lab.civicrm.org/dev/core/-/issues/1983Total Tax Amount on the Contribution (generated in backoffice/offline) no lon...2020-09-01T22:57:35ZKarinGTotal Tax Amount on the Contribution (generated in backoffice/offline) no longer adds up to sum of the Tax Amount for the individual line itemsThis is 5.28.x
![image](/uploads/95bbbea641887b9709aa6d28f16c472e/image.png)
I will look into this.
Issue: tax_amount on contribution = $0 -> but it should be: $35.09 in the screenshot above.This is 5.28.x
![image](/uploads/95bbbea641887b9709aa6d28f16c472e/image.png)
I will look into this.
Issue: tax_amount on contribution = $0 -> but it should be: $35.09 in the screenshot above.5.28.4https://lab.civicrm.org/dev/user-interface/-/issues/30Ability to Send Invoice with modified subject and CC it2020-09-22T02:41:28ZsunilAbility to Send Invoice with modified subject and CC itOverview
----------------------------------------
Ability to Send Invoice with CC email and with option to alter subject line.
Current behaviour
----------------------------------------
When Invoice Setting is Enabled at `CiviContribute...Overview
----------------------------------------
Ability to Send Invoice with CC email and with option to alter subject line.
Current behaviour
----------------------------------------
When Invoice Setting is Enabled at `CiviContribute Component Settings`, We get option to `Print Invoice` Or `Email Invoice`.
When we click on `Email Invoice`, we can choose From Address and Add additional Comment.
When Email Send:
For online payment form:
- Subject:`Contribution Invoice: Help Support CiviCRM!- Test User`
- BCC and CC emailed copied from Online page and used to send email.
For Offline Submission:
- Subject:`Invoice- Test User`
- BCC and CC : No possible
You can modify the subject, for that we need to alter the subject line in invoice template.
New behaviour
----------------------------------------
You can override Email Subject from UI, its optional, if you don't provide subject, default subject form invoice template get used.
CC Field is available. that will override online page CC email, and for offline payment its new option to send CC email.
![Screenshot_2020-08-29_at_7.54.52_AM](/uploads/0bcccfd49bc7a72697cdd97f604e12f3/Screenshot_2020-08-29_at_7.54.52_AM.png)
----------------------------------------
https://github.com/civicrm/civicrm-core/pull/182865.31.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.0lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/1981RFC compliant mail address not allowed2023-04-23T05:03:24ZDetlev SieberRFC compliant mail address not allowedOverview
----------------------------------------
CiviCRM has some kind of format check when entering emails.
However, in certain cases it is not possible to enter email addresses, although they rfc compliant.
Example: firstname-lastn...Overview
----------------------------------------
CiviCRM has some kind of format check when entering emails.
However, in certain cases it is not possible to enter email addresses, although they rfc compliant.
Example: firstname-lastname-@example.org
Current behaviour
----------------------------------------
When an email address with a "-" at the end (as firstname-lastname-@example.org ) is entered in a profile or in the contact summary, an error message occurs, the contact cannot be saved.
Expected behaviour
----------------------------------------
It should be possible to enter an email address like: firstname-lastname-@example.org
Environment information
----------------------------------------
CiviCRM 5.28.2 and CiviCRM 5.24.5
I believe that worked better previously, because we have a few cases like that within our database!https://lab.civicrm.org/dev/financial/-/issues/142Order api proposal - require less line item parameters2020-12-03T10:37:27ZeileenOrder api proposal - require less line item parametersI'd like to propose that we add sensible defaults for line items when using the order api
1) price_field_id - if NONE of the rows have a price_field_id then use the default pricefield id for all of them (I don't want to open up technica...I'd like to propose that we add sensible defaults for line items when using the order api
1) price_field_id - if NONE of the rows have a price_field_id then use the default pricefield id for all of them (I don't want to open up technical analysis of dealing with multiple price sets, more complex config) - so this is just for that common use case
2) qty - if not set, default to 1
This would make the minimum required params for a 'quick config' (I hate that usage but I think we know what it means) order
```
$this->callAPISuccess('Order', 'create', [
'financial_type_id' => 'Donation',
'contact_id' => $contact1,
'line_items' => [
['line_item' => [
[
'financial_type_id' => CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'financial_type_id', 'Donation'),
'line_total' => 40,
],
[
'financial_type_id' => CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'financial_type_id', 'Member Dues'),
'line_total' => 50,
],
]],
]
]);
```
Ideally we would also accept
```
'financial_type_id' =>'Donation',
```https://lab.civicrm.org/dev/core/-/issues/1980Add Line Item v4 API2020-09-10T19:29:08ZeileenAdd Line Item v4 APIIn order to do this there is some preliminary work to do as the v3 api has handling that needs to be unpacked first. In general there are 2 parts
1) Get & Delete - the goal here is to use a more conventional hook to do this in financial...In order to do this there is some preliminary work to do as the v3 api has handling that needs to be unpacked first. In general there are 2 parts
1) Get & Delete - the goal here is to use a more conventional hook to do this in financialacls core extension
2) Create - not too sure what this stuff is doing yet....5.31.0https://lab.civicrm.org/dev/core/-/issues/1979Incorrect comparison of status_id when changing status of linked cases2020-09-07T14:31:35ZDaveDIncorrect comparison of status_id when changing status of linked casesIt ends up working anyway because it will just change the status of the other case to the same thing it already was so you don't see any problem, but it's comparing wrong and you get an E_NOTICE: `Undefined index: status_id in CRM_Case_F...It ends up working anyway because it will just change the status of the other case to the same thing it already was so you don't see any problem, but it's comparing wrong and you get an E_NOTICE: `Undefined index: status_id in CRM_Case_Form_Activity_ChangeCaseStatus::beginPostProcess() (line 137 of .../CRM/Case/Form/Activity/ChangeCaseStatus.php).`
1. Create a case.
1. Create another case.
1. Create a link cases activity and link them.
1. Create a change case status activity and check the box to update related cases.
1. Click save.
It looks like it's been this way since it was implemented: https://github.com/civicrm/civicrm-core/commit/74b15fae91a220e2b1ab6f29f6e86001743eac0d#diff-784c2a130a993b23166dadf7f1ddc489R156. The available field at that point is a label not the id (the word id here would really mean option_value.value, but that's not the issue).
So two options:
1. Just remove the `if`, since that's effectively what it's been doing this whole time.
1. Include status_id in the results returned from getRelatedCases().5.31.0https://lab.civicrm.org/dev/core/-/issues/1978Ability to submit Custom Data using Record Payment form2023-04-23T05:03:24ZsunilAbility to submit Custom Data using Record Payment formOverview
----------------------------------------
Ability to Submit/provide custom data through Record Payment Form.
Example use-case
----------------------------------------
Through online page user added contribution record using pay-...Overview
----------------------------------------
Ability to Submit/provide custom data through Record Payment Form.
Example use-case
----------------------------------------
Through online page user added contribution record using pay-later mode with pending status.
Now, customer send check, admin wanted to Record payment and upload scanned copy of check and other custom details through same form.
Currently admin has to edit contribution record and upload scanned copy in custom field and other custom details.
Current behavior
----------------------------------------
Record Payment does not show Custom Field section
Proposed behavior
----------------------------------------
Record Payment will start showing Custom Field.
In case Multiple Record payment for same contribution record, existing custom field data on contribution record get pre-populated on Record Contribution form.
![Screenshot_2020-08-27_at_9.38.54_PM](/uploads/3f4ec0341900c8cd41142b511c640a3d/Screenshot_2020-08-27_at_9.38.54_PM.png)https://lab.civicrm.org/dev/core/-/issues/1977On French sites, incorrect display of Birth date in summary tab2023-04-22T05:03:28ZsamuelsovOn French sites, incorrect display of Birth date in summary tabIn France, the preferred date format is 'dd/mm/yy'. It seems to work well except in the case of the birth date, where the format is converted to `%E%f %B %Y` :
![Screenshot_2020-08-27](/uploads/4ff66bf5bdd238a7bb5680a2bb1f97c3/Screensho...In France, the preferred date format is 'dd/mm/yy'. It seems to work well except in the case of the birth date, where the format is converted to `%E%f %B %Y` :
![Screenshot_2020-08-27](/uploads/4ff66bf5bdd238a7bb5680a2bb1f97c3/Screenshot_2020-08-27.png)
It should display `11/05/1980`https://lab.civicrm.org/dev/core/-/issues/1976Can't get addressee_display, addressee_custom with APIv32023-04-19T05:03:27ZmarcusmCan't get addressee_display, addressee_custom with APIv3Overview
----------------------------------------
If I try to get the addressee fields addressee_display or addressee_custom with APIv3, the result is empty. Using APIv4 shows the data as expected.
Reproduction steps
------------------...Overview
----------------------------------------
If I try to get the addressee fields addressee_display or addressee_custom with APIv3, the result is empty. Using APIv4 shows the data as expected.
Reproduction steps
----------------------------------------
Tried this in demo system demo.circle-interactive.co.uk
![image](/uploads/1fe900555a54bf369734286b2cd2d93f/image.png)
![image](/uploads/c33d93fca57e3ad0d6b1b71134844b44/image.png)
Current behaviour
----------------------------------------
Result:
![image](/uploads/c8030463e718ac10d9c4bf38e4039902/image.png)
Expected behaviour
----------------------------------------
Fields should contain data from the selected fields
Environment information
----------------------------------------
Tested on Civicrm 5.28.1 (demosystem) and 5.24.5 (our system)https://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/1974Changing field from Multi-Select to Select seems to still be allowed -- but i...2021-03-16T06:59:45ZnoahChanging field from Multi-Select to Select seems to still be allowed -- but is brokenOverview
----------------------------------------
When editing a Multi-Select custom field in the GUI, there are two places where the interface is misleading/broken.
### *Edit Custom Field* form
As of 5.27, "Multi-Select" is not its ...Overview
----------------------------------------
When editing a Multi-Select custom field in the GUI, there are two places where the interface is misleading/broken.
### *Edit Custom Field* form
As of 5.27, "Multi-Select" is not its own HTML type; it is the "Select" type with the "serialize" marker set to true. On the "Edit Custom Field" form ([CRM/Custom/Form/Field.php](https://github.com/civicrm/civicrm-core/blame/5.28/CRM/Custom/Form/Field.php#L328)), "serialize" is represented by a checkbox labeled "Multi-Select". This checkbox can be unchecked, but the "serialize" marker is not changed after the form is submitted.
### *Change Field Type* form
On the "Edit Custom Field" form, if the user clicks "Change Input Field Type", the "Change Field Type" form appears.
- This form still lists "Multi-Select" as an option; it is not aware of the new "serialize" scheme. So the user can change the type to "Multi-Select".
- If a field's HTML type is "Multi-Select" or "Checkbox", the user can choose to convert the field to "Select" (although this is marked "not safe"). As it has always done, Civi [updates the custom field data so that there is only one option value per record, in unserialized form](https://github.com/civicrm/civicrm-core/blob/5.28/CRM/Custom/Form/ChangeFieldType.php#L163), but new code forces the "serialize" marker to stay true, which leads to problems editing field values.
Reproduction steps
----------------------------------------
1. Create an "Alphanumeric" "Checkbox" custom field with more than one option.
1. Edit a record that has the custom field; check off at least two options and save.
1. Go back to the settings screen for the custom field; edit the field settings.
1. Click "Change Input Field Type".
1. Choose "Multi-Select" and save.
1. **Observe that "Data and Input Field" is now just "Alphanumeric"** -- the HTML type is not shown. In the database, the field has "Multi-Select" as its html_type, but this form no longer recognizes that value.
1. Click "Change Input Field Type" again.
1. Choose "Select ( Not Safe )" and save.
1. Observe the helpful warning, and click OK.
1. **Observe that "Multi-Select" is checked,** despite the fact that we supposedly just changed the field type away from Multi-Select. This is because the custom field has "serialize" set to 1, left over from the "CheckBox" type.
1. Uncheck "Multi-Select" and Save.
1. Edit the field settings again.
1. **Observe that "Multi-Select" is now checked again**, despite unchecking it and saving it.
1. Go to the record where you entered data in the custom field before.
1. **Observe that just one of the options you checked before is listed.** This is because you changed the field from Multi-Select to Select. It is expected behavior.
1. Edit the record.
1. **Observe that no value is selected** because the field data is now unserialized, but "serialize" was prevented from changing to 0, so Civi is confused. This is a regression.
Current behaviour
----------------------------------------
The UI claims to allow conversion from multi-value (serialized) types to single-value (unserialized) types, and it does convert the custom data, but doesn't flip the "serialized" switch on the custom field itself, leaving both the data and the user confused.
Expected behaviour
----------------------------------------
You should be able to convert a multi-value field to a single-value field, as you have been able to do in Civi for years. Plenty of warning is provided that this is only something you should do if you take precautions.
After converting a field in this way, the remaining (single) custom field value should appear correctly on a record's edit form.
This feature being broken is a regression.5.28.4https://lab.civicrm.org/dev/core/-/issues/1973Email & Phone storage issues in event location2020-09-18T01:07:09ZjitendraEmail & Phone storage issues in event location**Email** - Second field value cannot be saved on form submit.
To replicate -
- Navigate to Event -> Location tab - https://dmaster.demo.civicrm.org/civicrm/event/manage/location?reset=1&action=update&id=3
- Enter a value for the secon...**Email** - Second field value cannot be saved on form submit.
To replicate -
- Navigate to Event -> Location tab - https://dmaster.demo.civicrm.org/civicrm/event/manage/location?reset=1&action=update&id=3
- Enter a value for the second email field and save. The second field is empty after the form is submitted. And Email2 value is displayed on the first email field
**Phone**: Every time the Location form is submitted, a new row is inserted in phone table even if it already exist.
To replicate -
- Navigate to Event -> Location tab - https://dmaster.demo.civicrm.org/civicrm/event/manage/location?reset=1&action=update&id=3
- Fill both the phone numbers and save.
- Re-save the form without changing any value. 2 new duplicate rows have been inserted in `civicrm_phone` table.
- This happens on every submission of the Location form.
Reverting https://github.com/civicrm/civicrm-core/pull/13534/files fixes both the above issues.5.31.0https://lab.civicrm.org/dev/core/-/issues/1972Offline Membership Renewal Tax Calculation is incorrect [regression]2020-09-01T22:57:35ZKarinGOffline Membership Renewal Tax Calculation is incorrect [regression]One of our clients reporting a regression in TaxMath -> this is straight up CiviCRM:
Before: 5.24.x -> Aug. 04, 2020:
![image](/uploads/bc917672c36b980d79fef4673273251f/image.png)
After: 5.28.3 -> Aug. 24, 2020:
![image](/uploads/61a...One of our clients reporting a regression in TaxMath -> this is straight up CiviCRM:
Before: 5.24.x -> Aug. 04, 2020:
![image](/uploads/bc917672c36b980d79fef4673273251f/image.png)
After: 5.28.3 -> Aug. 24, 2020:
![image](/uploads/61a2f438f4622db0f26762a825557d79/image.png)
GST amount is off by $0.30
5% of the total ($131.25) = $6.56 - is there new code attempting to calculate GST amounts backwards and not getting the math right?
Noting that the renewal form itself -> has the correct GST amount:
![image](/uploads/2dd7262bea7c079c285648421c69bd9f/image.png)
Just reproduced on dmaster.demo.civicrm.org
Renewal -> should be $125 + $6.25 (GST) = $131.25 (but note Tax Amount is $6.56)
![image](/uploads/b3ac217c19d7a90bf62991541b3130c1/image.png)https://lab.civicrm.org/dev/core/-/issues/1971Option value cache key missing domain ID can result in wrong value retrieved ...2020-08-26T19:27:09ZJKingsnorthOption value cache key missing domain ID can result in wrong value retrieved for domainI cannot provide steps to recreate the issue on dmaster because it's related to a multi-domain setup.
Our step to recreate was to:
- Log in on domain ID 1, send a test email, the 'from' address was 'test@domain1.com'
- Log in on domain ...I cannot provide steps to recreate the issue on dmaster because it's related to a multi-domain setup.
Our step to recreate was to:
- Log in on domain ID 1, send a test email, the 'from' address was 'test@domain1.com'
- Log in on domain ID 2, send a test email, the 'from' address was **still** 'test@domain1.com' (expecting @domain2.com)
In a multi-domain setup, the wrong option value for domain-sensitive option values can be returned. eg: `\CRM_Core_BAO_Domain::getNameAndEmail` returns the name and email of a different domain to the current one.
The problem stems from:
`\CRM_Core_OptionGroup::values`
The value names 'from_email_address' and 'grant_type' can be different depending on the domain ID they are looked up from.
However, the cacheKey does not include the domain ID, so the value for one domain could be cached, and returned when the query is for another domain:
`$cacheKey = self::createCacheKey($name, $flip, $grouping, $localize, $condition, $labelColumnName, $onlyActive, $keyColumnName, $orderBy);`
The domain ID is calculated lower down in the function, and is not passed in as a param.
I think this can be resolved by adding the domainID to the cache key - but only for domain-sensitive values (so as not to reduce performance for values that are shared across multiple domains).
---
I also noticed a mis-match between the current cacheKey (see above), and the one that is generated from flushValues: `$cacheKey = self::createCacheKey($name, $flip, $grouping, $localize, $condition, $labelColumnName, $onlyActive, $keyColumnName);` - the one in flushValues is missing the 'orderBy'. Is this a different problem?5.30.0https://lab.civicrm.org/dev/core/-/issues/1970API4 "where" doesn't fully work for checkbox/multi-select options2020-09-01T15:13:32ZnoahAPI4 "where" doesn't fully work for checkbox/multi-select optionsOverview
----------------------------------------
If I want to search for records which contain a particular option value (or values) in a multi-value custom field, there's currently no clean way to do that using APIv4's "get" action.
T...Overview
----------------------------------------
If I want to search for records which contain a particular option value (or values) in a multi-value custom field, there's currently no clean way to do that using APIv4's "get" action.
This limitation of API4's "where" clauses may also apply to "update" and "delete" actions, but I only investigated "get".
Reproduction steps
----------------------------------------
1. Create an option group with a couple options. Use that option group in creating a custom checkbox or multiple-select field on Contacts.
2. Create a contact who has two options selected in that custom field.
3. Try to use API v4 to "get" that contact, using one or both of the option values in that custom field in the "where" parameter.
You can [run through these reproduction steps using this code](https://lab.civicrm.org/dev/core/-/snippets/53).
Current behaviour
----------------------------------------
Records containing specific value options cannot be found successfully, except perhaps by hackily using "LIKE" with wildcards and Civi's VALUE_SEPARATOR character. In some cases when there is only a single value in the multi-value field, and you specify that option in the "where" parameter, the API will return the record, but looking at the generated SQL I think this is a fluke of collation or something.
Expected behaviour
----------------------------------------
When you use the "=" operator and a single option value in the "where" parameter, the API should return records that have exactly (and only) that one option selected.
Beyond that, we need to decide how it should work. I should be able to search for records where options A and C are selected, but not B. There might need to be a pair of custom operators, "contains" and "doesn't contain", for this purpose. These would translate into SQL LIKE or RLIKE comparisons using the VALUE_SEPARATOR. Note that there are currently some issues with RLIKE in Advanced Search as I note in #1967.https://lab.civicrm.org/dev/core/-/issues/1969e-notice when saving a contact from the left hand drupal block2023-04-17T05:03:19Zeileene-notice when saving a contact from the left hand drupal blockAdding a contact like this
![Screen_Shot_2020-08-22_at_1.16.08_PM](/uploads/f774d7a77e9d41c6f94841b12d387cf7/Screen_Shot_2020-08-22_at_1.16.08_PM.png)
results in
![Screen_Shot_2020-08-22_at_1.15.33_PM](/uploads/facd00f26f3fcc25ef741fe5...Adding a contact like this
![Screen_Shot_2020-08-22_at_1.16.08_PM](/uploads/f774d7a77e9d41c6f94841b12d387cf7/Screen_Shot_2020-08-22_at_1.16.08_PM.png)
results in
![Screen_Shot_2020-08-22_at_1.15.33_PM](/uploads/facd00f26f3fcc25ef741fe5463497ee/Screen_Shot_2020-08-22_at_1.15.33_PM.png)
The code lines are
https://github.com/civicrm/civicrm-core/blob/9d30c8d11e0ffe73dc38527346ecc4dfecc844cb/CRM/Contact/Form/Contact.php#L872-L880
And I was going to fix it but my brain started hurting when I looked that code (reproducibly) so I decided to log it in the hope someone else does.
I DID confirm that $group is not used again. I haven't confirm how 'flexible' the downstream fn is about what ithttps://lab.civicrm.org/dev/core/-/issues/1968Can't display System Status page - Guzzle error2024-03-22T05:03:28Zaydunsaidan.saunders@squiffle.ukCan't display System Status page - Guzzle errorOverview
----------------------------------------
Accessing the System Status page produces the boilerplate but no content.
Reproduction steps
----------------------------------------
1. Go to **Administer > Administration Console > Sy...Overview
----------------------------------------
Accessing the System Status page produces the boilerplate but no content.
Reproduction steps
----------------------------------------
1. Go to **Administer > Administration Console > System Status**
Current behaviour
----------------------------------------
The Drupal log shows:
```
| Location | https://example.org/civicrm/ajax/rest |
| Referrer | https://example.org/civicrm/a/ |
| Message | Error: Call to undefined function GuzzleHttp\Psr7\get_message_body_summary() in GuzzleHttp\Exception\RequestException::getResponseBodySummary() (line 127 of /var/www/sites/all/modules/civicrm/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php). |
```
This is a failure in handling an exception, so unless there is some other failure this function is not called.
It looks to be an internal error in the Guzzle. A quick search, shows reports of the problem in other software using this Guzzle.
- https://github.com/nextcloud/twofactor_gateway/issues/312
- https://wordpress.org/support/topic/internal-server-error-620/
- https://stackoverflow.com/questions/61363997/guzzlehttp-gives-call-to-undefined-function-guzzlehttp-psr7-get-message-body-su
This is only happening on one server. Others are functioning normally.
Commenting out the referenced line lets the status be produced.
Dumping the `$response` object shows a status of 403, but does not contain the URL.
Environment information
----------------------------------------
* __CiviCRM:__ _5.28.2_
* __PHP:__ _7.3_
* __CMS:__ _Drupal 7.30_
* __Web Server:__ _Apache 2.4_https://lab.civicrm.org/dev/core/-/issues/1967Search results may be wrong when option values contain special chars2023-04-18T05:03:18ZnoahSearch results may be wrong when option values contain special charsOverview
----------------------------------------
When
- a custom field has one of the multi-value HTML types (Multi-Select, Checkbox), and
- one of the options for the field has a machine value containing "+" or another character that h...Overview
----------------------------------------
When
- a custom field has one of the multi-value HTML types (Multi-Select, Checkbox), and
- one of the options for the field has a machine value containing "+" or another character that has special meaning in MySQL regular expressions,
using Advanced Search to search for that option may return incorrect results.
Reproduction steps
----------------------------------------
1. Create a multi-value custom field and an option group where some of the options' values contain regex special characters. For example:
```javascript
CRM.api3('OptionGroup', 'create', {
"name": "how_i_excel",
"title": "How I Excel",
"data_type": "String",
"is_active": 1,
"api.OptionValue.create": [{
"value": "fun drunk",
"label": "I'm Great at Beer Pong"
}, {
"value": "a+ student",
"label": "I Get Good Grades"
}, {
"value": "red[ish] hair",
"label": "I Have Beautiful Auburn Locks"
}]
}).then(function(result) {
console.log(result);
CRM.api3('CustomGroup', 'create', {
"title": "Stuff About Me",
"extends": "Contact",
"api.CustomField.create": {
"label": "Why I'm Awesome",
"data_type": "String",
"html_type": "CheckBox",
"option_group_id": "how_i_excel",
"is_searchable": 1,
"is_active": 1
}
}).then(function(result) {
console.log(result)
}, function(error) {
console.log(error)
});
}, function(error) {
console.log(error)
});
```
2. Create or edit some contacts with the different option values you set up in the previous step.
3. Use Advanced Search to search for the different option values.
Current behaviour
----------------------------------------
Searching for the option whose machine value is "a+ student" or "red[ish] hair" returns zero results, or the wrong results.
Expected behaviour
----------------------------------------
Searching for an option should return exactly the set of records whose custom value contains that option, regardless of what characters are used to store the option value.
Environment information
----------------------------------------
* __CiviCRM:__ Master, but this issue may go back to 4.6.6 or thereabouts
* __Database:__ MariaDB 10.4 (equivalent to MySQL 5.7)
Comments
----------------------------------------
The relevant bit of code is in [CRM_Core_BAO_CustomQuery->where()](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/CustomQuery.php#L311).
We have at least a couple options:
- Prohibit option values from containing regex special characters (plus sign +, asterisk \*, square brackets [], curly braces {}, pipe \| dot/period ., etc. Parentheses are already handled.) This seems infeasible to me, since option values can be created through the UI but may also be created through the API or other means. Also it doesn't handle option values that may have already been created.
- Escape the special characters during search. Although there is [no specific function](https://stackoverflow.com/questions/4024188/php-function-to-escape-mysql-regexp-syntax) in PHP or our codebase for escaping MySQL regular expressions, it would not be too much trouble to create.
Question: what would be an appropriate test for this?