CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-12-13T10:01:03Zhttps://lab.civicrm.org/dev/core/-/issues/4859FormBuilder / Afform: Deleted options disappear when customizing options in a...2023-12-13T10:01:03ZJustin657FormBuilder / Afform: Deleted options disappear when customizing options in a date fieldOverview
----------------------------------------
In FormBuilder, when customizing the select options in a date field, the deleted options completely disappear.
![image](/uploads/30f5a2fbd00ec6dedb42319ee88b4a23/image.png)
Reproduction...Overview
----------------------------------------
In FormBuilder, when customizing the select options in a date field, the deleted options completely disappear.
![image](/uploads/30f5a2fbd00ec6dedb42319ee88b4a23/image.png)
Reproduction steps
----------------------------------------
Happening on my 5.67.3. I reproduced this on d10 demo site running 5.70.alpha1: https://d10-master.demo.civicrm.org/.
1. Add a **date field** (such as Contact Created Date) as a filter on a search form.
1. On the date field, click the Gear icon, then click **Customize options**.
1. In the list of options, find "Today" and **click the Trash icon** to remove it from the list. It moves to the bottom of the list under a section "Delete options."
1. Scroll to the top of the list and click the green **Done** button.
2. Save the form. (optional)
3. Now go to the Customize Options for that same date field, and search for the item "Today" which we deleted previously. It's gone. There is no list of "Deleted options" at the bottom.
Current behaviour
----------------------------------------
The "Deleted options" list disappears after saving the customized options for a date filter.
Expected behaviour
----------------------------------------
The list of "Deleted options" should always show if there are any options that have been removed.
![image](/uploads/7e94c9a534316fbe461972150cdb166a/image.png)colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/4858Contact id quicksearch broken2024-03-15T13:24:20ZAndy ClarkContact id quicksearch brokenContact id quicksearch has broken in 5.67.3, albeit occasionally. User cannot locate any contacts by id at all, and using Drupal 'masquerade I verified this to be the case. The fix was to run the 'Cleanup Caches' option. What may be a...Contact id quicksearch has broken in 5.67.3, albeit occasionally. User cannot locate any contacts by id at all, and using Drupal 'masquerade I verified this to be the case. The fix was to run the 'Cleanup Caches' option. What may be a clue is that this system uses ACLs and although this user would have been restricted by ACLs she would have had access to the contacts she was searching for. As an administrator I could see the contacts when she couldn't which does seem to point to ACLs as the problem.https://lab.civicrm.org/dev/core/-/issues/4857Standalone: cms:administer users permission is not declared; cannot be granted2023-12-19T11:20:09ZRichStandalone: cms:administer users permission is not declared; cannot be grantedThere's existing core code for `cms:administer users` permission which standalone has also used for various forms/apis.
But it doesn't exist.
It may be as simple as declaring the permission in a hook in standaloneusers ext. Or it may n...There's existing core code for `cms:administer users` permission which standalone has also used for various forms/apis.
But it doesn't exist.
It may be as simple as declaring the permission in a hook in standaloneusers ext. Or it may need more work.https://lab.civicrm.org/dev/core/-/issues/4854SearchKit: Update of multiselect custom field is working in non-obvious way, ...2023-12-13T09:58:58ZDetlev SieberSearchKit: Update of multiselect custom field is working in non-obvious way, which may result in data loss.## Overview
SearchKit allows to update the selected entities (especially: contacts). However, when updating a multiselect custom field, the old values are deleted when a new one is selected.
This might be how it was designed, but won'...## Overview
SearchKit allows to update the selected entities (especially: contacts). However, when updating a multiselect custom field, the old values are deleted when a new one is selected.
This might be how it was designed, but won't be (imho) the way the user would expect it to work: I would have expected to have this work such as "tagging" a contact - where one contact might get additional tags.
## Example use-case
1. Create a custom field for contacts as alphanumeric with multiselect, create at least two options.
2. Open a contact and check the multiselect with option 1.
3. Create a SearchKit where you can find the above contact.
4. Select the contact
5. Action: Update, check the multiselect with option 2
6. Result: Instead of adding option 2 to the multiselect custom field and leaving option 1 as is, option 1 is unchecked.
## Current behaviour
Instead of adding option 2 to the multiselect custom field and leaving option 1 as is, option 1 is unchecked.
This is not what a user might expect and will result in loss of data.
## Proposed behaviour
The value for option 1 should be kept and option 2 should be added.
## Comments
Perhaps it makes sense to add another action ("update add"), that will add new options.https://lab.civicrm.org/dev/core/-/issues/4850Recreate unit tests on core screens that are converted to search displays2023-12-08T08:42:44ZDaveDRecreate unit tests on core screens that are converted to search displaysCompanion to https://lab.civicrm.org/dev/core/-/issues/3912
Here's a start, found via https://github.com/civicrm/civicrm-core/pull/28558
- [ ] CRM_Activity_Form_SearchTest.testSearch
- [ ] CRM_Admin_Form_PaymentProcessorTest.testUpdate...Companion to https://lab.civicrm.org/dev/core/-/issues/3912
Here's a start, found via https://github.com/civicrm/civicrm-core/pull/28558
- [ ] CRM_Activity_Form_SearchTest.testSearch
- [ ] CRM_Admin_Form_PaymentProcessorTest.testUpdateAcceptCreditCard
- [ ] CRM_Core_FormTest.testOpeningForms with data set "Location Type"
- [ ] CRM_Core_FormTest.testOpeningForms with data set "Message Templates"
- [ ] CRM_Core_FormTest.testOpeningForms with data set "Scheduled Jobs"
- [ ] CRM_Core_OptionGroupTest.testSanitizeFromEmailAddress with data set 0
- [ ] CRM_Core_OptionGroupTest.testSanitizeFromEmailAddress with data set 1
- [ ] CRM_Core_OptionGroupTest.testSanitizeFromEmailAddress with data set 2https://lab.civicrm.org/dev/core/-/issues/4849Shorten all Event iCal descriptions to match Add event to Google Calendar2024-03-07T00:52:44ZshaneonabikeShorten all Event iCal descriptions to match Add event to Google CalendarOverview
----------------------------------------
Presently, the _Add event to Google Calendar_ provide the ability to add a CiviCRM event into Google Calendars. The description is reduced down to the first paragraph and a link to the Ev...Overview
----------------------------------------
Presently, the _Add event to Google Calendar_ provide the ability to add a CiviCRM event into Google Calendars. The description is reduced down to the first paragraph and a link to the Event details is provided below. This is a lot cleaner than the present _Add event to iCalendar_, which includes all the Event description
![Selection_001](/uploads/33efb84cb475bfff4b087364d08d705c/Selection_001.png)
Example use-case
----------------------------------------
1. Create a New Event
1. Add a long description
1. View Event Info page
Current behaviour
----------------------------------------
The description provided in the ```ics``` and other formats is quite long.
Proposed behaviour
----------------------------------------
Reduce the description down to one paragraph with a link to the actual Event within the description. It would make it consistent and also probably a bit cleaner since most people (I think) don't read a full description after they have added something to their calendar but a reference is awesome!https://lab.civicrm.org/dev/core/-/issues/4848Nuance logging on API Authorization fails2023-12-07T00:07:32ZeileenNuance logging on API Authorization failsWhen an api request fails authorization one of 2 things happens
1) too much information is logged to our logs
2) too little information is logged.
In the former case some things like SearchKit rely on authorization failing appropriatel...When an api request fails authorization one of 2 things happens
1) too much information is logged to our logs
2) too little information is logged.
In the former case some things like SearchKit rely on authorization failing appropriately and logging can cause people to spend time debugging & trying to fix issues that are normal operation - ultimately both https://github.com/civicrm/civicrm-core/pull/28259 and https://github.com/civicrm/civicrm-core/pull/28260 fall in this category & nearly wound up opening up security to fix log noise
In the latter case an api call is failing authorization but it is hard to tell where. We recently hit this where the logged output was unhelpful because the backtrace being logged only got as far as the api call - we were not getting the trace from the exception itself (and the fail was happening on something the api called, not the main api). Hence we wound up altering the code to
```
\CRM_Core_Error::backtrace('API Request Authorization failed' . $apiRequest['action'] . " " . $apiRequest['entity'], TRUE);
\CRM_Core_Error::debug_var('backtrace', $e->getTraceAsString());
```
I think that it makes sense to be able to specify at the api call level when you don't care about logging exceptions (ie searchkit) but also to get some more info when you dohttps://lab.civicrm.org/dev/core/-/issues/4847Activity-based SearchKit results for 'restricted' users (via the Related Perm...2024-02-08T21:01:05ZpetednzActivity-based SearchKit results for 'restricted' users (via the Related Permissions Module) are no longer restricting results to only Activities of Contacts the user has access tohttps://chat.civicrm.org/civicrm/pl/wj4t3rrh7ir5uyz7t88c7fuj8o
We are using the "Related Permissions Module" https://civicrm.org/extensions/relationship-permissions-acls
Beyond that all we are doing is
- use relationship A to join X (...https://chat.civicrm.org/civicrm/pl/wj4t3rrh7ir5uyz7t88c7fuj8o
We are using the "Related Permissions Module" https://civicrm.org/extensions/relationship-permissions-acls
Beyond that all we are doing is
- use relationship A to join X (teacher) to Y (school)
- use relationship B to join Y (school) to Z (student)
- give X necessary permissions to see All Activities but not see All Contacts.
This means that in pure civicrm when X logs in they only see their Students and the relevant Activities.
- Add an SK to show My Contacts and confirm that X only sees their Students - PASS
- Add an SK to show My Activities (I can export but it is super simple) and confirm that X only sees Activities where their Students are the Target - FAIL - they now see all Students with specified Activity
This was the query from the above which worked up till last week when we ran a civi upgrade.
```
SELECT a.id AS id, a.subject AS subject, a.activity_type_id AS activity_type_id:label, Activity_ActivityContact_Contact_01.sort_name AS Activity_ActivityContact_Contact_01.sort_name, Activity_ActivityContact_Contact_01.id AS Activity_ActivityContact_Contact_01.id
FROM civicrm_activity a
INNER JOIN (civicrm_activity_contact Activity_ActivityContact_Contact_01_via_activitycontact INNER JOIN civicrm_contact Activity_ActivityContact_Contact_01 ON (Activity_ActivityContact_Contact_01_via_activitycontact.contact_id = Activity_ActivityContact_Contact_01.id)) ON Activity_ActivityContact_Contact_01_via_activitycontact.record_type_id = "3" AND Activity_ActivityContact_Contact_01_via_activitycontact.activity_id = a.id
LEFT JOIN civicrm_value_attendance_record_15 Attendance_record_1 ON a.id = Attendance_record_1.entity_id
WHERE (a.activity_type_id = "51")
AND (Attendance_record_1.week_commencing_124 BETWEEN "20231203" AND "20231209")
AND (a.is_test = "0")
AND (a.is_deleted = "0")
```colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/4846API Deprecation2023-12-20T19:19:58ZtreseroAPI DeprecationLots of these in the log for mailings
[warning] Deprecated function CRM_Mailing_BAO_MailingComponent::retrieve, use API.
CRM_Core_Error::deprecatedFunctionWarning
CRM_Mailing_BAO_MailingComponent::retrieve
CRM_Mailing_Form_Component::se...Lots of these in the log for mailings
[warning] Deprecated function CRM_Mailing_BAO_MailingComponent::retrieve, use API.
CRM_Core_Error::deprecatedFunctionWarning
CRM_Mailing_BAO_MailingComponent::retrieve
CRM_Mailing_Form_Component::setDefaultValues
CRM_Core_Form::buildForm
Array
(
[civi.tag] => deprecated
)
Trying to make an email template, and I get this.
Wish I could help more.https://lab.civicrm.org/dev/core/-/issues/4845CiviEvent with approvals: Registration form not pre-filled with (custom) part...2023-12-20T19:21:06ZTobias Voigttobias.voigt@civiservice.deCiviEvent with approvals: Registration form not pre-filled with (custom) participant dataI'm not sure wether this is a proposal or an issue. I'm using the approval workflow for CiviEvent where participants get a confirmation link after they've been approved by admins.
While this works great for simple registration use cases...I'm not sure wether this is a proposal or an issue. I'm using the approval workflow for CiviEvent where participants get a confirmation link after they've been approved by admins.
While this works great for simple registration use cases, where only contact information is gathered in the initial registration form, this feature regrettably can't be used for more comlex use cases, where the initial form also contains additional (custom) participant data (e.g. "Do you want the vegetarian option for dinner?").
So, if there's any fields for custom participant data in the initial registration form, users would fill out the form and send it. Afterwards, admins approve the registration and a confirmation link is sent out to the approved user. If he/she clicks on the confirmation link and chooses to confirm, all contact data gets pre-filled into the form - BUT: the participant data - which is already stored in the database from the initial form - is not pre-filled and has to be filled out again.
This drastically limits the scope of use cases this feature could work for, since in almost all our client's projects we work with additional / custom participant data.
So my question is: Is this a bug and the participant data should actually be loaded during the confirmation process? Or was this feature never intended? Or maybe the feature was intended but never realized? In any case: What might be the scope of development work necessary to not only pre-fill the confirmation form with contact data but also with participant data?https://lab.civicrm.org/dev/core/-/issues/4844Text field in FormBuilder breaks when inserting links2023-12-06T12:04:20Zjoshjosh@civicrm.orgText field in FormBuilder breaks when inserting linksAdding text with links in a FormBuilder text field functions as expected when adding for the first time. However, subsequent changes or attempts at making changes fail and the text appears to be truncated in the admin UI at the start of ...Adding text with links in a FormBuilder text field functions as expected when adding for the first time. However, subsequent changes or attempts at making changes fail and the text appears to be truncated in the admin UI at the start of the first link. The text on the frontend display remains as the original text and is neither truncated nor incorporates any changes despite successful "saves" in the admin interface.
![form-builder-text-issue](/uploads/493a188730553f1631d9613c50dce4da/form-builder-text-issue.png)
I've tested on the d9 sandbox and can reproduce that the text in the text box in the admin UI is truncated at the first link, however changes to text prior to the first link to appear to function as expected, so that bit may be specific to an issue on our site (civicrm.org).https://lab.civicrm.org/dev/core/-/issues/4842Allow bulk-enabling extensions through UI2023-12-08T13:17:56ZnoahAllow bulk-enabling extensions through UICurrent behaviour
----------------------------------------
On Administer > System Settings > Extensions, only one extension can be acted on at a time.
Proposed behaviour
----------------------------------------
It should be possible to...Current behaviour
----------------------------------------
On Administer > System Settings > Extensions, only one extension can be acted on at a time.
Proposed behaviour
----------------------------------------
It should be possible to select multiple extensions and perform the same action (Install, Disable, Uninstall) on all of them.https://lab.civicrm.org/dev/core/-/issues/4840Searchkit In Place Edit might load slow.2023-12-05T22:29:38ZjaapjansmaSearchkit In Place Edit might load slow.When creating the search kit for the permissions screen of the Standalone CiviCRM.
It turned out that the data loads very slow, because all permissions are shown for every role. And the in-place-edit makes this screen loading very slow. ...When creating the search kit for the permissions screen of the Standalone CiviCRM.
It turned out that the data loads very slow, because all permissions are shown for every role. And the in-place-edit makes this screen loading very slow.
@colemanw thought the permission check within in the in-place-edit was causing this.
See this PR which adds the permissions screen to standalone CiviCRM: https://github.com/civicrm/civicrm-core/pull/28523https://lab.civicrm.org/dev/core/-/issues/4838APIv3 call to GroupContact doesn't complete when using IN2023-12-07T14:24:57ZbrienneAPIv3 call to GroupContact doesn't complete when using INOverview
----------------------------------------
There is a bug within APIv3 when making a 'GET' call to 'GroupContact', where the Contact ID is set and the Group ID uses 'IN'.
Reproduction steps
--------------------------------------...Overview
----------------------------------------
There is a bug within APIv3 when making a 'GET' call to 'GroupContact', where the Contact ID is set and the Group ID uses 'IN'.
Reproduction steps
----------------------------------------
1. Click on **Support -> Developer -> API Explorer v3**.
1. Set *Entity* to **GroupContact** and *Action* to **get**
1. Add two parameters:
* Group ID IN (select at least one group)
* Contact ID = (select a contact)
1. Click **Execute**
1. Note that nothing is returned, only a spinning/loading wheel
Current behaviour
----------------------------------------
A call to APIv3 where the Contact ID is set and the Group ID uses IN does not finish executing. This seems to be happening because the validation doesn't support an array and fails in php 8.1.
```php
$result = civicrm_api3('GroupContact', 'get', [
'sequential' => 1,
'group_id' => ['IN' => ["Administrators"]],
'contact_id' => 203,
]);
```
Expected behaviour
----------------------------------------
The API call should be able to handle an arry and finish execution.
Environment information
----------------------------------------
* __CiviCRM:__ 5.67.0, 5.69.alpha1https://lab.civicrm.org/dev/core/-/issues/4837Saving a system workflow message template without making any changes still ma...2023-12-07T09:11:16ZDaveDSaving a system workflow message template without making any changes still makes civi think you changed itIt seems like it trims it so a trailing newline gets cut off, which technically is a change but not intentional.
I'm thinking the templates themselves shouldn't have trailing newlines. Or the comparison could take trimming into account.It seems like it trims it so a trailing newline gets cut off, which technically is a change but not intentional.
I'm thinking the templates themselves shouldn't have trailing newlines. Or the comparison could take trimming into account.https://lab.civicrm.org/dev/core/-/issues/4834Afform conditionnal fields based on checkboxes2023-12-06T23:59:18ZbgmAfform conditionnal fields based on checkboxes- Create a custom field of type checkbox, add a few options
- Create an Afform using that conditional field
- Add a field condition on another field (ex: lastname) that depends on a specific checkbox being checked
Result: field is not d...- Create a custom field of type checkbox, add a few options
- Create an Afform using that conditional field
- Add a field condition on another field (ex: lastname) that depends on a specific checkbox being checked
Result: field is not displayedhttps://lab.civicrm.org/dev/core/-/issues/4832CiviReport 'Available for Dashboard' checkbox lost functionality2023-12-20T19:20:26ZbrienneCiviReport 'Available for Dashboard' checkbox lost functionalityOverview
----------------------------------------
The ‘Available for Dashboard?’ checkbox on CiviReports has lost its functionality.
Reproduction steps
----------------------------------------
1. On an existing or new CiviReport, click ...Overview
----------------------------------------
The ‘Available for Dashboard?’ checkbox on CiviReports has lost its functionality.
Reproduction steps
----------------------------------------
1. On an existing or new CiviReport, click on the **Access** tab
* If it is a new report, add a title on the **Title and Format** tab to make sure the report can be easily found.
1. Check the box next to the *Available for Dashboard?* label
1. Save the report from the *Actions* menu.
1. Go to the CiviCRM home page and do a hard reload (or even a cache clear)
1. Note that the report is either still present as an available dashlet ~~or not listed at all.~~
Current behaviour
----------------------------------------
Unchecking the *Available for Dashboard?* box on an existing CiviReport that is already available as a dashlet does not remove the report from the list of available dashlets on the CiviCRM home page
~~Checking the *Available for Dashboard?* on a new or existing CiviReport does not add it to the list of available dashlets on the CiviCRM page.~~
Deleting a report also does not remove the dashlet from the available options, however, the user will encounter a non-fatal error message that ‘You have tried to access a report that does not exist.’
Expected behaviour
----------------------------------------
The *Available for Dashboard?* checkbox should accurately control whether the report is or is not available as a dashlet.
Environment information
----------------------------------------
* __CiviCRM:__ 5.67.0https://lab.civicrm.org/dev/core/-/issues/4829Standalone: Authx jwt should not generate a cookie2024-03-09T18:36:02ZbgmStandalone: Authx jwt should not generate a cookieRelated to this PR: https://github.com/civicrm/civicrm-core/pull/28407
We silenced the test for Standalone for now, but if I understand correctly, when doing a request with jwt for authx, it should not generate a cookie.
(This is very ...Related to this PR: https://github.com/civicrm/civicrm-core/pull/28407
We silenced the test for Standalone for now, but if I understand correctly, when doing a request with jwt for authx, it should not generate a cookie.
(This is very low priority, very low impact)https://lab.civicrm.org/dev/core/-/issues/4827FormBuilder - refreshing page after saving a new or cloned one lose current c...2023-12-06T22:49:59ZsamuelsovFormBuilder - refreshing page after saving a new or cloned one lose current contextCase 1:
- use clone button of a FormBuilder
- change the title and set a page route
- save
- press F5 to refresh the page
- a new clone is created instead of refreshing the current one
Case 2:
- create a new submission form
- set a titl...Case 1:
- use clone button of a FormBuilder
- change the title and set a page route
- save
- press F5 to refresh the page
- a new clone is created instead of refreshing the current one
Case 2:
- create a new submission form
- set a title and a page route
- save
- press F5 to refresh the page
- a new submission form is created instead of refreshing the current one
A way to solve this would be to redirect to the edit page `civicrm/admin/afform#/edit/afformMyNewForm` after we press the Save button instead of keeping the route `civicrm/admin/afform#/create/form/Individual` or `civicrm/admin/afform#/clone/afformMyForm`https://lab.civicrm.org/dev/core/-/issues/4825Issues with CiviCRM Tables During MySQL 8.0 Upgrade2023-12-06T23:29:47ZfatihatesIssues with CiviCRM Tables During MySQL 8.0 UpgradeDuring the upgrade to MySQL 8.0, I encountered one different warnings related to CiviCRM tables and I want to take the correct steps in this regard. These warnings are listed below:
Usage of db objects with names conflicting with new re...During the upgrade to MySQL 8.0, I encountered one different warnings related to CiviCRM tables and I want to take the correct steps in this regard. These warnings are listed below:
Usage of db objects with names conflicting with new reserved keywords Warning: The following objects have names that conflict with new reserved keywords. Ensure queries sent by your applications use quotes when referring to them or they will result in errors.
Do I need to fix the mentioned 4 tables (sample tables listed below)? Are the commands I provided for fixing these tables correct and valid?
Sample Tables
----------------------------------------
`xxx_xx.civicrm_mapping_field.grouping - Column name`
`xxx_xx.civicrm_option_value.grouping - Column name`
`xxx_xx.log_civicrm_mapping_field.grouping - Column name`
`xxx_xx.log_civicrm_option_value.grouping - Column name`
Images
----------------------------------------
![2023-12-01_01_59_19](/uploads/934aa70e46592189d1c748892224c31e/2023-12-01_01_59_19.png)
Proposed Solution:
----------------------------------------
`SELECT "grouping" FROM xxx_cagri.civicrm_mapping_field;`
Similar Issues
----------------------------------------
https://civicrm.stackexchange.com/questions/45993/issues-with-civicrm-tables-during-mysql-8-0-upgrade
Environment information
----------------------------------------
* __CiviCRM: 5.67.0
* __PHP: 8.1.25
* __CMS: Joomla 4.4.1
* __Database: 5.7.44