CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-01-11T13:56:44Zhttps://lab.civicrm.org/dev/core/-/issues/4060On 5.57.0 Joomla3, cv fails with 'Failed to start application'2023-01-11T13:56:44Zaydunsaidan.saunders@squiffle.ukOn 5.57.0 Joomla3, cv fails with 'Failed to start application'Overview
----------------------------------------
On a 5.57.0 Joomla 3.10.9 system, the `cv` command fails with 'Failed to start application'
(Logging against core rather than cv since the problem appears to be here)
Reproduction steps...Overview
----------------------------------------
On a 5.57.0 Joomla 3.10.9 system, the `cv` command fails with 'Failed to start application'
(Logging against core rather than cv since the problem appears to be here)
Reproduction steps
----------------------------------------
1. Try running various commands such as `cv vars:show`, `cv api Contact.get`
Current behaviour
----------------------------------------
```
In Factory.php line 137:
Failed to start application
vars:show [--out OUT] [--flat [FLAT]] [--level LEVEL] [--hostname HOSTNAME] [-t|--test] [-U|--user USER]
```
Expected behaviour
----------------------------------------
No error!
Environment information
----------------------------------------
* __CiviCRM:__ _5.57.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.3__
* __CMS:__ _Joomla 3.10.9._5.57.1aydunsaidan.saunders@squiffle.ukaydunsaidan.saunders@squiffle.ukhttps://lab.civicrm.org/dev/core/-/issues/4056Replace hard-coded call to legacyCustomSearch framework with a hook2023-06-25T18:31:24ZeileenReplace hard-coded call to legacyCustomSearch framework with a hookWe should get the legacy custom search frame work out of our `GroupContactCache` BAO and eventually out of core code (and unhide the extension, with a view to not shipping enabled).
In order to do this I think we need a hook to get the ...We should get the legacy custom search frame work out of our `GroupContactCache` BAO and eventually out of core code (and unhide the extension, with a view to not shipping enabled).
In order to do this I think we need a hook to get the sql when loading a contact group
![image](/uploads/9ca4de13d7127a957e988ccea1a5c43b/image.png)
It might potentially wind up like this
![image](/uploads/6eebfb49b84cb35210c17de5a7eaf5e2/image.png)
I see there is handling for the sql being empty - which seems weird - but we could probably assume that if anything ever needs no sql it is not a custom search
Note that `CRM_Contact_BAO_SearchCustom` could be moved to the extension with the hook once as part of this as nothing else calls it
The other place where the legacy custom search framework returns sql is
![image](/uploads/e99dfdf4ba2fb66ac6e78c9f1cffc3b6/image.png)
Internally the first query calls the same `contactIDs`
![image](/uploads/88c6ff1481188c0f666b6309cb01b25b/image.png)
@colemanw @seamuslee @DaveDhttps://lab.civicrm.org/dev/core/-/issues/4055Extension cannot found its own classes during install when opcache is enabled2023-03-16T13:12:50ZkainukExtension cannot found its own classes during install when opcache is enabledI start with the following configuration:
* PHP 8.1.7 _Using the docker image FROM php:8.1.7-apache-buster_
* OPCache enabled _standard configuration_
* Buildkit _CiviCRM install for Drupal 9_ see below:
````
civibuild create patch \
...I start with the following configuration:
* PHP 8.1.7 _Using the docker image FROM php:8.1.7-apache-buster_
* OPCache enabled _standard configuration_
* Buildkit _CiviCRM install for Drupal 9_ see below:
````
civibuild create patch \
--type drupal9-demo \
--civi-ver master \
--url http://patch.kainuk \
--cms-ver 9.5
````
Now, when I enable the Action Provider extension (just from the extension screen), the following error is thrown.
````
Error: Class "Civi\ActionProvider\Symfony\Component\DependencyInjection\DefinitionAdapter" not found in action_provider_civicrm_container() (line 15 of /buildkit/build/patch/web/sites/default/files/civicrm/ext/action-provider/action_provider.php)
````
`cv flush` lets the problem disappear, and for the Action Provider that is no problem because only code is installed (it does not change the database). However, other extensions can have more problems because the installation is interrupted, and possible incomplete.
The problem is, however, reproducible. When I disable the extension, and uninstall it, the error reappears after installing.
I did some duty time in the debugger and found the following code in the extension class loader (CRM_Extension_ClassLoader)
````php
$file = $this->getCacheFile();
if (file_exists($file)) {
$this->loader = require $file;
}
else {
$this->loader = $this->buildClassLoader();
$ser = serialize($this->loader);
file_put_contents($file,
sprintf("<?php\nreturn unserialize(%s);", var_export($ser, 1))
);
}
````
`$this->buildClassLoader()` is an expensive procedure, so after calculation the result is saved for reuse. When a new extension is installed, the saved file is removed because it does not contain the new extension configuration. A new classloader with all the extension stuff is calculated and an updated file is written.
For loading the class, the PHP construct `require` is used. This construct was designed for loading PHP code. The assumption is that PHP code does not change much, and OPCache used this assumption, to store the file in memory. The risk is here is that not the newly written configuration is used, but an old one from memory. On my configuration, I observed with the PHP debugger, that when the `hook_civicrm_container` the old classloader is loaded with require. Just put a breakpoint before the `$this->loader = require $file` line.
When the OPCache is disabled, the problem does not appear.5.59.0https://lab.civicrm.org/dev/core/-/issues/4052Problem with custom group fields when cache get returns NULL from 'CRM_Core_D...2024-03-18T23:41:32ZLeanderJCCProblem with custom group fields when cache get returns NULL from 'CRM_Core_DAO_CustomGroup_QueryMultipleFields *' cache keyOverview
----------------------------------------
We had a problem where we did an APIv3 call on participants where it would cause an error resulting in a 500 response.
Some stack tracing showed us that in CRM/Core/BAO/CustomGroup.php t...Overview
----------------------------------------
We had a problem where we did an APIv3 call on participants where it would cause an error resulting in a 500 response.
Some stack tracing showed us that in CRM/Core/BAO/CustomGroup.php the code `$multipleFieldGroups = $cache->get($multipleFieldGroupCacheKey);` returned NULL (line 576). Since there is no check that says that it should not be NULL the code continues and errors on `if (in_array($table, $multipleFieldGroups) &&` because
> Argument #2 ($haystack) must be of type array, null given in in_array().
Reproduction steps
----------------------------------------
Could not specifically reproduce this with a clean install.
Current behaviour
----------------------------------------
Our page where the APIv3 Participant call was made would return a 500.
```
TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in in_array() (line 611 of /var/www/html/vendor/civicrm/civicrm-core/CRM/Core/BAO/CustomGroup.php)
#0 /var/www/html/vendor/civicrm/civicrm-core/CRM/Core/BAO/CustomGroup.php(611): in_array('civicrm_value_r...', NULL)
#1 /var/www/html/vendor/civicrm/civicrm-core/api/v3/utils.php(1449): CRM_Core_BAO_CustomGroup::getTree('Participant', Array, 1982, NULL, Array, NULL, true, NULL, true, false)
#2 /var/www/html/vendor/civicrm/civicrm-core/api/v3/Participant.php(154): _civicrm_api3_custom_data_get(Array, NULL, 'Participant', '1982', NULL)
#3 /var/www/html/vendor/civicrm/civicrm-core/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_participant_get(Array)
#4 /var/www/html/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke(Array)
#5 /var/www/html/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest(Array)
#6 /var/www/html/vendor/civicrm/civicrm-core/api/api.php(133): Civi\API\Kernel->runSafe('Participant', 'get', Array)
```
Expected behaviour
----------------------------------------
The page should load as normal.
Environment information
----------------------------------------
* __CiviCRM:__ _5.55.1_
* __PHP:__ _8.0.24_
* __CMS:__ _Drupal 9.4.8_
* __Database:__ _8.0.26_
* __Web Server:__ _nginx/1.20.2_
Comments
----------------------------------------
We fixed this issue by switching to APIv4 so it would no longer automatically get the custom groups and fields for the participant, but this still seemed a general issue to report.
I believe an if, at line 578 after settings the variable, would fix this issue.
```
if ($multipleFieldGroups === NULL) {
$multipleFieldGroups = [];
}
```https://lab.civicrm.org/dev/core/-/issues/4038Import contribution fails in update mode even if contribution id is provided.2023-11-08T01:41:46ZKurund JalmiImport contribution fails in update mode even if contribution id is provided.Here is the error:
![Screenshot_from_2022-12-18_14-06-52](/uploads/f55f363f6c213e0280815a7d69321e44/Screenshot_from_2022-12-18_14-06-52.png)Here is the error:
![Screenshot_from_2022-12-18_14-06-52](/uploads/f55f363f6c213e0280815a7d69321e44/Screenshot_from_2022-12-18_14-06-52.png)Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/4031Searchkit: Download spreadsheet should use standard date format, not the form...2023-05-29T01:37:04ZlarsssandergreenSearchkit: Download spreadsheet should use standard date format, not the format set in Date FormatsIf you're downloading a CSV or other spreadsheet from Searchkit results or a SK Table, you'll get dates formatted per the Date Display format setting, which by default is `August 9th, 2012 1:17 PM`. That's a format that takes some wrang...If you're downloading a CSV or other spreadsheet from Searchkit results or a SK Table, you'll get dates formatted per the Date Display format setting, which by default is `August 9th, 2012 1:17 PM`. That's a format that takes some wrangling to get Excel or other spreadsheet programs to recognize as a date.
Instead, the date should be exported as it is using export from non-SK results, in standard format `2012-08-09 13:17`.
[Related issue](https://lab.civicrm.org/dev/core/-/issues/3730) on data types in ods or xlsx files.
Tested on dmaster (5.58).https://lab.civicrm.org/dev/core/-/issues/4028CMS Database Integration - Per-table prefixes are no longer supported2023-02-06T22:26:31ZolivierCMS Database Integration - Per-table prefixes are no longer supportedOverview
----------------------------------------
Since Drupal 8.2 per-table prefixes are no longer supported, so System Settings / CMS Database Integration menu should no longer display the 'Drypal 7' mapping table
Example use-case
---...Overview
----------------------------------------
Since Drupal 8.2 per-table prefixes are no longer supported, so System Settings / CMS Database Integration menu should no longer display the 'Drypal 7' mapping table
Example use-case
----------------------------------------
1. Click on **System Settings -> CMS Database Integration**.
Current behaviour
----------------------------------------
$databases['default']['default']['prefix']= [
'default' => 'drupal_',
'civicrm_acl' => '',
'civicrm_acl_cache' => '',
'civicrm_acl_contact_cache' => '',
'civicrm_acl_entity_role' => '',
'civicrm_action_log' => '',
'civicrm_action_mapping' => '',
'civicrm_action_schedule' => '',
'civicrm_activity' => '',
'civicrm_activity_contact' => '',
....
Proposed behaviour
----------------------------------------
$databases['civicrm']['default'] = [
'database' => 'xxxxxx',
'username' => 'xxxxxx',
'password' => 'set your db password',
'host' => '127.0.0.1',
'port' => '',
'driver' => 'mysql',
'prefix' => '',
'namespace' => 'Drupal\Core\Database\Driver\mysql',
'collation' => 'utf8mb4_general_ci',
];
Comments
----------------------------------------
_Anything else you would like the reviewer to note._5.60.0https://lab.civicrm.org/dev/core/-/issues/4026Custom field value not saved first time after membership type changed2024-03-15T01:10:51ZdanmurrayCustom field value not saved first time after membership type changedOverview
----------------------------------------
Membership type B has a custom field set but Membership type A does not. When a membership of type A is edited and changed to type B, the custom field set appears in the editor and value...Overview
----------------------------------------
Membership type B has a custom field set but Membership type A does not. When a membership of type A is edited and changed to type B, the custom field set appears in the editor and values can be set for the custom fields. However when the membership is saved, the custom field values are not remembered. The values are only remembered if the membership is edited a second time, and the custom fields are set and saved again.
Reproduction steps
----------------------------------------
Go to https://dmaster.demo.civicrm.org/
Add new custom field set used for Memberships -> General
Add new field to field set: a dropdown field with option 1 and option 2
Find any membership of type Student and edit it
Change membership type from Student to General, the new custom field appears for editing
![image](/uploads/2eae0c3199111e0605609f82408c7961/image.png)
Select option 1 in the custom field and save the membership
![image](/uploads/6863ef5c318c458537b090be791cfde6/image.png)
View the membership - the custom field value is not set
![image](/uploads/ddb4b7fc4f85ca0b9c1ceeaee751e449/image.png)
Edit the membership again, again select option 1 in the custom field and save the membership
View the membership again - the custom field value is now set
![image](/uploads/61578005173f4af4c10fb784446e4cd2/image.png)
Current behaviour
----------------------------------------
The first time a custom field value is set after a membership type is changed, the value is not remembered. It is only remembered after the second time it is saved.
Expected behaviour
----------------------------------------
The custom field value should be remembered the first time it is saved.
Environment information
----------------------------------------
Reproduced on https://dmaster.demo.civicrm.org/ 9th Dec 2022
Comments
----------------------------------------5.72.0https://lab.civicrm.org/dev/core/-/issues/4022PHP 7.4, 8+ TypeError: array_flip(): Argument #1 ($array) must be of type arr...2023-01-05T02:18:09ZeldonthianPHP 7.4, 8+ TypeError: array_flip(): Argument #1 ($array) must be of type array, string givenOverview
----------------------------------------
Fresh install seemed to work, after going through checklist and setting up preferences,
somehow the search preferences page now throws this error. not sure what the exact cause is.
http...Overview
----------------------------------------
Fresh install seemed to work, after going through checklist and setting up preferences,
somehow the search preferences page now throws this error. not sure what the exact cause is.
https://civicrm.stackexchange.com/q/43060/14046
Reproduction steps
----------------------------------------
This seems to come up whenever ANY of the options are changed and attempting to save on search preferences page. i.e., custom fields, search options or quick search fields selection/deselection, reorder, etc.
Current behaviour
----------------------------------------
upon saving any changes on the search preferences page.
go back to the page, all ordering gone, default fields only, and selections.. just click save, and things begin to work as first install. Can not select/deselect any field to be saved. new selections are not saved..
```
TypeError: array_flip(): Argument #1 ($array) must be of type array, string given in /code/vendor/civicrm/civicrm-core/CRM/Admin/Form/SettingTrait.php on line 380 #0 /code/vendor/civicrm/civicrm-core/CRM/Admin/Form/SettingTrait.php(380): array_flip('\x01sort_name\x01cont...')
#1 /code/vendor/civicrm/civicrm-core/CRM/Admin/Form/SettingTrait.php(224): CRM_Admin_Form_Setting::reorderSortableOptions('quicksearch_opt...', Array)
#2 /code/vendor/civicrm/civicrm-core/CRM/Admin/Form/Setting.php(66): CRM_Admin_Form_Setting->addFieldsDefinedInSettingsMetadata()
#3 /code/vendor/civicrm/civicrm-core/CRM/Admin/Form/Setting/Search.php(47): CRM_Admin_Form_Setting->buildQuickForm()
#4 /code/vendor/civicrm/civicrm-core/CRM/Core/Form.php(689): CRM_Admin_Form_Setting_Search->buildQuickForm()
#5 /code/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Display.php(76): CRM_Core_Form->buildForm()
#6 /code/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Display->perform(Object(CRM_Admin_Form_Setting_Search), 'display')
#7 /code/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Admin_Form_Setting_Search), 'display')
#8 /code/vendor/civicrm/civicrm-core/CRM/Core/Controller.php(355): HTML_QuickForm_Page->handle('display')
#9 /code/vendor/civicrm/civicrm-core/CRM/Utils/Wrapper.php(98): CRM_Core_Controller->run()
#10 /code/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(292): CRM_Utils_Wrapper->run('CRM_Admin_Form_...', 'Search Preferen...', Array)
#11 /code/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem(Array)
#12 /code/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke(Array)
#13 /code/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke(Array)
#14 /code/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(80): Drupal\civicrm\Civicrm->invoke(Array)
#15 [internal function]: Drupal\civicrm\Controller\CivicrmController->main(Array, '')
#16 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#17 /code/web/core/lib/Drupal/Core/Render/Renderer.php(564): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#18 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#19 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#20 /code/vendor/symfony/http-kernel/HttpKernel.php(169): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#21 /code/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#22 /code/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /code/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /code/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /code/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /code/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /code/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /code/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /code/web/core/lib/Drupal/Core/DrupalKernel.php(709): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /code/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#31 {main}
```
Expected behaviour
----------------------------------------
Search preferences should be able to be saved with changes.. and accessible at
civicrm/admin/setting/search?reset=1
Environment information
----------------------------------------
* __CiviCRM: 5.55.2, 5.56
* __PHP: 7.4, 8.0, 8.1
* __CMS: Drupal 9.4.8
* __Database: MariaDB 10.4.25
* __Web Server: nginx/1.21.65.57.0https://lab.civicrm.org/dev/core/-/issues/4012Contribution Page credit card expiry months are incorrectly offset when the t...2022-12-17T23:11:48ZbgmContribution Page credit card expiry months are incorrectly offset when the timezone is WhitehorseFound an interesting bug that only happens with users who have chose the America/Whitehorse timezone (-0700). It does not happen if we chose another similar timezone (America/Vancouver, America/Yellowknife, etc).
To reproduce on dmaster...Found an interesting bug that only happens with users who have chose the America/Whitehorse timezone (-0700). It does not happen if we chose another similar timezone (America/Vancouver, America/Yellowknife, etc).
To reproduce on dmaster / drupal7:
- login as the demo user
- change the user's timezone to America/Whitehorse
Then go to a contribution page:
https://dmaster.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=2
![image](/uploads/ea61f948003f258501391a3c90e2a6e3/image.png)5.58.0https://lab.civicrm.org/dev/core/-/issues/3994Auto renew options for membership types are not saving for a contribution page2023-12-07T00:06:08ZKurund JalmiAuto renew options for membership types are not saving for a contribution pageSteps to replicate on vanilla CiviCRM install
- Membership type configuration
![Screenshot_from_2022-11-18_10-51-50](/uploads/02d45ded17660376a461d6738c287c48/Screenshot_from_2022-11-18_10-51-50.png)
- In the contribution page configur...Steps to replicate on vanilla CiviCRM install
- Membership type configuration
![Screenshot_from_2022-11-18_10-51-50](/uploads/02d45ded17660376a461d6738c287c48/Screenshot_from_2022-11-18_10-51-50.png)
- In the contribution page configuration try to make option 'Required' and save.
![Screenshot_from_2022-11-18_10-52-30](/uploads/9f50922426022defea7b99c53a386def/Screenshot_from_2022-11-18_10-52-30.png)
- However, it not saved
![Screenshot_from_2022-11-18_10-52-41](/uploads/57717f65ddd9e0df971821cafade9752/Screenshot_from_2022-11-18_10-52-41.png)5.69.0Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3986FormBuilder: defaults for bulk create2023-05-24T14:05:46Zaydunsaidan.saunders@squiffle.ukFormBuilder: defaults for bulk createOverview
----------------------------------------
Provide a 'defaults' entity for bulk entry
Example use-case
----------------------------------------
1. Create a submission form for Activities
2. On the main Activity1 fieldset, mark it...Overview
----------------------------------------
Provide a 'defaults' entity for bulk entry
Example use-case
----------------------------------------
1. Create a submission form for Activities
2. On the main Activity1 fieldset, mark it as 'Repeat'
3. You can now create a set of activities
4. But ...
Current behaviour
----------------------------------------
All relevant fields need to be completed even if they are repetitive
Proposed behaviour
----------------------------------------
Provide a 'defaults' version of the fieldset where repeated values can be entered.
The normal entries are then combined with the default values before creating the entities.
Note this is different to the 'Values' feature: those are specified by the form designer (eg specifying an activity type)
The defaults are provided by the user filling in the form such as specifying a 'key contact' that is used when creating all the other entities, unless that value is specified.
```
Default entry: Field 1: Field 2: abc
Entry 1: Field 1: Hi 1 Field 2:
Entry 2: Field 1: Hi 2 Field 2:
Entry 3: Field 1: Hi 3 Field 2: def
Entry 4: Field 1: Hi 4 Field 2:
Entry 5: Field 1: Hi 5 Field 2: ghi
```
should create:
```
Entry 1: Field 1: Hi 1 Field 2: abc
Entry 2: Field 1: Hi 2 Field 2: abc
Entry 3: Field 1: Hi 3 Field 2: def
Entry 4: Field 1: Hi 4 Field 2: abc
Entry 5: Field 1: Hi 5 Field 2: ghi
```
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/3982SearchKit: dropdowns for country and state don't work2022-11-16T20:07:08Zaydunsaidan.saunders@squiffle.ukSearchKit: dropdowns for country and state don't workOverview
----------------------------------------
In SearchKit, the dropdowns for 'Address (primary) Country', 'Address (billing) Country', 'Address (primary) State/Province', 'Address (billing) State/Province' don't work.
Reproduction ...Overview
----------------------------------------
In SearchKit, the dropdowns for 'Address (primary) Country', 'Address (billing) Country', 'Address (primary) State/Province', 'Address (billing) State/Province' don't work.
Reproduction steps
----------------------------------------
1. Create a new SearchKit search
2. Search for Contacts
3. Add 'Where': 'Address (primary) Country' '='
Current behaviour
----------------------------------------
The Country list dropdown just spins and does not complete.
![image](/uploads/756beb13ac0db4147fb703d2dc37692b/image.png)
Expected behaviour
----------------------------------------
List of countries
Environment information
----------------------------------------
* __CiviCRM:__ _Master_colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3980SearchKit displays: be able to add description so end user knows the context2022-11-21T19:39:52ZherbdoolSearchKit displays: be able to add description so end user knows the contextCurrently on SearchKit displays we can set the name which ends up being used for the title and the URL. I've tried to add additional information there for end users so they understand the context of the results. E.g. "Only shows results ...Currently on SearchKit displays we can set the name which ends up being used for the title and the URL. I've tried to add additional information there for end users so they understand the context of the results. E.g. "Only shows results for the current campaign". But that's awkward to stuff that all into the title. And also means one has to be careful that on the first save *not* to add those notes to the name so as to prevent an ungainly URL.
(The other option is to embed the SK into an afform, but that's a lot of extra work for just a bit of description.)
So a separate description field would be ideal.https://lab.civicrm.org/dev/core/-/issues/3977Payment processor handling of `billing-country-5` inconsistent2022-11-11T02:07:08ZeileenPayment processor handling of `billing-country-5` inconsistentThis is a follow on from https://lab.civicrm.org/dev/core/-/issues/3918 / https://github.com/civicrm/civicrm-core/pull/24232 / https://github.com/civicrm/civicrm-core/pull/24903
The original PR https://github.com/civicrm/civicrm-core/pu...This is a follow on from https://lab.civicrm.org/dev/core/-/issues/3918 / https://github.com/civicrm/civicrm-core/pull/24232 / https://github.com/civicrm/civicrm-core/pull/24903
The original PR https://github.com/civicrm/civicrm-core/pull/24903 did not explain what problem was being solved & it didn't come out in the review process.... so I think in the first instance we should establish that.
This is my best guess to reverse engineer the point of the original change ...
All calls to `doPayment` are expected to pass through the documented parameters https://docs.civicrm.org/dev/en/latest/extensions/payment-processors/create/#billing-fields - in this case the relevant parameter is `billing_country-5`. That parameter is a bit of a pig so some/ most code ALSO passes `country` - and this seems to be done consistently enough that `Paypal` and `Authorize.net` (our oldest processors) are using `country`.
I do think it is important that when payment processors are sending out an array the contract of what keys they should pass out is clear. If we want to deprecate `billing_country-5` in favour of 'country' that seems OK (we would need to update the docs) - but at the moment there seems to be some code that passes `country` in a format that is not correct - which led to the regression.
I feel like in the first instance we should find & fix (with tests) the reported instances of that that came up in https://lab.civicrm.org/dev/core/-/issues/3918
Looking at the code for `setBillingCountry` and the validation - I have a feeling that code may only be hit from the unit tests? In which case the case for reducing the validation seems strong enough.
One thing we COULD do in the test suite is register a hook on all unit tests for `alterPaymentProcessor` & validate the `country` field in it - that might track down any errant ones
I should note that `PropertyBag` isn't a subsitute for us fixing core code to pass the contract parameters5.56.0https://lab.civicrm.org/dev/core/-/issues/3965Adding mailing events (unsub, open, clicks, etc) to API42023-10-16T00:28:23ZlarsssandergreenAdding mailing events (unsub, open, clicks, etc) to API4I'd like to add mailing events to API4 so we can use them in SearchKit, to improve the A/B Mailing report page, and so on.
This would be all the [Mailing Events here.](https://github.com/civicrm/civicrm-core/tree/master/CRM/Mailing/Even...I'd like to add mailing events to API4 so we can use them in SearchKit, to improve the A/B Mailing report page, and so on.
This would be all the [Mailing Events here.](https://github.com/civicrm/civicrm-core/tree/master/CRM/Mailing/Event/DAO) Not sure they are all essential, but might as well do them all at once, as they will all be very similar.
Having poked around at this, I see a few issues that I think I need some help with before starting on this.
We have, for example, TrackableURLOpen, which links to a TrackableURL and also to the Queue entity, which links to the Job entity, which links to the Mailing entity. I don't think we want to have users building queries with joins on all of these entities in SearchKit in order to get useful information back. Ideally, we'd have an entity that has a get action that would return:
- id from TrackableURLOpen
- timestamp from TrackableURLOpen
- URL from TrackableURL
- contact id from Queue
- mailing id from Job
Can we do this by adding all these entities to the API, adding entity bridges to connect them all and then adding an abstract entity that wraps everything up together, with a get function that gets all the fields above from the API (and a getfields function as well). Or is there a less manual way to do this?
Also, I see that the Queue entity already exists in API4, but it isn't the Mailing_Event_Queue entity. Is there a way to specify the full class for an entity so that we don't get a collision? It looks like it just expects the last word from the classname as the API class and that won't work in this case. This might be helpful in general here, because adding an entity called just Opened is going to be confusing (versus naming it something like MailingEventOpened).https://lab.civicrm.org/dev/core/-/issues/3963Mix of auto renewing membership types and non-auto renewing membership types ...2024-03-15T21:08:28ZEdselopezMix of auto renewing membership types and non-auto renewing membership types not handled properly in pricesets.Overview
----------------------------------------
On a membership price set, it is possible to specify a mix of auto renewing memberships as well as non auto renewing memberships, but allow the selection of only one at a time (by virtue ...Overview
----------------------------------------
On a membership price set, it is possible to specify a mix of auto renewing memberships as well as non auto renewing memberships, but allow the selection of only one at a time (by virtue of it being a radio select). It seems CiviCRM doesn't know how to handle this properly, as it assumes that multiple options can be selected.
The code here https://github.com/civicrm/civicrm-core/blob/master/CRM/Price/BAO/PriceSet.php#L1290 seems to fetch the HTML type (which should be the deciding factor on if the payment processor is compatible with handling multiple concurrent transactions) but doesn't really do anything with it.
Reproduction steps
----------------------------------------
1. Create a membership price set
2. Add a price field of type radio
3. Proceed to create selections having membership types selected, but be sure to include a mix of auto renewing membership types and non-auto renewing membership types
4. Add the price field on a contribution page and click save.
Current behaviour
----------------------------------------
(I have tested this for PayPal - Website Payments Standard, but it should be replicable for any payment processor which doesn't support "MultipleConcurrentPayments".
Error shown when trying to save
"Price Set
The membership price set associated with this online contribution allows a user to select BOTH an auto-renew AND a non-auto-renew membership. This requires submitting multiple processor transactions, and is not supported for one or more of the payment processors enabled under the Amounts tab."
Expected behaviour
----------------------------------------
The contribution form should recognize that the price field is a single select field, and therefore allow me to save the configuration.
Environment information
----------------------------------------
* __Browser:__ _Firefox 59.0.1/Chrome 78.0.3904/Safari 13_
* __CiviCRM:__ _Master/5.20.0/5.19.1/5.18.2/..._ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.0/7.1/7.2/7.3/...__
* __CMS:__ _Backdrop 1.5/Drupal 7.30/Joomla 3.3/WordPress 4.5/..._
* __Database:__ _MySQL 5.7.7/MariaDB 10.4/..._
* __Web Server:__ _Apache 2.4/Nginx 1.16/..._5.69.5seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/3962Bool token formatting2022-11-18T14:27:07ZeileenBool token formattingI hit an issue today where we were using tokens in smarty. We already have this format in several message templates - e.g
`{if '{contact.current_employer}'} ({contact.current_employer}){/if}`
The single quotes are necessary as `{if } ...I hit an issue today where we were using tokens in smarty. We already have this format in several message templates - e.g
`{if '{contact.current_employer}'} ({contact.current_employer}){/if}`
The single quotes are necessary as `{if } {/if} ` will fail - so it renders to `{if ''} {/if} `
However, the problem we hit is if the employer is `O'Malley Construction'` which renders as `{if 'O'Malley Construction'} {/if} `
I think the solution is to add a bool modifier & allow any token to be passed through it - it would also simplify the smarty a little - ie
`{if {contact.current_employer|bool}} ({contact.current_employer}){/if}`5.57.0https://lab.civicrm.org/dev/core/-/issues/3944SearchKit: Show count on both top and bottom of display2022-10-27T20:47:07ZlarsssandergreenSearchKit: Show count on both top and bottom of displayCurrently, the count of results in a SearchKit display is only shown on the bottom of the page. In core, totals are usually shown at the top and bottom of the page in search results. I think it would be more usable to also show the total...Currently, the count of results in a SearchKit display is only shown on the bottom of the page. In core, totals are usually shown at the top and bottom of the page in search results. I think it would be more usable to also show the total count in SearchKit displays at the top of the page, beside the Actions drop down menu. It's a good sanity check for users to be able to see how many entities they are doing an action on before doing so - they shouldn't have to scroll to the bottom of the page and then back up to see the count. It's also not always easy to see how many are selected or if you've selected just one page of results or the whole list.
Something simple like this, which would also show NNN selected of NNN results when some are selected.
![image](/uploads/0587e86d7faed05a9ecf441a64f93378/image.png)
This could be disabled by disabling show count for the display.https://lab.civicrm.org/dev/core/-/issues/3937Importing "No" values to Boolean field results in empty2023-04-03T02:21:49ZelilisseckImporting "No" values to Boolean field results in emptyOverview
----------------------------------------
Contact imports to custom "Yes or No" fields work with values 1 or 0. "Yes" also appears to work.
If you import a "No" value, however, the field will be blank for that contact instead o...Overview
----------------------------------------
Contact imports to custom "Yes or No" fields work with values 1 or 0. "Yes" also appears to work.
If you import a "No" value, however, the field will be blank for that contact instead of having the "No"/0 label/value.
Technical details
----------------------------------------
["strtoboolstr"](https://github.com/civicrm/civicrm-core/blob/4ce53ba3de860a5d9aac1b1bbd22b7a29e839af2/CRM/Utils/String.php#L424) gets run twice on this data. [Once on the raw value returning a boolean](https://github.com/civicrm/civicrm-core/blob/902fc38d0d6cd9d09ee02f30cc6621747151a06a/CRM/Import/Parser.php#L1602) and [once later in the code here](https://github.com/civicrm/civicrm-core/blob/902fc38d0d6cd9d09ee02f30cc6621747151a06a/CRM/Contact/Import/Parser/Contact.php#L328)
When you run this on a boolean value (you shouldn't, according to the comments, but perhaps we should check for this), "Yes"/true will _look_ like it's working okay because the preg_match will match for (bool)true but it won't match for (bool)false. I'm sure this has something to do with a PHP oddity I know nothing about but related to the fact that `strlen((bool)true)` is `1` and `strlen((bool)false)` is `0`.
Proposed solution is:
1) Don't run strtoboolstr twice. We don't need that second iteration of it because it's already been run on the data. I'm not sure of any other impacts for this so also:
2) Write a test for importing to a Yes/No field with the 6 values that should work (1,0,yes,no,true,false). I've started writing this test following examples but i'm having trouble getting my import data actually in properly to run the assertEquals on. I will open a WIP PR with this test.
Any other thoughts welcome!
Reproduction steps
----------------------------------------
1. Create a custom field with data type "Yes or No"
2. Create a csv to import first,last,custom_fieldID with data for your custom field "Yes" and "No"
3. Run the import normally through the GUI in the Contacts > Import Contacts workflow
4. Observe custom field results on the imported contacts
Expected behaviour
----------------------------------------
According to code comments, this type of field import should accept "1", "0", "Yes", "No", "true", "false" and they should all fill a "Yes or No" field correctly.
Environment information
----------------------------------------
This was reproduced on the master branch in d9 (5.56.alpha1)5.61.0