CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-01-10T12:26:09Zhttps://lab.civicrm.org/dev/core/-/issues/4065Upgrade Error 5.56.1 to 5.57.0 duplicate Search Kit UI_name2023-01-10T12:26:09ZkcristianoUpgrade Error 5.56.1 to 5.57.0 duplicate Search Kit UI_nameEnviornment:
WP 6.1.1
php 7.4
apache 2.4
Search Kit has a search created in 2021 called 'Top Donors'
on upgrade I get the error:
`[nativecode=1062 ** Duplicate entry 'Top_Donors' for key 'UI_name']`
```
[Error: Finish core DB update...Enviornment:
WP 6.1.1
php 7.4
apache 2.4
Search Kit has a search created in 2021 called 'Top Donors'
on upgrade I get the error:
`[nativecode=1062 ** Duplicate entry 'Top_Donors' for key 'UI_name']`
```
[Error: Finish core DB updates 5.57.0]
Error Field Error Value
Type DB_Error
Code -5
Message DB Error: already exists
Mode 16
UserInfo INSERT INTO `civicrm_saved_search` (`name` , `label` , `form_values` , `mapping_id` , `search_custom_id` , `api_entity` , `api_params` , `created_id` , `modified_id` , `expires_date` , `description` ) VALUES ('Top_Donors' , 'Top Donors' , NULL , NULL , NULL , 'Contribution' , '{\"version\":4,\"select\":[\"GROUP_CONCAT(DISTINCT Contribution_Contact_contact_id_01.display_name) AS GROUP_CONCAT_Contribution_Contact_contact_id_01_display_name\",\"SUM(total_amount) AS SUM_total_amount\",\"COUNT(id) AS COUNT_id\",\"AVG(total_amount) AS AVG_total_amount\"],\"orderBy\":[],\"where\":[[\"contribution_status_id:name\",\"=\",\"Completed\"]],\"groupBy\":[\"contact_id.display_name\"],\"join\":[[\"Contact AS Contribution_Contact_contact_id_01\",\"LEFT\",[\"contact_id\",\"=\",\"Contribution_Contact_contact_id_01.id\"]]],\"having\":[]}' , 202 , 202 , NULL , NULL ) [nativecode=1062 ** Duplicate entry 'Top_Donors' for key 'UI_name']
DebugInfo INSERT INTO `civicrm_saved_search` (`name` , `label` , `form_values` , `mapping_id` , `search_custom_id` , `api_entity` , `api_params` , `created_id` , `modified_id` , `expires_date` , `description` ) VALUES ('Top_Donors' , 'Top Donors' , NULL , NULL , NULL , 'Contribution' , '{\"version\":4,\"select\":[\"GROUP_CONCAT(DISTINCT Contribution_Contact_contact_id_01.display_name) AS GROUP_CONCAT_Contribution_Contact_contact_id_01_display_name\",\"SUM(total_amount) AS SUM_total_amount\",\"COUNT(id) AS COUNT_id\",\"AVG(total_amount) AS AVG_total_amount\"],\"orderBy\":[],\"where\":[[\"contribution_status_id:name\",\"=\",\"Completed\"]],\"groupBy\":[\"contact_id.display_name\"],\"join\":[[\"Contact AS Contribution_Contact_contact_id_01\",\"LEFT\",[\"contact_id\",\"=\",\"Contribution_Contact_contact_id_01.id\"]]],\"having\":[]}' , 202 , 202 , NULL , NULL ) [nativecode=1062 ** Duplicate entry 'Top_Donors' for key 'UI_name']
PEAR_Exception: DB Error: already exists in /home/wpmaybe/public_html/wp-content/plugins/civicrm/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php on line 945
DB_Error: DB Error: already exists in unknown on line unknown
```
I edited the label and name in DB and re-ran the upgrade:
Success
I also now have a packaged Search with the same label and name as one that was created previously. Perhaps we should have a more unique name (not label) to indicated it's a core/packaged search?
EDIT: The affected sites all have the extension 'SearchKit Reports' enabled.https://lab.civicrm.org/dev/core/-/issues/4064Off-line Contribution receipts are sent to on hold emails2023-04-22T16:38:36ZlarsssandergreenOff-line Contribution receipts are sent to on hold emailsIf you record an off-line contribution for a contact with an email on hold, the option to send them a receipt at their on-hold email address is shown (with no indication that the email is on hold).
I would think the expected behaviour w...If you record an off-line contribution for a contact with an email on hold, the option to send them a receipt at their on-hold email address is shown (with no indication that the email is on hold).
I would think the expected behaviour would be to not show the receipt option if the contributor's email is on hold.https://lab.civicrm.org/dev/core/-/issues/4062Emojis submitted to CiviCRM API cause issues2023-10-22T12:20:26ZfkohrtEmojis submitted to CiviCRM API cause issues## Problem/Motivation
Emojis that are submitted to custom fields cause an issue upon webform submission.
## Detailed steps to reproduce
1. Set up a simple webform event registration form, e.g. first name, last name, and a custom atten...## Problem/Motivation
Emojis that are submitted to custom fields cause an issue upon webform submission.
## Detailed steps to reproduce
1. Set up a simple webform event registration form, e.g. first name, last name, and a custom attendee-specific custom field (multi-line text box / textarea).
2. Put 👍🏻 into the custom field
3. Error message: The website encountered an unexpected error. Please try again later.
Alongside every form submission with emojis, the log contains two related entries:
__webform_submission__
```
CRM_Core_Exception: DB Error: unknown error in civicrm_api3() (line 135 of /var/www/[SITE]/vendor/civicrm/civicrm-core/api/api.php).
```
__php__
```
Drupal\Core\Entity\EntityStorageException: DB Error: unknown error in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 815 of /var/www/[SITE]/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
```
## Proposed resolution
Successful submission of text that contains emojis.
## Further context
Moved from `webform_civicrm` issue [3331605](https://www.drupal.org/project/webform_civicrm/issues/3331605).https://lab.civicrm.org/dev/core/-/issues/4061Send letter in bulk to pledgers2023-01-10T09:34:22ZyashodhaSend letter in bulk to pledgersFunctional specifications:
- We are replicating the existing feature for contributions “Thank you letters - print or email” for the pledges.
- In menu Pledges, Find Pledges, make the Pledge statuses Pending, In progress and Overdue sele...Functional specifications:
- We are replicating the existing feature for contributions “Thank you letters - print or email” for the pledges.
- In menu Pledges, Find Pledges, make the Pledge statuses Pending, In progress and Overdue selected by default
- In menu Actions, add “Pledge Letters - print or email”
- When we select “Pledge Letters - print or email”, we land on a screen (replicate of the one for contributions)
- Replace Thank-you Letter for Contributions (PDF) by Pledge Letter
- Replace Update thank-you dates for these contributions by Update pledge letter dates for these pledges
- Remove Update receipt dates for these contributions
- Replace MAKE THANK-YOU LETTERS by MAKE PLEDGE LETTERS
The following tokens need to be available in the drop down Tokens so they can be included in a message template and resolved when included in the letter:
- Total pledge amount
- Total pledge payments
- Pledge balance
- Upcoming pledge payment amount
- Upcoming pledge payment due datehttps://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/4059CiviEvent: API3/4 deletes event is_template flag on event update2023-01-16T15:22:16ZBjörn EndresCiviEvent: API3/4 deletes event is_template flag on event updateOverview
----------------------------------------
The CiviCRM API resets(!) the ``is_template`` flag on an event entity when manipulating unrelated attributes. Tested on APIv3 and APIv4.
Reproduction steps
------------------------------...Overview
----------------------------------------
The CiviCRM API resets(!) the ``is_template`` flag on an event entity when manipulating unrelated attributes. Tested on APIv3 and APIv4.
Reproduction steps
----------------------------------------
1. Create a new event template (not a message template)
1. Go to the API explorer (3 or 4)
1. Run ``Event.get`` with the ID of the given template. Observe that the ``is_template`` parameter is set to 1/true.
1. Run ``Event.create/update`` with parameters:
* ``id`` = ID of the given template
* ``title`` = "just want to trigger a change"
1. Run ``Event.get`` with the ID of the given template.
Current behaviour
----------------------------------------
Observe that the ``is_template`` parameter is set to 0/false - **the flag has been deleted!**
Expected behaviour
----------------------------------------
API call should leave the ``is_template`` parameter alone, i.e. the return value of then ``is_template`` parameter should be 1/true
Environment information
----------------------------------------
Tested on current [DMASTER](https://dmaster.demo.civicrm.org) running 5.59.alpha1, but has definitely been around for longer.
Comments
----------------------------------------
A unit test to cover that should be pretty straightforward with these instructions.5.59.0https://lab.civicrm.org/dev/core/-/issues/4058Search Tasks limited by certain ACLs when they should not be2023-01-10T09:35:37ZRichSearch Tasks limited by certain ACLs when they should not beSometimes an incomplete list of search tasks are shown to a user whose access is ACL limited.
I think this problem is caused by this line:
https://lab.civicrm.org/dev/core/-/blob/5.56/CRM/ACL/BAO/ACL.php#L503
I think the loop `break`s...Sometimes an incomplete list of search tasks are shown to a user whose access is ACL limited.
I think this problem is caused by this line:
https://lab.civicrm.org/dev/core/-/blob/5.56/CRM/ACL/BAO/ACL.php#L503
I think the loop `break`s when it shouldn't. I think what's intended is to simply shift that `break` up within the `if {}` that ends on the line above it.
I think the intention of the code is:
- loop through the DAO results that lists permissions
- if the object_id is empty (typically, zero) then the permission applies to all "objects of that type" by which I think it means groups.
- there's an allowance that this record might be for a different permission type (e.g. View instead of Edit) which we would want to ignore
- if the type does match, then all groups are permissioned and we merge those onto our `$ids` array
However where it fails is if there are, say, 2 rows returned. The first says View all, the 2nd says Edit all, and we're asking about edit permission. Because of the `break` where it is, once the first row is looked at and discarded, we break and don't loko at the 2nd row!
Shifting the `break` up seems to fix this and seems to me to be probably what was intended.
Because this bug is highly sensitive to a load of stuff, it's likely that this shows up in weird situations and could be hard to reproduce.
If this makes sense to anyone I'll submit a PR.
In case it's helpful, my proposal is
```diff
diff --git a/sites/all/modules/civicrm/CRM/ACL/BAO/ACL.php b/sites/all/modules/civicrm/CRM/ACL/BAO/ACL.php
index 58b388b73..3d036a3a3 100644
--- a/CRM/ACL/BAO/ACL.php
+++ b/CRM/ACL/BAO/ACL.php
@@ -499,8 +499,8 @@ ORDER BY a.object_id
foreach ($allGroups as $id => $dontCare) {
$ids[] = $id;
}
+ break;
}
- break;
}
}
return $ids;
```https://lab.civicrm.org/dev/core/-/issues/4057Cannot remove contact from group from Groups tab UI within ACL environment2023-01-10T09:36:07ZRichCannot remove contact from group from Groups tab UI within ACL environmentHave a staff user, *Pebbles*, in an ACL, with access to a contact, *Wilma*.
When Pebbles views the Groups tab of Wilma's record, they are able to add Wilma to a group via the UI, but should they click **remove** or **delete** next to a ...Have a staff user, *Pebbles*, in an ACL, with access to a contact, *Wilma*.
When Pebbles views the Groups tab of Wilma's record, they are able to add Wilma to a group via the UI, but should they click **remove** or **delete** next to a group, an error shows:
> API permission check failed for GroupContact/delete call; insufficient permission: require access CiviCRM and edit all contacts
I don't think this is a security/permissions thing.
Pebbles is able to remove Wilma from the group by simply clicking Edit to get to the hideous edit-flippin-everything form, and then removing the group from the select2 element in the Groups accordion.
## Suggested fix (v1)
I think it's useful for ACL-ed staffers to be able to use groups; it's such a core feature of Civi. And it's fairly weird that they can add a contact to a group, but not remove one - or not by the main UI.
I implemented this as follows in a custom extension, but I'm sure there's a better way to do it upstream.
```
/**
* @see https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_alterAPIPermissions/
*/
function myextension_civicrm_alterAPIPermissions($entity, $action, &$params, &$permissions) {
if ($entity === 'group_contact' && $action == 'delete' && !empty($params['id'])) {
$gc = \Civi\Api4\GroupContact::get(FALSE)
->addWhere('id', '=', $params['id'])
->addSelect('contact_id', 'group_id.group_type:name')
->execute()->single();
$mayEditContact = \Civi\Api4\Contact::checkAccess()
->setAction('update')
->addValue('id', $gc['contact_id'])
->execute()->first()['access'] ?? FALSE;
$groupIsNotAcl = !in_array('Access Control', $gc['group_id.group_type:name'] ?? []);
if ($mayEditContact && $groupIsNotAcl) {
// Reduce the access permissions for this call.
$permissions['group_contact']['delete'] = 'access CiviCRM';
}
}
}
```https://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/4054Redis cache of Extensions persists between builds2023-01-05T21:57:54ZeileenRedis cache of Extensions persists between buildsI'm hitting an issue where if I run civibuild to rebuild a site shortly after enabling afform it fails - the reason is the Redis cache is used to retrieve enabled extensions, including afform so the afform alterMenu hook is called when i...I'm hitting an issue where if I run civibuild to rebuild a site shortly after enabling afform it fails - the reason is the Redis cache is used to retrieve enabled extensions, including afform so the afform alterMenu hook is called when installing CiviCRM - but the extension is not yet installed & hence the function fatals as it fails to find the Afform class it calls
When determining which hook is called we see
```
/**
* @param $moduleList
*/
public function requireCiviModules(&$moduleList) {
$civiModules = CRM_Core_PseudoConstant::getModuleExtensions();
```
This winds up at
![image](/uploads/e0a82bcf50371e56217b8a0d5c048e2a/image.png)
And it gets the previous build's module list here
![image](/uploads/69f06caeb86421b3923c41e152028f23/image.png)
The cache name is a bit convoluted - but it should be flushed on install to avoid this between-install leakage.
I'm not quite sure where though ... @tottenhttps://lab.civicrm.org/dev/core/-/issues/4053Standalone: users and roles2023-08-11T16:23:42ZbgmStandalone: users and rolesGeneral issue to discuss user management, roles and permissions.
There was a discussion in Manchester about this. At first we explored the idea of using CiviCRM groups to manage permissions, but there was a lot of discomfort because of ...General issue to discuss user management, roles and permissions.
There was a discussion in Manchester about this. At first we explored the idea of using CiviCRM groups to manage permissions, but there was a lot of discomfort because of the (lack of) security around groups and how it could end up adding a lot of extra complexity. Of course, maybe an implement or another might prove one way or another.
So far one [WIP branch](https://github.com/civicrm/civicrm-core/compare/master...demeritcowboy:civicrm-core:user-storage?expand=1) by @DaveD proposes creating `civicrm_user` with an ID, username, password and maybe email. While testing, I managed to get it working by also adding a record in the `civicrm_uf_match` table (for authx http logins), to link that user to a contact.
Presumably we would also have `civicrm_user_role` (ex: admin, staff, member) and `civicrm_user_permission` (ex: "admin" has the "Administer CiviCRM" permission).
And then we would have the same permission grid similar to what CiviCRM has for WordPress role management (in that case, it adds WordPress capabilities, but in this case, it would add records in `civicrm_user_permission`).
cc @DaveD @artfulrobot @JoeMurray
Related meta: #2998https://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/4051ApiV4 - add options2022-12-27T20:14:54ZeileenApiV4 - add options@totten has added something to `cv` where you can add an option to an existing field - I think this feature makes sense, but as a an apiv4 feature (rather than a cv feature) and across multiple entities rather than just Settings. There a...@totten has added something to `cv` where you can add an option to an existing field - I think this feature makes sense, but as a an apiv4 feature (rather than a cv feature) and across multiple entities rather than just Settings. There are different ways it could look but in essence you are looking to be able to offer stuff like
```
Setting::update()->addWhere('name', '=', 'enable_components')->addOption(['CiviCampaign'])->execute();
Setting::update()->addWhere('name', '=', 'enable_components')->removeOption(['CiviCampaign'])->execute();
Contact::update()->addWhere('id', '=', 123)->addOption(['contact_sub_type' => 'Student'])->execute();
Contact::update()->addWhere('id', '=', 123)->removeOption(['contact_sub_type' => 'Student'])->execute();
```
I'm not sure the exact syntax or whether it should be on the `update` action - one for @colemanw
- This would probably be limited to fields with `is_multiple` or `serialize` or some other indicator of multiple-value-ness (whatever we land on for settings) & be validated against the relevant pseudoconstant or callback-option-listhttps://lab.civicrm.org/dev/core/-/issues/4050Can't Disable Event Notification when Registering Participant Off-line2022-12-28T18:13:11ZsavionleeCan't Disable Event Notification when Registering Participant Off-lineOverview
----------------------------------------
When performing an offline Event Registration, you cannot disable "Send Confirmation and Receipt". The POST handler ```civicrm/contact/view/participant``` sends out emails irrespective of...Overview
----------------------------------------
When performing an offline Event Registration, you cannot disable "Send Confirmation and Receipt". The POST handler ```civicrm/contact/view/participant``` sends out emails irrespective of the disabled checkbox on the UI and the disabled default event page configuration.
https://chat.civicrm.org/civicrm/pl/4uy3mp5c3jbtjdx96fif6nk4ie
_If you have already posted on https://civicrm.stackexchange.com or https://chat.civicrm.org, please include the link to that conversation._
Reproduction steps
----------------------------------------
1. Open a Contact
1. Click on **Actions-> Register for Event**.
1. After any Event, Disable **☑️ Send Confirmation and Receipt** and **Save**.
1. Got a success of **"Event registration for Test Email has been added. A confirmation email has been sent to"**.
(No email should have been sent)
Current behaviour
----------------------------------------
_What happens currently. Please provide error messages, screenshots or gifs ([LICEcap](http://www.cockos.com/licecap/), [SilentCast](https://github.com/colinkeenan/silentcast)) where appropriate._
Currently Sends this payload with a disabled send notification and disabled Payment box
```
entryURL:
https://example.website/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fcontact%2Fview%2Fparticipant&page=CiviCRM&reset=1&action=add&cid=497&context=participant
_qf_default:
Participant:upload
MAX_FILE_SIZE: 83886080
_qf_Participant_upload: 1
contact_id: 497
event_id: 15
campaign_id: 8
role_id[]: 1
register_date: 2022-12-27 13:23:00
status_id: 1
source:
hidden_feeblock: 1
hidden_eventFullMsg:
priceSetId: 10
price_16:
price_13:
price_11:
financial_type_id: 4
total_amount: 0
receive_date: 2022-12-27 13:23:00
trxn_id:
contribution_status_id: 1
payment_instrument_id: 4
check_number:
from_email_address: 185
receipt_text:
note:
hidden_custom: 1
hidden_custom_group_count[]: 1
custom_21_-1:
custom_18_-1: 0
custom_19_-1: 0
custom_20_-1: 0
custom_22_-1:
hidden_custom: 1
hidden_custom_group_count[]: 1
hidden_custom: 1
hidden_custom_group_count[]: 1
hidden_custom: 1
hidden_custom_group_count[]: 1
```
I injected a null value into the options to select from the drop down which changed the parameter of ```from_email_address: 185``` to ```from_email_address: ``` Unfortunately, that is not how the post handler determines if to send a message because i got this error:
![image](/uploads/ddd977f63def220652a4e628a64e6702/image.png) So it still tried to send with the unset email address.
Expected behaviour
----------------------------------------
_What should happen._
No email is sent.
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. -->
* __Browser:__ _Edge 108.0.1462.54 _
* __CiviCRM:__ _5.56.0, 5.55.3_
* __PHP:__ _7.4?_
* __CMS:__ _Wordpress 6.1.1_
* __Database:__ _Maria DB_
* __Web Server:__ _Apache 2_
Comments
----------------------------------------
I'm not skilled in reading how php handles calls and everything, so i can't find the handler that this post query relates to. Any pointers would help!https://lab.civicrm.org/dev/core/-/issues/4048Fatal error when changing membership type, on membership with 0 contributions2024-01-12T17:29:15ZBradley TaylorFatal error when changing membership type, on membership with 0 contributions## Steps to reproduce
1. Create a membership without a contribution.
2. Edit the membership you just created, change the membership type, and save (again without a contribution)
## Expected result
The membership should correctly save ...## Steps to reproduce
1. Create a membership without a contribution.
2. Edit the membership you just created, change the membership type, and save (again without a contribution)
## Expected result
The membership should correctly save both times.
## Expected result
The second save does not save correctly/ causes a 500 server error.
The error message is:
```
Fatal error: Uncaught Error: max(): Argument #1 ($value) must contain at least one element
in /app/web/app/plugins/civicrm/civicrm/CRM/Member/Form/Membership.php on line 1547
Call stack:
1. max()
app/plugins/civicrm/civicrm/CRM/Member/Form/Membership.php:1547
2. CRM_Member_Form_Membership::setStatusMessage()
app/plugins/civicrm/civicrm/CRM/Member/Form/Membership.php:1380
3. CRM_Member_Form_Membership::submit()
app/plugins/civicrm/civicrm/CRM/Member/Form/Membership.php:881
4. CRM_Member_Form_Membership::postProcess()
app/plugins/civicrm/civicrm/CRM/Core/Form.php:573
...
```
The membership does appear to actually be saved correctly upon refreshing the page.
## Environment information
PHP 8.1
I cannot reproduce this on dmaster. I think this is because calling `max(array_keys([]))` on PHP 7.4 merely causes a warning, whereas on PHP 8.x it causes an `Uncaught ValueError`.https://lab.civicrm.org/dev/core/-/issues/4047htmlspecialchars() issue on PHP8 and CiviReport2023-01-04T07:44:17ZJonGoldhtmlspecialchars() issue on PHP8 and CiviReport**Note** I've been seeing this `htmlspecialchars()` error on this line frequently on PHP 8. This is just the one instance I investigated thoroughly.
When attempting to use a particular CiviReport instance, we get a WSOD with this error...**Note** I've been seeing this `htmlspecialchars()` error on this line frequently on PHP 8. This is just the one instance I investigated thoroughly.
When attempting to use a particular CiviReport instance, we get a WSOD with this error in watchdog:
```
TypeError: htmlspecialchars(): Argument #1 ($string) must be of type string, array given in htmlspecialchars() (line 144 of /var/www/mysite/vendor/civicrm/civicrm-packages/HTML/Common.php)
#0 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/Common.php(144): htmlspecialchars()
#1 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/input.php(154): HTML_Common->_getAttrString()
#2 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/Renderer/Array.php(307): HTML_QuickForm_input->toHtml()
#3 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/Renderer/ArraySmarty.php(189): HTML_QuickForm_Renderer_Array->_elementToArray()
#4 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/Form/Renderer.php(87): HTML_QuickForm_Renderer_ArraySmarty->_elementToArray()
#5 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/Renderer/Array.php(221): CRM_Core_Form_Renderer->_elementToArray()
#6 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/element.php(415): HTML_QuickForm_Renderer_Array->renderElement()
#7 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm.php(1705): HTML_QuickForm_element->accept()
#8 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/Form.php(1136): HTML_QuickForm->accept()
#9 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Display.php(95): CRM_Core_Form->toSmarty()
#10 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Display.php(83): CRM_Core_QuickForm_Action_Display->renderForm()
#11 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Display->perform()
#12 /home/jon/local/mysite/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle()
#13 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/Controller.php(355): HTML_QuickForm_Page->handle()
#14 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Utils/Wrapper.php(98): CRM_Core_Controller->run()
#15 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Report/Page/Instance.php(74): CRM_Utils_Wrapper->run()
#16 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(319): CRM_Report_Page_Instance->run()
#17 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem()
#18 /home/jon/local/mysite/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke()
#19 /home/jon/local/mysite/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke()
#20 /home/jon/local/mysite/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(80): Drupal\civicrm\Civicrm->invoke()
#21 [internal function]: Drupal\civicrm\Controller\CivicrmController->main()
#22 /home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array()
#23 /home/jon/local/mysite/web/core/lib/Drupal/Core/Render/Renderer.php(580): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#24 /home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext()
#25 /home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
#26 /home/jon/local/mysite/vendor/symfony/http-kernel/HttpKernel.php(169): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#27 /home/jon/local/mysite/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#28 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle()
#29 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#30 /home/jon/local/mysite/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#31 /home/jon/local/mysite/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
#32 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle()
#33 /home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#34 /home/jon/local/mysite/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#35 /home/jon/local/mysite/web/core/lib/Drupal/Core/DrupalKernel.php(707): Stack\StackedHttpKernel->handle()
#36 /home/jon/local/mysite/web/index.php(19): Drupal\Core\DrupalKernel->handle()
#37 {main}
```
I tracked it down to my `form_values` which is this:
```
a:27:{s:6:"fields";a:4:{s:9:"sort_name";s:1:"1";s:8:"event_id";s:1:"1";s:9:"status_id";s:1:"1";s:7:"role_id";s:1:"1";}s:12:"sort_name_op";s:3:"has";s:15:"sort_name_value";s:0:"";s:8:"email_op";s:3:"has";s:11:"email_value";s:0:"";s:11:"event_id_op";s:2:"in";s:14:"event_id_value";a:0:{}s:6:"sid_op";s:2:"in";s:9:"sid_value";a:0:{}s:6:"rid_op";s:2:"in";s:9:"rid_value";a:0:{}s:34:"participant_register_date_relative";s:1:"0";s:30:"participant_register_date_from";s:0:"";s:28:"participant_register_date_to";s:0:"";s:6:"eid_op";s:2:"in";s:9:"eid_value";a:0:{}s:11:"custom_4_op";s:2:"in";s:14:"custom_4_value";a:0:{}s:16:"blank_column_end";s:0:"";s:11:"description";s:44:"Provides lists of participants for an event.";s:13:"email_subject";s:0:"";s:8:"email_to";s:0:"";s:8:"email_cc";s:0:"";s:10:"permission";s:16:"access CiviEvent";s:6:"groups";s:0:"";s:7:"options";N;s:9:"domain_id";i:1;}
```
Unserialized:
```
array (
'fields' =>
array (
'sort_name' => '1',
'event_id' => '1',
'status_id' => '1',
'role_id' => '1',
),
'sort_name_op' => 'has',
'sort_name_value' => '',
'email_op' => 'has',
'email_value' => '',
'event_id_op' => 'in',
'event_id_value' => array (),
'sid_op' => 'in',
'sid_value' => array (),
'rid_op' => 'in',
'rid_value' => array (),
'participant_register_date_relative' => '0',
'participant_register_date_from' => '',
'participant_register_date_to' => '',
'eid_op' => 'in',
'eid_value' => array (),
'custom_4_op' => 'in',
'custom_4_value' => array (),
'blank_column_end' => '',
'description' => 'Provides lists of participants for an event.',
'email_subject' => '',
'email_to' => '',
'email_cc' => '',
'permission' => 'access CiviEvent',
'groups' => '',
'options' => NULL,
'domain_id' => 1,
)
```
The issue is `custom_4`, which is save as `in` `array()`. However, this is (and always has been) a free-entry text field, so "IN" should never have been an option. Pre-PHP8, this was ignored, now it's a fatal error.
I see @seamuslee made a [partial fix](https://github.com/civicrm/civicrm-packages/pull/346) but I'll submit a patch to handle the "empty array" case.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4046Civi incompatible with composer 2.5 (serialization of closure is not allowed)2022-12-23T16:28:53ZDaveDCivi incompatible with composer 2.5 (serialization of closure is not allowed)In https://github.com/composer/composer/commit/39de9899a70d8351db134027dc24ed35fc629346#diff-2f0f90552ea46ccb1d7d485298d70262be6825e776fa8e35de15f2f6c4e3efedR114 they added a closure to composer's classloader.
In civi, it creates a cach...In https://github.com/composer/composer/commit/39de9899a70d8351db134027dc24ed35fc629346#diff-2f0f90552ea46ccb1d7d485298d70262be6825e776fa8e35de15f2f6c4e3efedR114 they added a closure to composer's classloader.
In civi, it creates a cache of the extension classloader (which extends composer's) by serializing it: https://github.com/civicrm/civicrm-core/blob/04edd1c101b3d4982c727aae083f7f92c8440928/CRM/Extension/ClassLoader.php#L85
You can't serialize closures, so it gives an error.
Note to reproduce this when using `cv`, you'll need to build cv from source using composer 2.5, since when using cv it uses its own vendor's copy of the composer classloader, not the one in the civi install's vendor folder. So the one in cv might be an older one if using a phar, and then you won't see the error.https://lab.civicrm.org/dev/core/-/issues/4045Ideas for (funded) speed improvements in mailings2023-08-28T14:44:15ZAndrew WestIdeas for (funded) speed improvements in mailingsWe'd be interested in funding some speed improvements when building mailing recipients in CiviMail. They'd inherently feed through to Mosaico, I think.
We find the mailings screens pretty snappy apart from selecting recipients. There a...We'd be interested in funding some speed improvements when building mailing recipients in CiviMail. They'd inherently feed through to Mosaico, I think.
We find the mailings screens pretty snappy apart from selecting recipients. There are few bottlenecks that it'd be nice to get rid of:
**Improve the dropdown**
When you have lots of groups and mailings the dropdown doesn't work very well. It stalls, with multiple spinners appearing, or wipes out your text while typing, or says 'none found' for a bit before updating, or alternates between 'Searching' and 'Loading', and generally takes an achingly long time to find the groups in its own dropdown.
![image](/uploads/91dcd7a0a2c2e7d3230c4016d1d49db0/image.png)
Compare this to the smart group dropdown in Search Kit, which is blindingly fast.
Maybe this could be replaced with the new API4-based entityref? Possibly split into two (or even four?): Groups to include / Groups to Exclude / Mailings to include / Mailings to exclude?
**Improve generating the list of recipients**
A complicated selection of groups can easily take 30 seconds to update and save, for us. This is very frustrating when adding one smart group at a time in the dropdown. Possible fixes:
- Refactor CRM_Mailing_BAO_Mailing::getRecipients(). At the moment this function seems to create a lot of temp tables, and uses a bunch of heavy queries to compare them against each other. Again, Search Kit can do complicated includes/excludes way faster. So I figure this could be modernised.
- Possibly the slow part here is emptying/filling civicrm_mailing_recipients each time the criteria are changed. Maybe add a 'getRecipientCountPreview' function to get a count of recipients without actually populating the table? This would let people experiment in the mailing screen quickly. Then only generate the actual recipient list when the mailing is scheduled or saved as a draft?
Any other ideas? Or thoughts on whether the above makes sense?
We could fund maybe 15hrs on this atm. If anyone wants to join us that'd be great too :-)https://lab.civicrm.org/dev/core/-/issues/4044User authentication via authx is not working for non CMS users using formbuil...2022-12-22T08:14:28ZKurund JalmiUser authentication via authx is not working for non CMS users using formbuilder formsSteps to replicate:
- Create a form and enable tokens
- Send an email with form's complete url token to the non CMS user contact
- Open link in the email in the incognito window
- Form does not set defaults for the contact and saving the...Steps to replicate:
- Create a form and enable tokens
- Send an email with form's complete url token to the non CMS user contact
- Open link in the email in the incognito window
- Form does not set defaults for the contact and saving the form also fails.