Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-06-17T01:12:06Zhttps://lab.civicrm.org/dev/financial/-/issues/197Can no longer update Amount for Recurring Contributions even if it only has o...2022-06-17T01:12:06ZKarinGCan no longer update Amount for Recurring Contributions even if it only has one Lineitem1. Scenario:
A native CiviCRM Contribution page for people to start a Monthly Donation. People can select an amount or enter a custom amount:
![image](/uploads/f804e779d8a59e8c700d71d553ef1d44/image.png)
2. It uses a Priceset:
![imag...1. Scenario:
A native CiviCRM Contribution page for people to start a Monthly Donation. People can select an amount or enter a custom amount:
![image](/uploads/f804e779d8a59e8c700d71d553ef1d44/image.png)
2. It uses a Priceset:
![image](/uploads/5fe1c1c85e7a8ea0046a3752381ac306/image.png)
3. Admin used to be able to update the recurring amount to be transacted here ->
![image](/uploads/8746e3b2aed512d1d467e5c178f1441c/image.png)
4. There is a note at the top that one now needs to edit the Template Contribution ->
![image](/uploads/2c175648b6e4a24839b70220df96135a/image.png)
5. But it can't be edited ->
![image](/uploads/f00911e26a76b1741999c943ed891d8d/image.png)
6. Even though there is only one line item:
![image](/uploads/b88571a041f8473d3885a05994298729/image.png)
7. I've also tested a simpler priceset with only ONE field -> same result - one can not edit the amount
![image](/uploads/a9384f511a03dbb39827cff3526367f6/image.png)
![image](/uploads/ec375efd47b0964c6e8f7894611f7aac/image.png)
![image](/uploads/1e7590cea80ad145580866fd2fc6e6d6/image.png)5.51.0https://lab.civicrm.org/dev/core/-/issues/35045.50.1: Upgrade fails at 5.48: Unknown column 'is_autorun'2022-06-29T02:33:29ZDmitry Smirnov5.50.1: Upgrade fails at 5.48: Unknown column 'is_autorun'I've upgraded code base to 5.50.1 and attempted an upgrade from 5.33.2 which failed on 5.48 as follows:
```
[Error: Convert "is_autorun" to "runner"]
Error Field Error Value
Type DB_Error
Code -19
Message DB Error: no such field
Mode 16...I've upgraded code base to 5.50.1 and attempted an upgrade from 5.33.2 which failed on 5.48 as follows:
```
[Error: Convert "is_autorun" to "runner"]
Error Field Error Value
Type DB_Error
Code -19
Message DB Error: no such field
Mode 16
UserInfo UPDATE civicrm_queue SET runner = "task" WHERE is_autorun = 1 [nativecode=1054 ** Unknown column 'is_autorun' in 'where clause']
DebugInfo UPDATE civicrm_queue SET runner = "task" WHERE is_autorun = 1 [nativecode=1054 ** Unknown column 'is_autorun' in 'where clause']
PEAR_Exception: DB Error: no such field in /usr/share/php/PEAR.php on line 944
- DB_Error: DB Error: no such field in unknown on line unknown
| Exception trace | | |
|-----------------|--------------------------------------------------------------|-----------------------------------------------------------------------|
| # | Function | Location |
| 0 | CRM_Core_Error::exceptionHandler() | /usr/share/php/PEAR.php:944 |
| 1 | PEAR_Error->__construct() | /usr/share/php/DB.php:977 |
| 2 | DB_Error->__construct() | /usr/share/php/PEAR.php:575 |
| 3 | PEAR::_raiseError() | /usr/share/php/PEAR.php:223 |
| 4 | PEAR->__call() | /usr/share/php/DB/common.php:1913 |
| 5 | DB_common->raiseError() | /usr/share/php/DB/mysqli.php:932 |
| 6 | DB_mysqli->mysqliRaiseError() | /usr/share/php/DB/mysqli.php:402 |
| 7 | DB_mysqli->simpleQuery() | /usr/share/php/DB/common.php:1219 |
| 8 | DB_common->query() | /usr/share/civicrm/packages/DB/DataObject.php:2696 |
| 9 | DB_DataObject->_query() | /usr/share/civicrm/packages/DB/DataObject.php:1829 |
| 10 | DB_DataObject->query() | /usr/share/civicrm/CRM/Core/DAO.php:472 |
| 11 | CRM_Core_DAO->query() | /usr/share/civicrm/CRM/Core/DAO.php:1637 |
| 12 | CRM_Core_DAO::executeQuery() | /usr/share/civicrm/CRM/Upgrade/Incremental/php/FiveFortyEight.php:107 |
| 13 | CRM_Upgrade_Incremental_php_FiveFortyEight::convertAutorun() | /usr/share/civicrm/CRM/Queue/Task.php:73 |
| 14 | CRM_Queue_Task->run() | /usr/share/civicrm/CRM/Queue/Runner.php:215 |
| 15 | CRM_Queue_Runner->runNext() | /usr/share/civicrm/CRM/Queue/Page/AJAX.php:36 |
| 16 | CRM_Queue_Page_AJAX::{closure}() | /usr/share/civicrm/CRM/Queue/ErrorPolicy.php:89 |
| 17 | CRM_Queue_ErrorPolicy->call() | /usr/share/civicrm/CRM/Queue/Page/AJAX.php:38 |
| 18 | CRM_Queue_Page_AJAX::runNext() | /usr/share/civicrm/CRM/Core/Invoke.php:285 |
| 19 | CRM_Core_Invoke::runItem() | /usr/share/civicrm/CRM/Core/Invoke.php:69 |
| 20 | CRM_Core_Invoke::_invoke() | /usr/share/civicrm/CRM/Core/Invoke.php:36 |
| 21 | CRM_Core_Invoke::invoke() | /usr/share/wordpress/wp-content/plugins/civicrm/civicrm.php:1211 |
| 22 | CiviCRM_For_WordPress->invoke() | /usr/share/wordpress/wp-includes/class-wp-hook.php:292 |
| 23 | WP_Hook->apply_filters() | /usr/share/wordpress/wp-includes/class-wp-hook.php:316 |
| 24 | WP_Hook->do_action() | /usr/share/wordpress/wp-includes/plugin.php:484 |
| 25 | do_action() | /usr/share/wordpress/wp-admin/admin.php:259 |
| 26 | {main} | |
```https://lab.civicrm.org/dev/core/-/issues/3503Grant export Amount Granted or Amount Requested fields are blank2022-07-05T03:54:39ZStoobGrant export Amount Granted or Amount Requested fields are blankTo reproduce in version 5.50.1:
1. Find Grants
2. click Export
3. select primary fields
4. Error: Amount Granted field is missing. This is a primary grant field
5. Find Grants
6. click Export
7. select your own fields, including Amoun...To reproduce in version 5.50.1:
1. Find Grants
2. click Export
3. select primary fields
4. Error: Amount Granted field is missing. This is a primary grant field
5. Find Grants
6. click Export
7. select your own fields, including Amount Granted and Amount requested
8. Error: Amount Granted and Amount Requested are blank
See attached.
![export-grants](/uploads/a14926db363436c3d4b35be76d3c08ac/export-grants.png)
![csv-export](/uploads/42d0884e8732e61b7082dfa7315916fb/csv-export.png)5.51.0https://lab.civicrm.org/dev/core/-/issues/3502CiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entity_...2022-06-15T00:32:44ZtottenCiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entity_supported_info"Overview
----------------------------------------
The combination of CiviCRM v5.50 + `rules` + `entity` + `civicrm_entity` + `de.systopia.campaign` leads to a fatal exception:
> CiviCRM has not bootstrapped sufficiently to fire event "...Overview
----------------------------------------
The combination of CiviCRM v5.50 + `rules` + `entity` + `civicrm_entity` + `de.systopia.campaign` leads to a fatal exception:
> CiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entity_supported_info"
Reported by @francescbassas on Mattermost https://chat.civicrm.org/civicrm/pl/1izo73dcpjfcbem97eek7s6d6w
Current behaviour
----------------------------------------
Full backtrace: https://gist.github.com/totten/a40ac137f52301b42706e4f7510bc7ad
There is a root exception, which works like so:
1. For whatever normal+circumstantial reason, Civi starts to boot (`civicrm_initialize()`). While booting, it loads extensions (like `de.systopia.campaign`).
2. `campaign.civix.php` has an old-template that raises a warning on php74. (`Array and string offset access syntax with curly braces is deprecated`)
3. Drupal captures the warning, which it sends to the logger.
4. The logger is integrated with `rules`, which is further integrated with `entity`. *Before you can log a warning, it wants to know the list of all entities.*
5. The list of entities includes CiviCRM's entities (core+contrib)... so `civicrm_entity` tries to start Civi again (`civicrm_initialize()`), which incorrectly reports that the system has booted (*it hasn't; we're still-midboot*). It proceeds to ask extensions for their entities (`hook_civicrm_entity_supported_info`).
6. `CiviEventDispatcher` complains (`throw new \RuntimeException`) that we are not ready to run `hook_civicrm_entity_supported_info`.
There is also a secondary exception:
1. The root exception is picked up by Drupal's exception-handler.
2. Drupal exception-handler tries to format a pretty page using the theme. A `theme` is a kind of `entity` (apparently).
3. This fires another request along similar path: `entity` => `civicrm_entity` => `CiviEventDispatcher` => `RuntimeException`
Short term mitigations
----------------------------------------
I suspect any one of the following would address the immediate symptom:
* Fix the syntax warning in `campaign.civix.php`
* Disable `de.systopia.campaign` OR `rules` OR `civicrm_entity`
* Use `php73`
Systemic resolutions
----------------------------------------
A few opinions:
* `rules` makes the logging system too heavy/too complex. One should be able to log a message without triggering a scan of all application-modules.
* When Civi boots and loads the ext mainfiles, it is evidently a mistake to trust the CMS with handling warnings. Something in Civi (eg `CRM_Core_Config::singleton()` or `commonBuildModuleList()`) could install a more conservative logger for the duration of bootstrap.
* `civicrm_initialize()` should probably report something clearer if you call it recursively (ie call it a second time, mid-boot) -- and then `civicrm_entity` can be more guarded (*if the system hasn't booted, then you cannot reliably send hooks to exts*)
* `CiviEventDispatcher`'s interpretation of `not-ready` could be more conservative; eg instead of throwing an exception, drop the hook and write to the PHP `error_log()`.
I do believe it is correct for the system to complain about this scenario. To see why, suppose we add another extension (`advanced_events`) which actually listens to `hook_civicrm_entity_supported_info`. It can nominally go through the motions of firing `hook_civicrm_entity_supported_info`, but we're mid-boot. We haven't loaded all of the files yet (files like `advanced_events.php`). We cannot call `advanced_events_civicrm_entity_supported_info()` yet. The hook does not truly run.
To make matters worse, hooks are often tied up with static-caches. Incomplete data will be cached by `rules`, `entity`, and `CRM_Utils_Hook`. Thus, even though the warning in `campaign.civix.php` seems recoverable, there would be spooky effects later on. Diagnosing that kind of spooky effect can be extremely difficult (given that each piece works independently; and given how the symptoms depend on the happenstance of local environment).5.50.2https://lab.civicrm.org/dev/core/-/issues/3500Wordpress: Merge contacts not working ('CRM_Core_EntityReference' not found)2022-06-08T18:17:51ZWPAWordpress: Merge contacts not working ('CRM_Core_EntityReference' not found)Overview
----------------------------------------
Merge contacts fails with error: Class 'CRM_Core_EntityReference' not found
This happens from all pages where contacts can be merged.
Reproduction steps
-------------------------------...Overview
----------------------------------------
Merge contacts fails with error: Class 'CRM_Core_EntityReference' not found
This happens from all pages where contacts can be merged.
Reproduction steps
----------------------------------------
1. Search contacts
2. Select 2 hits
3. Select Merge contacts
Current behaviour
----------------------------------------
Error: Class 'CRM_Core_EntityReference' not found
Expected behaviour
----------------------------------------
Contact should be merged.
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:__ _Firefox 100+./Chrome 102.0.5005.63_
* __CiviCRM:__ _5.4.72_
* __PHP:__ _7.3_
* __CMS:__ _WordPress 5.9.3_https://lab.civicrm.org/dev/financial/-/issues/195Using the line item editor on a contribution template does not update the mat...2022-07-07T07:51:33ZAlanDixonUsing the line item editor on a contribution template does not update the matching recurring contribution total amountThis is a follow up issue to https://lab.civicrm.org/dev/financial/-/issues/194
as per: https://lab.civicrm.org/dev/financial/-/issues/194#note_75215
It's a similar issue to this one: https://github.com/civicrm/civicrm-core/pull/21473
...This is a follow up issue to https://lab.civicrm.org/dev/financial/-/issues/194
as per: https://lab.civicrm.org/dev/financial/-/issues/194#note_75215
It's a similar issue to this one: https://github.com/civicrm/civicrm-core/pull/21473
Note that if you go back and just save the contribution template, then the issue can be worked around as an administrator!
i.e. part of the problem is that the line item editor is assuming it's living in an isolated world that it knows everything instead of behaving like a responsible citizen.https://lab.civicrm.org/dev/core/-/issues/3499Membership Renewal Message textarea input is absent2022-06-10T14:31:34ZGMCVO DatabasesMembership Renewal Message textarea input is absentOverview
----------------------------------------
The ability to enter a message on membership renewal has been lost
Reproduction steps
----------------------------------------
Find memberships.
Click on the Renew link for a membership ...Overview
----------------------------------------
The ability to enter a message on membership renewal has been lost
Reproduction steps
----------------------------------------
Find memberships.
Click on the Renew link for a membership on the RHS (if present).
You get the Renew Membership popup.
Check the 'Send Confirmation and Receipt?' box.
Should get a textarea called Membership Renewal but you just get the associated help text:
"Enter a message you want included at the beginning of the emailed receipt. EXAMPLE: 'Thanks for supporting our organisation with your membership.'"
Current behaviour
----------------------------------------
Just get the text 'Enter a message you want included at the beginning of the emailed receipt. EXAMPLE: 'Thanks for supporting our organization with your membership.''
The textarea is missing from the html (not just invisible).
Expected behaviour
----------------------------------------
![image](/uploads/d91cb3c23f50862670a5b73ba832745a/image.png)
Environment information
----------------------------------------
Happens on https://dmaster.demo.civicrm.org/
Comments
----------------------------------------
It is working on an old site version CiviCRM 5.46.3 but don't know exactly when it stopped working.5.51.0https://lab.civicrm.org/dev/core/-/issues/3498Import Custom Data - Review of refactorings2022-06-09T21:26:24ZtottenImport Custom Data - Review of refactorings(Off-shoot from https://github.com/civicrm/civicrm-core/pull/23719)
I did some `r-run`, and (broadly) the "Import Custom Data" in `master` appears to work with this update. The examples I used were posted at https://github.com/eileenmcn...(Off-shoot from https://github.com/civicrm/civicrm-core/pull/23719)
I did some `r-run`, and (broadly) the "Import Custom Data" in `master` appears to work with this update. The examples I used were posted at https://github.com/eileenmcnaughton/testdata/pull/2
For a baseline, I compared against 5.49. There were a few quirks and changes.
* (Pre-existing/Unchanged Quirk) The "Start Year" field is defined as "YY" field, but you have to submit a full date. This was true in 5.49 as well.
* (Pre-existing/Unchanged Quirk) "Required" custom-fields are not really required. (That's fair for single-value data attached to another entity - but I'm unsure about multi-value data, where it feels like a separate entity.)
* (Improved) The "Level" field has a more clever/forgiving behavior -- in 5.49, it only matched the option-values numerically (`edu-longdate-full-num.csv`). With this update, matches by number as well as name (`edu-longdate-full-name.csv`). I don't know if that means that are misbehaved edge-cases, but it does generally feel more forgiving.
* (Changed) For invalid "Level" values like [this number](https://github.com/eileenmcnaughton/testdata/pull/2/files#diff-e4e7bafc6e1830e2d67181a2eb2b9e591d91e8ae0abc4dc94abf2804c68cd6d5R6) or [this name](https://github.com/eileenmcnaughton/testdata/pull/2/files#diff-2ede79a5313e574f650035f7ac23d94c7cc20b4847f7fa8ffa8354c4ba982b1bR6), the behavior changed. In 5.49, it completely rejected the record due to the bad value; in 23719, it accepted the record but skipped the value.
* (Regressed) In 5.49, the importer reported the bad "Level" value at the end. In 23719, it inaccurately indicates success.5.51.0eileeneileenhttps://lab.civicrm.org/dev/core/-/issues/3497API4: FALSE incorrectly treated as NULL2023-03-20T16:37:08ZJonGoldAPI4: FALSE incorrectly treated as NULLOverview
----------------------------------------
API4 treats a `FALSE` as a `NULL` during update actions. This breaks the bulk entity update functionality of Search Kit.
Reproduction steps
----------------------------------------
1. C...Overview
----------------------------------------
API4 treats a `FALSE` as a `NULL` during update actions. This breaks the bulk entity update functionality of Search Kit.
Reproduction steps
----------------------------------------
1. Create an Activity custom field of type "Yes/No".
1. In Search Kit, search for activities.
1. Select one or more activities and use the **Update Activities** action to set the custom field's value to `Yes`.
1. Observe that this works correctly.
1. Select the same activities and use the **Update Activities** action to set the custom field's value to `No`.
Current behaviour
----------------------------------------
The activities whose custom field was supposed to be set to `No` are nulled out.
Expected behaviour
----------------------------------------
The custom field's value should be set to `No`.
Comments
----------------------------------------
This is replicable in API4, but not in the Explorer. The issue only occurs when the `addValue()` is passed `FALSE`, but not when `addValue()` is passed `0`. Since API Explorer always uses a `0` when you select `No`, the bug doesn't occur. Nor does it occur with the `cv (short)` syntax, presumably because `cv` is doing some conversion of the value(s). However, you *can* replicate this with the `cv (pipe)` code - e.g.:
This works correctly:
```shell
echo '{"values"{"Availability.Are_you_available_in_the_morning_":0},"where":[["id","IN",[689,688]]]}' | cv api4 Activity.update --in=json
```
This exhibits the bug:
```shell
echo '{"values"{"Availability.Are_you_available_in_the_morning_":false},"where":[["id","IN",[689,688]]]}' | cv api4 Activity.update --in=json
```https://lab.civicrm.org/dev/financial/-/issues/194Unable to edit amount of recurring series2022-06-13T16:42:23ZKarinGUnable to edit amount of recurring seriesWe just noted a regression affecting all latest releases 5.45.x ESR through 5.50.x -> our iATS clients are not able to update amounts for recurring contributions -> Alan @adixon and I confirmed it on two separate sites D9 and D7 and two ...We just noted a regression affecting all latest releases 5.45.x ESR through 5.50.x -> our iATS clients are not able to update amounts for recurring contributions -> Alan @adixon and I confirmed it on two separate sites D9 and D7 and two different methods (credit card and ACH) -> we have clients who have been using CiviCRM for 10y - who have over 10k of these series to manage and they can't bump e.g. this donor from $20 to $25
![image](/uploads/cfc1a9d1a87409946be83be31b8ce860/image.png)
It looks like a form issue -> note the errors:
`Cannot change contribution status from Template to .`
and
`Date Received is a required field`
Marking as regression as in the past admins were able to update recurring series amounts.https://lab.civicrm.org/dev/core/-/issues/3496CiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entityT...2022-06-15T03:08:45ZjrobensCiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entityTypes".Overview
----------------------------------------
Upgrade to 5.50.1 results in
`CiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entityTypes".`
I am using civicrm_entity. Mosaico is the 'non-typical' CiviCRM exten...Overview
----------------------------------------
Upgrade to 5.50.1 results in
`CiviCRM has not bootstrapped sufficiently to fire event "hook_civicrm_entityTypes".`
I am using civicrm_entity. Mosaico is the 'non-typical' CiviCRM extension.
https://civicrm.stackexchange.com/questions/42039/installation-of-v5-50-gives-me-an-immediate-bootstrap-exception/42055#42055
Reproduction steps
----------------------------------------
1. Update CiviCRM
1. Attempt top load any page, run CV or drush
1. CiviCRM is not bootstrapped sufficiently!
Current behaviour
----------------------------------------
There is an initialize error. _civicrm_entity_ is in use. I was able to stop this creating an error by refactoring into using drupal events rather than hooks. This just pushed the problem further into civicrm. The drupal _civicrm_ module then caused an error at the initialize() function and after that block. There are reports in stack overflow of this same symptom occurring in Wordpress.
[initialize-error](/uploads/5b96cc9a779774d4fa6db72e453ea280/initialize-error.png)
Expected behaviour
----------------------------------------
Page should load or CV run.
Environment information
----------------------------------------
* __Browser:__ _Firefox Chrome 100+ /Safari
* __CiviCRM:__ From 5.49.3 to _Master/5.50.0 or 5.50.1 _ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ /7.4/__
* __CMS:__ _Drupal 9.3.15_
* __Database:__ _MariaDB 10.4_
* __Web Server:__ _Apache 2.4/..._
Comments
----------------------------------------
Commenting out _comonModuleBuildList_ in Container.php as added to git on 21/4/2022 enables the page to load.5.50.2https://lab.civicrm.org/dev/core/-/issues/3495Sorting/paging Advanced Search results corrupts search criteria2022-06-16T05:07:08ZBobSSorting/paging Advanced Search results corrupts search criteriaOverview
----------------------------------------
Certain search criteria fields in Advanced Search which have an implied LIKE operator are corrupted upon sorting by clicking on a column or by advancing to a different page in the results...Overview
----------------------------------------
Certain search criteria fields in Advanced Search which have an implied LIKE operator are corrupted upon sorting by clicking on a column or by advancing to a different page in the results.
Two such fields are:
Contribution Source
Case Subject
Others fields, such as Contact Name, do not exhibit this problem.
Reproduction steps
----------------------------------------
1. Login to https://dmaster.demo.civicrm.org
1. Search | Advanced Search
1. Display results as: Contributions
1. Contribution | Contribution Source = "p"
1. Click Search
1. Note 59 results, displayed search criteria includes "Contribution Source Like %p%"
1. Click the City column heading (or any other column heading), or display page 2 of the results.
Current behaviour
----------------------------------------
There are now 108 results, and the displayed search criteria includes "Contribution Source Like %%"
Expected behaviour
----------------------------------------
The search criteria should not be affected by sorting or paging the results.
Environment information
----------------------------------------
* __Browser:__ _Chrome/102.0.5005.63_
* __CiviCRM:__ _5.50.0_
* __PHP:__ _7.4.29_
* __CMS:__ _Drupal 7.88_
* __Database:__ _MariaDB 10.4.13_
* __Web Server:__ _Apache 2.4.43_
Comments
----------------------------------------
Problem traced to /CRM/Core/Form/Search.php:convertTextStringsToUseLikeOperator() calling trim() on $this->_formValues[$fieldName]. That variable, in the affected cases, is an array rather than a string, e.g. ['LIKE' => 'search_value'].5.52.0https://lab.civicrm.org/dev/core/-/issues/3494ACLs fail with syntax error when using nested API4 smart groups2022-08-09T16:01:32ZAndrew WestACLs fail with syntax error when using nested API4 smart groupsOverview
----------------------------------------
Easiest to explain with specifics:
We have users who should only be able to access contacts in Northern Ireland. So we've got an ACL set up for this.
We have a regular group MembersAll,...Overview
----------------------------------------
Easiest to explain with specifics:
We have users who should only be able to access contacts in Northern Ireland. So we've got an ACL set up for this.
We have a regular group MembersAll, and a smart group MembersNorthernIreland. MembersNorthernIreland is an API4 smart group that finds anyone in the group MembersAll who lives in Northern Ireland.
Then we have a 'Northern Ireland' ACL that allows access to the MembersNorthernIreland smart group.
But the MembersNorthernIreland is throwing syntax errors for ACL users, because a long way down the chain the code finds itself not allowed to access details about MembersAll - because it's not a group the ACL'd user is allowed to access.
Essentially the GroupContactCache wants to build the SQL to generate the people in MembersNorthernIreland. It hands this over to API4, which parses the smart group criteria and finds MembersAll. API4 wants to get the ID for MembersAll and ultimately calls FormattingUtil::getPseudoconstantList() - which tries to return a list of _all_ groups via a getfields call [here](https://github.com/civicrm/civicrm-core/blob/99106f72c566265e5437f1654740f9adc7976956/Civi/Api4/Utils/FormattingUtil.php#L268). But at this point the ACL permissions themselves get in the way, and all it gets is a list of the groups the user is allowed to access.
So the function can't find an ID and returns nothing, ultimately resulting in a DB syntax error where the SQL tries to search an empty list:
```
[message] => DB Error: syntax error
[mode] => 16
[debug_info] => SELECT child_group_id, parent_group_id FROM civicrm_group_nesting WHERE parent_group_id IN () [nativecode=1064 ** You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ')' at line 1]
```
Backtrace:
```
[...sql then error handling...]
#11 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php(476): DB_DataObject->query("SELECT child_group_id, parent_group_id FROM civicrm_group_nesting WHERE paren...")
#12 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/GroupNesting.php(201): CRM_Core_DAO->query("SELECT child_group_id, parent_group_id FROM civicrm_group_nesting WHERE paren...")
#13 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/GroupContactCache.php(671): CRM_Contact_BAO_GroupNesting::getDescendentGroupIds((Array:0))
#14 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/Civi/Api4/Service/Spec/Provider/ContactGetSpecProvider.php(75): CRM_Contact_BAO_GroupContactCache::populateTemporaryTableWithContactsInGroups((Array:0), "civicrm_tmp_e_dflt_a6ffaf8a8a00dea3b83483af9d0b4a95")
#15 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/Civi/Api4/Query/Api4SelectQuery.php(554): Civi\Api4\Service\Spec\Provider\ContactGetSpecProvider::getContactGroupSql((Array:32), "`a`.`id`", "IN", (Array:0), Object(Civi\Api4\Query\Api4SelectQuery), 0)
#16 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/Civi/Api4/Query/Api4SelectQuery.php(530): Civi\Api4\Query\Api4SelectQuery->createSQLClause("`a`.`id`", "IN", (Array:0), (Array:32), 0)
#17 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/Civi/Api4/Query/Api4SelectQuery.php(425): Civi\Api4\Query\Api4SelectQuery->composeClause((Array:3), "WHERE", 0)
#18 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/Civi/Api4/Query/Api4SelectQuery.php(298): Civi\Api4\Query\Api4SelectQuery->treeWalkClauses((Array:3), "WHERE")
#19 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/Civi/Api4/Query/Api4SelectQuery.php(150): Civi\Api4\Query\Api4SelectQuery->buildWhereClause()
#20 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/GroupContactCache.php(529): Civi\Api4\Query\Api4SelectQuery->getSql()
#21 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/GroupContactCache.php(808): CRM_Contact_BAO_GroupContactCache::getApiSQL((Array:14), 1177)
#22 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/GroupContactCache.php(654): CRM_Contact_BAO_GroupContactCache::insertGroupContactsIntoTempTable("civicrm_tmp_e_gccache_d3d3e139c670a183ea5d7ceab54118b6", 1177, 4808, NULL)
#23 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/GroupContactCache.php(360): CRM_Contact_BAO_GroupContactCache::buildGroupContactTempTable((Array:1), Object(CRM_Utils_SQL_TempTable))
#24 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/CRM/ACL/BAO/ACL.php(290): CRM_Contact_BAO_GroupContactCache::load(Object(CRM_Core_DAO))
#25 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/CRM/ACL/API.php(117): CRM_ACL_BAO_ACL::whereClause(2, (Array:0), (Array:0), 290135)
#26 /data/vhosts/humanists.uk/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/Contact/Permission.php(187): CRM_ACL_API::whereClause(2, (Array:0), (Array:0), 290135, FALSE, FALSE, TRUE)
#27 /data/vhosts/humanists.uk/wp-content/plugins/civicrm-wp-profile-sync/includes/civicrm/cwps-civicrm-contact.php(1099): CRM_Contact_BAO_Contact_Permission::allow("290135", 2)
#28 /data/vhosts/humanists.uk/wp-content/plugins/civicrm-wp-profile-sync/includes/civicrm/cwps-civicrm-contact.php(1058): CiviCRM_WP_Profile_Sync_CiviCRM_Contact->user_can_view("290135")
#29 /data/vhosts/humanists.uk/wp-includes/class-wp-hook.php(307): CiviCRM_WP_Profile_Sync_CiviCRM_Contact->menu_link_add(Object(WP_Admin_Bar))
#30 /data/vhosts/humanists.uk/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(NULL, (Array:1))
#31 /data/vhosts/humanists.uk/wp-includes/plugin.php(524): WP_Hook->do_action((Array:1))
```
Reproduction steps
----------------------------------------
1. Using search kit, create smart group x based on smart group y
2. Create an ACL that permits users to access smart group x, but not smart group y
3. Login as that user and try to access Civi
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:__ _Firefox 59.0.1/Chrome 78.0.3904/Safari 13_
* __CiviCRM:__ _5.50.1_
* __PHP:__ _7.3_
* __CMS:__ _WordPress 6.0_
Comments
----------------------------------------
I've worked around it by removing the nested group. But I'm not sure of the best approach to fix it in the code.https://lab.civicrm.org/dev/core/-/issues/3492CiviGrant Date Fields no longer respect relative dates in Advanced Search2022-07-05T03:54:13ZelilisseckCiviGrant Date Fields no longer respect relative dates in Advanced SearchSteps to reproduce:
1) Install new buildkit site on master branch (I used wordpress demo)
2) Enabled the CiviGrant extension packed with Core
3) Navigate to Advanced Search and expand the "Grants" tab
4) Pick a date field such as "Grant...Steps to reproduce:
1) Install new buildkit site on master branch (I used wordpress demo)
2) Enabled the CiviGrant extension packed with Core
3) Navigate to Advanced Search and expand the "Grants" tab
4) Pick a date field such as "Grant Money transfer date" and choose a relative date such as "This Calendar Year"
5) Click "Search" and observe no "Where" clauses have been applied to the results
6) Choose a date range from "Jan 1" to *whatever today is* and observe the search works this way, but not with the relative date
Details:
I have a feeling this has something to do with the grant component being packing into an extension, but i'm not quite sure how yet. Any ideas quite welcome! I could put some dev time into fixing if nobody has an idea yet.
What I have observed is that the advanced search FORM itself is outputting the correct formValues array when compared to a contribution field with a relative date that DOES work, i.e.
`["grant_money_transfer_date_relative"]=> string(9) "this.year" ["grant_money_transfer_date_low"]=> string(0) "" ["grant_money_transfer_date_high"]=> string(0) ""`
vs
`["receive_date_relative"]=> string(9) "this.year" ["receive_date_low"]=> string(0) "" ["receive_date_high"]=> string(0) "" `
(a contribution receive date field with relative date)
The same array also reaches /ext/civigrant/CRM/Grant/BAO/Query.php and i'm not quite sure where it goes after that but something about that processing is not getting "grant_money_transfer_date_relative" translated into a "where" query in SQL.5.51.0https://lab.civicrm.org/dev/core/-/issues/3491Multiple log files on multilanguage environments2022-06-25T11:49:50ZjensschuppeMultiple log files on multilanguage environmentsMulti-language environments with path prefixes for each language cause multiple CiviCRM log files in `ConfigAndLog`.
As the log file name contains a hash that includes the `userFrameworkBaseURL`, each language creates a separate log fil...Multi-language environments with path prefixes for each language cause multiple CiviCRM log files in `ConfigAndLog`.
As the log file name contains a hash that includes the `userFrameworkBaseURL`, each language creates a separate log file, see https://github.com/civicrm/civicrm-core/blob/5.48.1/CRM/Core/Error.php#L637-L657.
Since those log files are about the same environment, there should be only one active log file.5.52.0https://lab.civicrm.org/dev/core/-/issues/3489Increase field size for mailing bounce type2024-01-29T10:07:13ZKurund JalmiIncrease field size for mailing bounce typeThe database fields in civicrm_mailing_bounce_type are too restrictive. The name field is limited to 24 characters and the description is limited to 255 characters. This isn’t long enough for the name and description provided by some ema...The database fields in civicrm_mailing_bounce_type are too restrictive. The name field is limited to 24 characters and the description is limited to 255 characters. This isn’t long enough for the name and description provided by some email service providers - e.g. AWS SES.
I propose that the name field should be increased to 256 characters (`VARCHAR(256)`) and the description field should be increased to 2048 characters (`VARCHAR(2048)`).https://lab.civicrm.org/dev/core/-/issues/3488Minor Search Kit bug: Map Contacts does not update2024-02-03T05:03:23ZAndrew WestMinor Search Kit bug: Map Contacts does not updateOverview
----------------------------------------
If you run Map Contacts in Search Kit, then change the search critiera and run it again, you get the original results.
Reproduction steps
----------------------------------------
1. Sear...Overview
----------------------------------------
If you run Map Contacts in Search Kit, then change the search critiera and run it again, you get the original results.
Reproduction steps
----------------------------------------
1. Search for some contacts
2. Select all, then Map Contacts
3. Close the popup
4. Change the criteria considerably and run the search
5. Select all, then Map Contacts
6. The original results appear
Environment information
----------------------------------------
5.50 with the [proximity patch](https://github.com/civicrm/civicrm-core/pull/23597) applied
Comments
----------------------------------------
The test sites don't have a geocoding provider set up so I can't say for sure it's not something on our setup.https://lab.civicrm.org/dev/core/-/issues/3487CiviCRM Status Page Blank Upon Upgrade to 5.50.02022-06-01T18:20:45ZjohngehrigCiviCRM Status Page Blank Upon Upgrade to 5.50.0Overview
----------------------------------------
Upon upgrade to CiviCRM 5.50.0, the CiviCRM Status page appears blank (i.e. no status information loads on the page). The CiviCRM status information still loads on the CiviCRM Dashboard i...Overview
----------------------------------------
Upon upgrade to CiviCRM 5.50.0, the CiviCRM Status page appears blank (i.e. no status information loads on the page). The CiviCRM status information still loads on the CiviCRM Dashboard in the modal bubble. Otherwise, the upgrade appears successful and everything works properly.
Reproduction steps
----------------------------------------
Run upgrade
Current behaviour
----------------------------------------
CiviCRM System Status page is blank (i.e. no status information loads)
Expected behaviour
----------------------------------------
CiviCRM System Status page loads System Status information
Environment information
----------------------------------------
Browser: Chrome 102.0.5005.63 (Official Build) (64-bit)<br/>
CiviCRM: 5.50.0, upgrading from 5.48.0<br/>
PHP: 7.4<br/>
CMS: WordPress 6.0<br/>
Database: MariaDB 10.3<br/>
Web Server: Apache
Comments
----------------------------------------
I tried to find the problem with the CiviCRM Status page but nothing really stuck out -- I checked the log files, cleared the cache, checked with a different browser, and also checked the cPanel logs but couldn't see anything with errors. Finally, I also checked the Release Notes for releases between 5.48.1 - 5.49.4 to see if any incremental release mentioned this type of error for a possible regression and did not see anything related to it in the Release Notes either.<br/><br/>![6-1-2022_1-01-40_PM](/uploads/98988532824cd2428dfb3f1ebcdaff4f/6-1-2022_1-01-40_PM.png)
![6-1-2022_1-02-08_PM](/uploads/d09873fcb5fa23476536d417a7a40d0e/6-1-2022_1-02-08_PM.png)https://lab.civicrm.org/dev/core/-/issues/3486Merge multiple event participant changes ownership of contribution inappropri...2024-02-04T05:03:27ZStoobMerge multiple event participant changes ownership of contribution inappropriatelyHow to reproduce:
1) Contact A purchases two tickets for self and guest, Contact B, using Multiple Participant registration. As appropriate this creates a contribution for Contact A, and participant for Contact A and Contact B.
2) Cont...How to reproduce:
1) Contact A purchases two tickets for self and guest, Contact B, using Multiple Participant registration. As appropriate this creates a contribution for Contact A, and participant for Contact A and Contact B.
2) Contact B is a duplicate record of pre-existing Contact C. Merge the "new" Contact B into into Contact C on the right.
3) Inappropriate behavior: the contribution record in Contact A record is on Contact C.https://lab.civicrm.org/dev/core/-/issues/3485Installer - CiviGrant option no longer works2022-06-11T15:47:08ZtottenInstaller - CiviGrant option no longer worksOverview
----------------------------------------
When performing a web-based installation on Drupal or WordPress, it presents a list of components that you can toggle. One option no longer works correctly.
Reproduction steps
---------...Overview
----------------------------------------
When performing a web-based installation on Drupal or WordPress, it presents a list of components that you can toggle. One option no longer works correctly.
Reproduction steps
----------------------------------------
1. Create an empty D7/BD/WP site
2. Enable CiviCRM
3. In the status alert, click the link to `civicrm/setup`
4. Enable the CiviGrant option
5. Proceed with install
Current behaviour
----------------------------------------
CiviGrant is not activated
Expected behaviour
----------------------------------------
Activate CiviGrant extension
Or: Don't present the option
Environment information
----------------------------------------
Hydra site for WP: http://site-list.test-1.civicrm.org:8001/?filter=hydra-* (http://hydra-wp.test-1.civicrm.org:8002/)
Comments
----------------------------------------
I noticed this while trying the 5.50 installer, but it probably regressed circa 5.48.
The installer currently presents a list of components (https://github.com/civicrm/civicrm-core/blob/master/setup/plugins/blocks/components.civi-setup.php) and populates `$e->getModel()->components`.
To configurably toggle extensions during install, it needs to update `$e->getModel()->extensions`.
https://github.com/civicrm/civicrm-core/blob/master/setup/src/Setup/Model.php#L42-L455.51.0