Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-23T05:03:29Zhttps://lab.civicrm.org/dev/core/-/issues/3785participant field group sort order does not reflect configured order2024-03-23T05:03:29Zmagnolia61participant field group sort order does not reflect configured orderOverview
----------------------------------------
We have several custom field groups for participants.
Some for a specific event type, some others for specific participant roles
Current behaviour
---------------------------------------...Overview
----------------------------------------
We have several custom field groups for participants.
Some for a specific event type, some others for specific participant roles
Current behaviour
----------------------------------------
Currently the order in which the custom field groups are displayed while editing of viewing does not reflect the sort order that we selected in the custom field group settings. There is even a difference between viewing and editing a participant the one is ascending, the other descending.
Proposed behaviour
----------------------------------------
The sort order of the custom field groups for participants follows the selected order of the custom field groups. They are not groupes by selector (event type, role, etc), but follow the order that is configured.
Comments
----------------------------------------
I have no clue where to find this, and I'm not really a coder. Probably this is a very small change if you know where to look for.https://lab.civicrm.org/dev/core/-/issues/3781Fatal Error on upgrade to 5.52.02022-08-18T23:26:03ZkcristianoFatal Error on upgrade to 5.52.0After upgrade from 5.51.3 to 5.52.0 the browser returns a 500 error.
php log shows:
```
[05-Aug-2022 11:41:51 UTC] PHP Fatal error: Declaration of Symfony\Component\DependencyInjection\ServiceLocator::has(string $id) must be compatible...After upgrade from 5.51.3 to 5.52.0 the browser returns a 500 error.
php log shows:
```
[05-Aug-2022 11:41:51 UTC] PHP Fatal error: Declaration of Symfony\Component\DependencyInjection\ServiceLocator::has(string $id) must be compatible with Psr\Container\ContainerInterface::has($id) in /home/wpcv/public_html/wp-content/plugins/civicrm/civicrm/vendor/symfony/dependency-injection/ServiceLocator.php on line 46
```
There is no corresponding entry in ConfigAndLog nor the apache error log
I thought it might be extended reports due to https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/issues/516 But doing a git checkout of master first had no effect.
This had not come up in the testing I had done on generic sites, but this did occur on the first production site I upgraded. I'll look further as it may be something site-specific. Logging an issue in case any others have the same problem.
Env:
Apache 2.4
php 7.4
mariadb 10.3
WP 5.9.3
CiviCRM 5.52.0 (upgrade from 5.51.3)https://lab.civicrm.org/dev/core/-/issues/3780Add an ability to set a field as hidden in formbuilder2023-12-21T07:20:06ZKurund JalmiAdd an ability to set a field as hidden in formbuilderKurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3779Add display only field support for formbuilder2024-02-02T01:19:18ZKurund JalmiAdd display only field support for formbuildercolemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3778Event participant registered by contact ID2023-09-04T08:05:09Zmattwiremjw@mjwconsult.co.ukEvent participant registered by contact IDSee discussion at https://github.com/civicrm/civicrm-core/pull/23936
The existing field "registered_by_id" has a number of problems:
It does not get set if you add a registration via the backend forms.
It always gets set to the primary...See discussion at https://github.com/civicrm/civicrm-core/pull/23936
The existing field "registered_by_id" has a number of problems:
It does not get set if you add a registration via the backend forms.
It always gets set to the primary participant even when the user selects "Not X, or want to register a different person" (ie. URL has the parameter cid=0).
The "registered_by_id" field requires a participant ID and not a contact ID. This means that you cannot record that you registered one or more participants unless you are also a participant of that event.
Why not change registered_by_id to a contact ID? That's likely to have all sorts of unexpected impacts as the existing field is used in various wonderful ways (eg. registration emails behave a bit differently if there is a registered_by_id).
Does this fix everything?
No, not yet. That will require more work on the UI / mailing side of things to use the new field. But it's accessible as part of the Participant entity which means it can be used via the API and with searchkit.
This PR includes a little bit of UI work on the backend event participant form to allow you to set the new "registered by contact" field and this form will prefer that field.
What about setting the primary participant ID when they weren't the one registering?
Yes, this PR fixes that. It checks if the contact ID on the form is the same as the primary participant contact ID. If it's not it won't set the registered_by_id field.
Core patches:
- ~~https://github.com/civicrm/civicrm-core/pull/24167 - Add created_id field to civicrm_participant~~ merged
- ~~https://github.com/civicrm/civicrm-core/pull/24304 - Add code hook to set civicrm_participant.created_id~~ merged
- https://github.com/civicrm/civicrm-core/pull/24749 - Add 'Registered by Contact ID' to civireport
- _Need to extract patches from https://github.com/civicrm/civicrm-core/pull/23936 for Quickform UI etc._
- https://github.com/civicrm/civicrm-core/pull/24750 - Work in progress for participant forms.https://lab.civicrm.org/dev/core/-/issues/3777Afform: Radios should show default value when form is loaded/reset2023-09-02T05:11:54Zmattwiremjw@mjwconsult.co.ukAfform: Radios should show default value when form is loaded/resetSee #3449, #3450, https://github.com/civicrm/civicrm-core/pull/23413 (testing comments from @artfulrobot )
If you select a default value the filter is applied but it is not shown as "selected" when the form is loaded/reset.See #3449, #3450, https://github.com/civicrm/civicrm-core/pull/23413 (testing comments from @artfulrobot )
If you select a default value the filter is applied but it is not shown as "selected" when the form is loaded/reset.Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3776CiviCRM - next version? Getting fit for future...2022-08-24T03:00:46ZTobias KrauseCiviCRM - next version? Getting fit for future...Sorry if this ticket is too general but I don't know where to go with my concerns.
We just updated our servers to PHP 8.0 (which was released im November 2020) and then I found some warnings in the logs about deprecated code. To find th...Sorry if this ticket is too general but I don't know where to go with my concerns.
We just updated our servers to PHP 8.0 (which was released im November 2020) and then I found some warnings in the logs about deprecated code. To find the reasons for these I diged into the code basis of CiviCRM and I found out that CiviCRM relys on very old frameworks (e.g. Smarty version 2.6 from the year 2016) or on frameworks not really actively maintained (zetacomponents/mail from the year 2020). Just two examples but I feel if I would check the other dependencies there might be some more old frameworks.
The tip for now from the Civi-community: stay on PHP 7.4 - which will reach end of life by November this year. Even PHP 8.0 will just receive security updates until November this year so that from November on PHP 8.1 would be the correct version - on which CiviCRM is absolutely not working as I already tested.
Now I got very concerned about the next years. We heavily use CiviCRM in our daily work for the administration of thousands of donators and newsletter subscribers and for the newsletter sending so that CiviCRM is the main tool of our daily work. And now CiviCRM already feels a little bit like a dinosaur to me - especially compared with Drupal 9 I am working with in general. I fear that CiviCRM cannot keep up with the ongoing developments of PHP (and JavaScript).
My question: are there any plans for updating the dependencies? Maybe even a plan to change to more modern frameworks like Twig? I found a roadmap where Form Builder, CiviCRM Standalone and UI Improvements are listed but this feels just like some new features based on the current code basis.https://lab.civicrm.org/dev/core/-/issues/3775Disable Deadlock retries for Mailing Jobs2024-03-24T05:03:28ZseamusleeDisable Deadlock retries for Mailing JobsSo CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful becaus...So CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful because it means it can get tied up on get_lock queries re-trying them a silly number of times when it should be moving onto the next thingseamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/3773Deprecated function: Required parameter $sortCriteria follows optional parame...2024-03-20T05:03:26ZTobias KrauseDeprecated function: Required parameter $sortCriteria follows optional parameter $countEverytime cron runs I see this message in logs:
`Deprecated function: Required parameter $sortCriteria follows optional parameter $count in include() (line571 in /var/www/civi_live/vendor/composer/ClassLoader.php)`
After searching a li...Everytime cron runs I see this message in logs:
`Deprecated function: Required parameter $sortCriteria follows optional parameter $count in include() (line571 in /var/www/civi_live/vendor/composer/ClassLoader.php)`
After searching a little bit the only place which makes sense for this message is ezcMailImapTransport->sortFromOffset() in vendor/zetacomponents/mail/src/transports/imap/imap_transport.php
My setup:
- drupal 9.3.19
- CiviCRM 5.51.1
- PHP 8.0
I don't knowwhere this dependency comes from but this library needs an update for PHP 8.0 - or it should be considered to use another dependency. For IMAP handling I have good experiences with https://github.com/ddeboer/imaphttps://lab.civicrm.org/dev/core/-/issues/3770Figure out how to offer preferredLanguage in api explorer with options2024-03-20T05:03:26ZeileenFigure out how to offer preferredLanguage in api explorer with optionsFrom discussion of adding preferredLanguage - options should be explorer-discoverable
https://github.com/civicrm/civicrm-core/pull/24116#pullrequestreview-1057986655From discussion of adding preferredLanguage - options should be explorer-discoverable
https://github.com/civicrm/civicrm-core/pull/24116#pullrequestreview-1057986655https://lab.civicrm.org/dev/core/-/issues/3768Improvement to Case Detail report2024-03-22T05:03:27ZyashodhaImprovement to Case Detail reportExpose some of the useful columns and filters :
- expose city in case detail report
- add filter for 'Activity type of the last activity'Expose some of the useful columns and filters :
- expose city in case detail report
- add filter for 'Activity type of the last activity'yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3767Import 'encountered an unexpected error' between Step 2 and 3 with 500 rows2022-08-16T22:38:33ZStoobImport 'encountered an unexpected error' between Step 2 and 3 with 500 rowsUsing 5.51.1 Import Contacts the error "The website encountered an unexpected error. Please try again later." This phrase occurs in the CiviCRM code base in several .php files, but is not a normal onscreen backtrace debug output and noth...Using 5.51.1 Import Contacts the error "The website encountered an unexpected error. Please try again later." This phrase occurs in the CiviCRM code base in several .php files, but is not a normal onscreen backtrace debug output and nothing giving more clues in Civi's log files that I can tell.
It occurs in this situation: a file of 500 rows x 30 columns after about 3 seconds of loading after pressing the button in Step 2 to continue to Step 3.
No error appears when that same file is split in half to only 250 rows.
I have tried this same full CSV file (500 rows) on a 5.50.4 install and there is no error.
The import for Individuals with typical data (name, email phone) but does contain several custom fields and an employer relationship. There are also some special characters (international names) I wonder if the import is not handling those well.
Although I cannot provide you my data I would be happy to test if you have a test bed and a way to generate similar testing data of this nature for an import. I hope this has been helpful.https://lab.civicrm.org/dev/wordpress/-/issues/129Fatal Rest errors in WP logs2022-08-03T16:22:23ZrbaughFatal Rest errors in WP logsThis is for a WP 5.9 site running CiviCRM 5.51.0
I have been seeing this fatal error in the WP logs from time to time, but haven't personally run into it to know what triggered it:
```
PHP Fatal error: Uncaught TypeError: array_reduce...This is for a WP 5.9 site running CiviCRM 5.51.0
I have been seeing this fatal error in the WP logs from time to time, but haven't personally run into it to know what triggered it:
```
PHP Fatal error: Uncaught TypeError: array_reduce(): Argument #1 ($array) must be of type array, int given in /home/www/wp-content/plugins/civicrm/wp-rest/Controller/Rest.php:156
Stack trace:
#0 /home/www/wp-content/plugins/civicrm/wp-rest/Controller/Rest.php(156): array_reduce(1, Object(Closure), Array)
#1 /home/www/wp-includes/rest-api/class-wp-rest-server.php(1141): CiviCRM_WP_REST\Controller\Rest->get_items(Object(WP_REST_Request))
#2 /home/www/wp-includes/rest-api/class-wp-rest-server.php(988): WP_REST_Server->respond_to_request(Object(WP_REST_Request), '/civicrm/v3/res...', Array, NULL)
#3 /home/www/wp-includes/rest-api/class-wp-rest-server.php(414): WP_REST_Server->dispatch(Object(WP_REST_Request))
#4 /home/www/wp-includes/rest-api.php(386): WP_REST_Server->serve_request('/civicrm/v3/res...')
#5 /home/www/wp-includes/class-wp-hook.php(307): rest_api_loaded(Object(WP))
#6 /home/www/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters('', Array)
#7 /home/www/wp-includes/plugin.php(522): WP_Hook->do_action(Array)
#8 /home/www/wp-includes/class-wp.php(396): do_action_ref_array('parse_request', Array)
#9 /home/www/wp-includes/class-wp.php(758): WP->parse_request('')
#10 /home/www/wp-includes/functions.php(1310): WP->main('')
#11 /home/www/wp-blog-header.php(16): wp()
#12 /home/www/index.php(17): require('/home/www...')
#13 {main}
thrown in /home/www/wp-content/plugins/civicrm/wp-rest/Controller/Rest.php on line 156
```
I tried to check the Civi logs to see if I could find a match, but think the fatal error trumped it enough that Civi couldn't log it.https://lab.civicrm.org/dev/wordpress/-/issues/128Top menu missing after upgrade to v5.51.12022-07-29T16:19:29ZjsherkTop menu missing after upgrade to v5.51.1I just upgraded from v5.50.3 to v5.51.1 (with WordPress v6.01) on three seperate civicrm installs, and although the upgrade appears to be successful, the top civicrm menu is now missing in all three installs.
When I click on CiviCRM fro...I just upgraded from v5.50.3 to v5.51.1 (with WordPress v6.01) on three seperate civicrm installs, and although the upgrade appears to be successful, the top civicrm menu is now missing in all three installs.
When I click on CiviCRM from left wordpress menu, it takes me to civicrm dashboard, but there is no top menu for me to click on anything.
Any thoughts?https://lab.civicrm.org/dev/core/-/issues/3757Users with administer_reports should be able to delete dashlets from the dash...2024-03-19T05:03:27ZandyburnsUsers with administer_reports should be able to delete dashlets from the dashboardThe current behavior I see is anyone with `administer_reports` can access the "Access" tab in a given report in CiviReport. Therefore, they can create dashlets. However, upon making a dashlet available for the dashboard, these can not be...The current behavior I see is anyone with `administer_reports` can access the "Access" tab in a given report in CiviReport. Therefore, they can create dashlets. However, upon making a dashlet available for the dashboard, these can not be removed by that same user, potentially resulting in a cluttered dashboard and user frustration.
Non-admins are missing trash can delete function:
![image](/uploads/206f154220c69227a784cc2d40e87a39/image.png)
Admin sees trash can:
![image](/uploads/21dbc1ca9cc3247a4752324df98a68b2/image.png)
Sure, interest in civireport is quite low now but this same behavior affects dashlets created from search kit.
For search kit, I would set that `administer data` or maybe `administer_reports` would be the needed permission to remove dashlets. Currently, it is not enough.https://lab.civicrm.org/dev/core/-/issues/3755Search Kit: CiviMail search action fails for non-administrators2022-08-23T21:47:10ZandyburnsSearch Kit: CiviMail search action fails for non-administrators1. A user with `access_civimail`, `access_ajax_api` goes to a contacts search kit display with form builder.
2. Selects some contacts
3. Selects Action > Email Schedule/Send with CiviMail
4. Gets the following error which comes from [her...1. A user with `access_civimail`, `access_ajax_api` goes to a contacts search kit display with form builder.
2. Selects some contacts
3. Selects Action > Email Schedule/Send with CiviMail
4. Gets the following error which comes from [here](https://lab.civicrm.org/dev/core/-/blob/master/ext/search_kit/ang/crmSearchTasks/crmSearchTaskMailing.ctrl.js#L68).
![image](/uploads/80639f024a3c2d38ed44d142d2fa6175/image.png)
I added several permissions such as `administer civicrm` and `administer civicrm data` in debugging. Still fails. They are able to do this same action in Advanced Search. An `administrator` WordPress role can do this action.
Thoughts on further steps to debug?
```
Jul 26 13:49:10 [debug] AJAX Error ({error_id}): failed with exception
Array
(
[error_id] => rZuY-s4sQ-caps
[exception] => Civi\API\Exception\UnauthorizedException: "Authorization failed"
#0 /var/www/example/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(147): Civi\API\Kernel->authorize(Object(Civi\Api4\Provider\ActionObjectProvider), Object(Civi\Api4\Generic\DAOCreateAction))
#1 /var/www/example/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/AbstractAction.php(234): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAOCreateAction))
#2 /var/www/example/wp-content/plugins/civicrm/civicrm/api/api.php(85): Civi\Api4\Generic\AbstractAction->execute()
#3 /var/www/example/wp-content/plugins/civicrm/civicrm/CRM/Api4/Page/AJAX.php(136): civicrm_api4("Group", "create", (Array:3), NULL)
#4 /var/www/example/wp-content/plugins/civicrm/civicrm/CRM/Api4/Page/AJAX.php(77): CRM_Api4_Page_AJAX->execute("Group", "create", (Array:3), NULL)
#5 /var/www/example/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(319): CRM_Api4_Page_AJAX->run((Array:5), NULL)
#6 /var/www/example/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem((Array:16))
#7 /var/www/example/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:5))
#8 /var/www/example/wp-content/plugins/civicrm/civicrm.php(1199): CRM_Core_Invoke::invoke((Array:5))
#9 /var/www/example/wp-includes/class-wp-hook.php(303): CiviCRM_For_WordPress->invoke("")
#10 /var/www/example/wp-includes/class-wp-hook.php(327): WP_Hook->apply_filters("", (Array:1))
#11 /var/www/example/wp-includes/plugin.php(470): WP_Hook->do_action((Array:1))
#12 /var/www/example/wp-admin/admin.php(259): do_action("toplevel_page_CiviCRM")
#13 {main}
)
```
Civi 5.51.1 WP 5.8.4 multisite.https://lab.civicrm.org/dev/core/-/issues/3754Search Kit: SearchDisplay can't start with a dollar sign.2022-07-26T20:47:07ZJonGoldSearch Kit: SearchDisplay can't start with a dollar sign.### Steps to replicate.
* Create a minimal Search Kit search.
* Add a display, title it "$25 donors".
* Try to save the display.
### Expected result
Saved.
### Actual result
"Saving" icon continues indefinitely. Dev tools show a 500 e...### Steps to replicate.
* Create a minimal Search Kit search.
* Add a display, title it "$25 donors".
* Try to save the display.
### Expected result
Saved.
### Actual result
"Saving" icon continues indefinitely. Dev tools show a 500 error: `{"error_code":"1","error_message":"Sorry an error occurred and your request was not completed. (Error ID: FX5K-eX9G-ESWF)"}`.
I think this is happening because it's a chained API call, and chained API calls use dollar signs to represent values that come from elsewhere in the chain.https://lab.civicrm.org/dev/core/-/issues/3751Export fails for contact reference of type multi-select2024-03-17T09:15:14ZKurund JalmiExport fails for contact reference of type multi-selectFor a multi-select custom field when multiple contacts are selected with long names then the export fails.
This happens because temp export table is created with a varchar 255 column. I feel it should be changed to type `text`.For a multi-select custom field when multiple contacts are selected with long names then the export fails.
This happens because temp export table is created with a varchar 255 column. I feel it should be changed to type `text`.https://lab.civicrm.org/dev/coworker/-/issues/1Fix the fix mes2023-04-19T04:51:07ZeileenFix the fix mesI wanted to add this to civicrm-buildkit (which is the meta for this issue) - but I couldn't because all the phar links were 'fixmes' - so was the repo but I figured that one out at leastI wanted to add this to civicrm-buildkit (which is the meta for this issue) - but I couldn't because all the phar links were 'fixmes' - so was the repo but I figured that one out at leasttottentottenhttps://lab.civicrm.org/dev/core/-/issues/3750CiviCRM 5.51.1 APIv4 bug querying tag by name incorrectly returns untagged Co...2022-08-10T02:07:07Zjustinfreeman (Agileware)CiviCRM 5.51.1 APIv4 bug querying tag by name incorrectly returns untagged Contacts when executed by Anonymous but correctly returns tagged Contacts for Authenticated UsersCiviCRM 5.51.1 APIv4 bug querying tag by name **incorrectly** returns **untagged** Contacts when executed by Anonymous but correctly returns tagged Contacts for Authenticated Users. Check Permissions is FALSE for the API call. This was w...CiviCRM 5.51.1 APIv4 bug querying tag by name **incorrectly** returns **untagged** Contacts when executed by Anonymous but correctly returns tagged Contacts for Authenticated Users. Check Permissions is FALSE for the API call. This was working in CiviCRM 5.49.1.
Using CiviCRM 5.49.1, the APIv4 query used the following WHERE clause:
```
$contacts = \Civi\Api4\Contact::get(FALSE)
...
->addWhere('tags:name', 'IN', [9, 'Professional Member'])
```
As of CiviCRM 5.51.1, this started returning different results for Anonymous versus logged in Authenticated Users. Despite the Check Permissions being FALSE for the API call.
In CiviCRM 5.51.1, this WHERE clause DOES work.
```
$contacts = \Civi\Api4\Contact::get(FALSE)
...
->addWhere('tags', 'IN', [9])
```
Also should be noted that this WHERE clause does NOT work either.
```
$contacts = \Civi\Api4\Contact::get(FALSE)
...
->addWhere('tags:name', 'IN', 'Professional Member')
```
Agileware Ref: CIVICRM-2019