CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-02-20T06:26:43Zhttps://lab.civicrm.org/dev/core/-/issues/4133Search Kit: date field - more transformation options2023-02-20T06:26:43ZherbdoolSearch Kit: date field - more transformation optionsThis is a follow-up to https://lab.civicrm.org/dev/core/-/issues/3700, which despite it's title only dealt with aggregating by partial dates. This one is to expand the date options in the Field Transformations for date fields in SearchKi...This is a follow-up to https://lab.civicrm.org/dev/core/-/issues/3700, which despite it's title only dealt with aggregating by partial dates. This one is to expand the date options in the Field Transformations for date fields in SearchKit.
[As mentioned here](https://lab.civicrm.org/dev/core/-/issues/3700#note_80020), it would something similar to:
![Captura_de_pantalla_de_2022-08-04_18-54-00](https://lab.civicrm.org/dev/core/uploads/aca17ace20d78328c85a71a17fcfbabd/Captura_de_pantalla_de_2022-08-04_18-54-00.png)
---
Note that transforming the dates *is* possible by enabling "Rewrite Text" for a field in a display. Then doing something like:
```
{"[join_date]"|date_format:"%m/%d/%Y"}
```
Or whatever the token is for the date field.
It would be handy to have a section in the [User Guide](https://docs.civicrm.org/user/en/latest/searching/searchkit) on some of these tricks for SearchKit. Would save time from asking in the chat.https://lab.civicrm.org/dev/core/-/issues/4129API v4 explorer: boolean params don't render correctly for CV (short)2023-02-20T06:24:39ZnoahAPI v4 explorer: boolean params don't render correctly for CV (short)The API4 explorer generates shorthand `cv` syntax that looks like, for example:
````bash
cv api4 Contact.delete +w 'id = 99' checkPermissions=false useTrash=false
````
However, `cv` does not correctly interpret `false` in this context....The API4 explorer generates shorthand `cv` syntax that looks like, for example:
````bash
cv api4 Contact.delete +w 'id = 99' checkPermissions=false useTrash=false
````
However, `cv` does not correctly interpret `false` in this context. The syntax that works is:
````bash
cv api4 Contact.delete +w 'id = 99' checkPermissions=0 useTrash=0
````
So the explorer should generate that syntax.https://lab.civicrm.org/dev/core/-/issues/4125Use a maintenance template and theme for Drupal 8/9+ in CRM_Utils_System_Drup...2023-02-20T06:21:58ZherbdoolUse a maintenance template and theme for Drupal 8/9+ in CRM_Utils_System_Drupal8::theme() (follow up to dev/core#4076)In https://lab.civicrm.org/dev/core/-/issues/4076 we're splitting up the `theme()` method and putting it into each System class. The Drupal8 method doesn't behave like Drupal 7's, which uses the maintenance template and theme (without th...In https://lab.civicrm.org/dev/core/-/issues/4076 we're splitting up the `theme()` method and putting it into each System class. The Drupal8 method doesn't behave like Drupal 7's, which uses the maintenance template and theme (without the admin menu, etc). It would be nice if it did.
A first attempt looked like the following but it's missing the Civi core JS and CSS:
```
public function theme(&$content, $print = FALSE, $maintenance = FALSE) {
$ret = FALSE;
if (!$print) {
if ($maintenance) {
if ($region = CRM_Core_Region::instance('html-header', FALSE)) {
CRM_Utils_System::addHTMLHead($region->render(''));
}
$renderer = \Drupal::service('bare_html_page_renderer');
$build['content'] = [
'#markup' => \Drupal\Core\Render\Markup::create($content),
];
$civicrmPageState = \Drupal::service('civicrm.page_state');
$title = $civicrmPageState->getTitle();
$response = $renderer->renderBarePage($build, $title, 'maintenance_page');
print $response->getContent();
exit();
}
$ret = TRUE;
}
$out = $content;
if ($ret) {
return $out;
}
else {
print $out;
return NULL;
}
}
```https://lab.civicrm.org/dev/core/-/issues/4124Past campaigns are not to be assigned via batch update/update contributions2023-03-15T06:27:08ZyashodhaPast campaigns are not to be assigned via batch update/update contributionsSteps to replicate :
- Create a campaign with end date in past
![campaign](/uploads/cefd27e11afe0c929803e28f58f67bbb/campaign.png)
- Create a profile configured for contribution fields (including the campaign field)
- Find Contribution...Steps to replicate :
- Create a campaign with end date in past
![campaign](/uploads/cefd27e11afe0c929803e28f58f67bbb/campaign.png)
- Create a profile configured for contribution fields (including the campaign field)
- Find Contributions, and select a few and use the created profile to update the campaign
- The campaign is NOT available in the drop down
![batch_update](/uploads/cfa7bee25d1cb7baa5bd1664b39e00e5/batch_update.png)
- On new/edit contributions, you are able to choose the past campaigns as well (which is the correct behavior).
![new_contribution](/uploads/82d4ddaaf86af46cab608ef26b333ece/new_contribution.png)yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4122Send receipt for contribution in contact dashboard redirects to advanced search2023-02-15T05:58:42ZChabadrichmondSend receipt for contribution in contact dashboard redirects to advanced searchOverview
----------------------------------------
When sending a receipt for a contribution in the contact dashboard it submits the receipt successfully and redirects to the search page with a notice on the top right saying "Because your...Overview
----------------------------------------
When sending a receipt for a contribution in the contact dashboard it submits the receipt successfully and redirects to the search page with a notice on the top right saying "Because your session timed out, we have reset the search page."
I tested on Civicrm Demo site as well and saw it on a number of versions starting from 5.53
Reproduction steps
----------------------------------------
1. Click on Contacts
2. Go to contributions Tab
3. Send a receipt to an existing contribution
4. Email is sent but it redirects to advanced search page with notice about Session timeout
![Receipt_error](/uploads/890aea89a1a364196a66ad79ff6175bc/Receipt_error.gif)
Expected behaviour
----------------------------------------
Receipt dialog box should close with success messagehttps://lab.civicrm.org/dev/core/-/issues/4117Filter Searches by 'is_current' / expires_date2023-02-07T23:27:08ZeileenFilter Searches by 'is_current' / expires_dateThe `civicrm_search` table has an `expires_date` field. I believe it should be used as a filter on the search admin screen.
I copied the field into `civicrm_user_job` when I created that and the searches based on user jobs have expires_...The `civicrm_search` table has an `expires_date` field. I believe it should be used as a filter on the search admin screen.
I copied the field into `civicrm_user_job` when I created that and the searches based on user jobs have expires_date set from the user job.
I realised it is a bit of a pain to add to the js as it would be `expires_date` is in the past OR is NULL - which got me thinking that it is most like `is_current` & perhaps should be a trait like that - with is_current = TRUE as a default
@colemanw - what has me most confused is where to put it - I could add it to `IsCurrentSpecProvider` & it just has different rules - maybe I'll tryhttps://lab.civicrm.org/dev/core/-/issues/4113Afform - Can't display default value for deceased field2023-08-01T20:14:31ZGhost UserAfform - Can't display default value for deceased fieldOverview
----------------------------------------
When you create a Search Kit and want to set a default value to the deceased field in the Form Builder, it doesn't show.
Reproduction steps
----------------------------------------
1. C...Overview
----------------------------------------
When you create a Search Kit and want to set a default value to the deceased field in the Form Builder, it doesn't show.
Reproduction steps
----------------------------------------
1. Create a Search Kit based on Contact and create a Form.
2. In the Form add the 'Is deceased' field into the Form Layout and select a default value. Also add a route to be able to see the Form. See image below:
![image](/uploads/c19e8c240e4c53e1ad662cb30953fbc2/image.png)
3. Go to the Page that you created and you see that the default value is not selected.
![image](/uploads/5c85d8a8dcd614967a9ab67210561f7b/image.png)
Expected behaviour
----------------------------------------
In the created Page the default value should be already selected, which it isnt't the case.
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 109.0.1/Chrome 109.0.5414.120
* __CiviCRM:__ 5.60.alpha1
* __Site:__ [dmaster](https://dmaster.demo.civicrm.org/)https://lab.civicrm.org/dev/core/-/issues/4111Searchkit: Fatal error on Related Contacts search2023-02-08T19:45:59ZshaneonabikeSearchkit: Fatal error on Related Contacts searchHey there,
I built out a Related Contacts search, but noticed recently that there are some Fatal error messages in the Civi logs.
## How to reproduce
You can use my export here it's nothing complicated just a Display of Related Contac...Hey there,
I built out a Related Contacts search, but noticed recently that there are some Fatal error messages in the Civi logs.
## How to reproduce
You can use my export here it's nothing complicated just a Display of Related Contacts (way to go on this feature btw)
```
[
[
"SavedSearch",
"save",
{
"records": [
{
"name": "Related_Contacts",
"label": "Related Contacts",
"form_values": null,
"mapping_id": null,
"search_custom_id": null,
"api_entity": "RelationshipCache",
"api_params": {
"version": 4,
"select": [
"near_relation:label",
"far_contact_id.display_name"
],
"orderBy": [],
"where": [
[
"is_active",
"=",
true
]
],
"groupBy": [],
"join": [],
"having": []
},
"expires_date": null,
"description": null
}
],
"match": [
"name"
]
}
],
[
"SearchDisplay",
"save",
{
"records": [
{
"name": "Relationships",
"label": "Relationships Table",
"saved_search_id.name": "Related_Contacts",
"type": "table",
"settings": {
"actions": true,
"limit": 25,
"classes": [
"table",
"table-striped",
"table-bordered"
],
"pager": {
"show_count": true,
"expose_limit": true
},
"columns": [
{
"type": "field",
"key": "near_relation:label",
"dataType": "String",
"label": "Relationship",
"sortable": true,
"link": {
"path": "",
"entity": "Relationship",
"action": "view",
"join": "",
"target": "crm-popup"
},
"title": "View Related Contact",
"tally": {
"fn": null
}
},
{
"type": "field",
"key": "far_contact_id.display_name",
"dataType": "String",
"label": "Contact Name",
"sortable": true,
"link": {
"path": "",
"entity": "Contact",
"action": "view",
"join": "far_contact_id",
"target": "_blank"
},
"title": "View Contact",
"tally": {
"fn": null
}
}
],
"sort": [
[
"relationship_type_id",
"DESC"
],
[
"far_contact_id.display_name",
"ASC"
]
],
"placeholder": 5,
"tally": {
"label": "Total"
}
},
"acl_bypass": true
}
],
"match": [
"name",
"saved_search_id"
]
}
],
[
"Afform",
"save",
{
"records": [
{
"name": "afsearchRelationships",
"requires": [],
"title": "Relationships",
"description": "",
"is_dashlet": false,
"is_public": false,
"is_token": false,
"permission": "access CiviCRM",
"type": "search",
"entity_type": null,
"join_entity": null,
"contact_summary": "block",
"icon": "fa-list-alt",
"server_route": "",
"redirect": null,
"create_submission": false,
"navigation": null,
"layout": "<div af-fieldset=\"\">\n <af-field name=\"far_contact_id.display_name\" defn=\"{label: 'Contact Name', input_attrs: {}}\" />\n <crm-search-display-table search-name=\"Related_Contacts\" display-name=\"Relationships\" filters=\"{near_contact_id: options.contact_id}\"></crm-search-display-table>\n</div>\n"
}
]
}
]
]
```
## What is happening
The display renders perfectly, but in the logs it seems that the ```SELECT statement``` is incorrect. This fires just on the actual search as well.
## The Error
```
Feb. 03 09:30:22 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -2
[message] => DB Error: syntax error
[mode] => 16
[debug_info] => SELECT FROM (SELECT `a`.`near_relation` AS `near_relation:label`, `far_contact_id_1`.`display_name` AS `far_contact_id.display_name`, `RelationshipCache_Contact_far_contact_id_01`.`display_name` AS `RelationshipCache_Contact_far_contact_id_01.display_name`
FROM civicrm_relationship_cache a
LEFT JOIN `civicrm_relationship_type_en_CA` `RelationshipCache_RelationshipType_relationship_type_id_01` ON `a`.`relationship_type_id` = `RelationshipCache_RelationshipType_relationship_type_id_01`.`id`
LEFT JOIN `civicrm_contact` `RelationshipCache_Contact_far_contact_id_01` ON `a`.`far_contact_id` = `RelationshipCache_Contact_far_contact_id_01`.`id`
LEFT JOIN `civicrm_contact` `far_contact_id_1` ON `a`.`far_contact_id` = `far_contact_id_1`.`id`
WHERE (`a`.`is_active` = "1")
) `api_query` [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 'FROM (SELECT `a`.`near_relation` AS `near_relation:label`, `far_contact_id_1`...' at line 1]
[type] => DB_Error
[user_info] => SELECT FROM (SELECT `a`.`near_relation` AS `near_relation:label`, `far_contact_id_1`.`display_name` AS `far_contact_id.display_name`, `RelationshipCache_Contact_far_contact_id_01`.`display_name` AS `RelationshipCache_Contact_far_contact_id_01.display_name`
FROM civicrm_relationship_cache a
LEFT JOIN `civicrm_relationship_type_en_CA` `RelationshipCache_RelationshipType_relationship_type_id_01` ON `a`.`relationship_type_id` = `RelationshipCache_RelationshipType_relationship_type_id_01`.`id`
LEFT JOIN `civicrm_contact` `RelationshipCache_Contact_far_contact_id_01` ON `a`.`far_contact_id` = `RelationshipCache_Contact_far_contact_id_01`.`id`
LEFT JOIN `civicrm_contact` `far_contact_id_1` ON `a`.`far_contact_id` = `far_contact_id_1`.`id`
WHERE (`a`.`is_active` = "1")
) `api_query` [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 'FROM (SELECT `a`.`near_relation` AS `near_relation:label`, `far_contact_id_1`...' at line 1]
[to_string] => [db_error: message="DB Error: syntax error" code=-2 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="SELECT FROM (SELECT `a`.`near_relation` AS `near_relation:label`, `far_contact_id_1`.`display_name` AS `far_contact_id.display_name`, `RelationshipCache_Contact_far_contact_id_01`.`display_name` AS `RelationshipCache_Contact_far_contact_id_01.display_name`
FROM civicrm_relationship_cache a
LEFT JOIN `civicrm_relationship_type_en_CA` `RelationshipCache_RelationshipType_relationship_type_id_01` ON `a`.`relationship_type_id` = `RelationshipCache_RelationshipType_relationship_type_id_01`.`id`
LEFT JOIN `civicrm_contact` `RelationshipCache_Contact_far_contact_id_01` ON `a`.`far_contact_id` = `RelationshipCache_Contact_far_contact_id_01`.`id`
LEFT JOIN `civicrm_contact` `far_contact_id_1` ON `a`.`far_contact_id` = `far_contact_id_1`.`id`
WHERE (`a`.`is_active` = "1")
) `api_query` [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 'FROM (SELECT `a`.`near_relation` AS `near_relation:label`, `far_contact_id_1`...' at line 1]"]
)
```
The thing I want to point out is the ```SELECT FROM (SELECT `a`.`near_relation` ``` at the start. The Select is invalid because it's not selecting any fields. Perhaps it should be ```*```, but really I did choose ```Relationship to contact``` and ```Contact (far side)``` to be displayed in the actual table below
![Selection_003](/uploads/1e2116880e9c710671ec74425b19d41e/Selection_003.png)https://lab.civicrm.org/dev/core/-/issues/4110Can't edit Activity source, targets, assignees in FormBuilder2023-04-05T16:48:01ZnoahCan't edit Activity source, targets, assignees in FormBuilder[As reported](https://chat.civicrm.org/civicrm/pl/eprjkpg4cbrcbbj7u64qnbsohc) by @guyiac on MM:
I'm trying to use a form to edit existing activities. I can pass the existing activity id successfully with an URL, and all the information ...[As reported](https://chat.civicrm.org/civicrm/pl/eprjkpg4cbrcbbj7u64qnbsohc) by @guyiac on MM:
I'm trying to use a form to edit existing activities. I can pass the existing activity id successfully with an URL, and all the information for the activity will pre-fill into the form, ***except*** the contacts (targets, assigned to, and created by). Am I missing something? Civi 5.54.0.https://lab.civicrm.org/dev/core/-/issues/4108Missing field for state province is easily missed2023-02-02T07:52:59ZyashodhaMissing field for state province is easily missedSteps to replicate :
--------------------
- Go to main of any configured contribution pages
- Fill all the mandatory fields except postcode
- On submit, the page will have postcode field in view (no need to scroll) all the way down.
...Steps to replicate :
--------------------
- Go to main of any configured contribution pages
- Fill all the mandatory fields except postcode
- On submit, the page will have postcode field in view (no need to scroll) all the way down.
![dmaster_postcode](/uploads/66a33999f7035fd958cde632cf975f74/dmaster_postcode.png)
- Fill all the mandatory fields except state province
- On submit, the page will NOT have state province field in view (need to scroll)
![dmaster_state](/uploads/f8019eddec3cfd91bf6c5b77f0dfdd28/dmaster_state.png)
This is inconsistent and esp cumbersome when you have a lot of fields configured in profile.https://lab.civicrm.org/dev/core/-/issues/4107Disabling an extension should not remove associated permissions from the CMS2023-07-05T22:19:53ZlarsssandergreenDisabling an extension should not remove associated permissions from the CMSDisabling an extension doesn't erase any settings for the extension, except if there is an associated permission in the CMS, which is removed on disabling the extension. When you later re-enable the extension, no one has the permission w...Disabling an extension doesn't erase any settings for the extension, except if there is an associated permission in the CMS, which is removed on disabling the extension. When you later re-enable the extension, no one has the permission which is re-added. This is inconsistent with how all the other settings work and confusing for users and admins (who will wonder why they can't do what they used to be able to do). This came up for me with CDN Tax Receipts, but testing shows it seems to happen with other extensions too.
Is there any reason we couldn't just leave permissions in place on extension disable and remove them instead on uninstall?
Tested on 5.59 on D7.https://lab.civicrm.org/dev/core/-/issues/4102Custom field content in a repeating event is not copied to all/subsequent ins...2023-02-02T07:45:34ZUpperholmeCustom field content in a repeating event is not copied to all/subsequent instances of the repeated eventOverview
----------------------------------------
I have set up a series of repeating events. I also have a set of custom fields for events. If I populate to a custom field in one instance of the repeating event, and save the change I a...Overview
----------------------------------------
I have set up a series of repeating events. I also have a set of custom fields for events. If I populate to a custom field in one instance of the repeating event, and save the change I am asked if I want to cascade that change to later events in the series, to all of the events, or to none. If I choose to save the change to either all of the events in the series or to later events in the series, I expect the custom field to be populated with an identical value in all of the selected events in the series. This doesn't happen. The change is on ly saved to the specific event that I have edited.
Reproduction steps
----------------------------------------
1. Create a custom field set for events with at least one field.
2. Create an event and specify that it be repeated more than once. Save.
3. Edit one instance of the event series (not the last one in the series). Edit a selected custom field for the event. Save and choose to apply the change to either all of the events in the series, or to later events.
4. Edit a later instance of the event, and note that the change has not been applied.
Current behaviour
----------------------------------------
The change to the selected custom field in only saved to the specific instance of the event.
Expected behaviour
----------------------------------------
I expect the custom field to be populated with an identical value in all of the selected events in the series.
Environment information
----------------------------------------
CiviCRM 5.57.1
Drupal 7.94https://lab.civicrm.org/dev/core/-/issues/4101CiviCRM session management contributing to (causing?) 30s login delays with J...2023-01-30T08:32:33ZTOCM_MMatthewsCiviCRM session management contributing to (causing?) 30s login delays with JetPack and non-default themesOverview
----------------------------------------
There is more info in the CiviCRM StackExchange thread at https://civicrm.stackexchange.com/questions/42896/civicrm-plugin-causes-a-30-second-login-delay/42901#42901. And this is also pro...Overview
----------------------------------------
There is more info in the CiviCRM StackExchange thread at https://civicrm.stackexchange.com/questions/42896/civicrm-plugin-causes-a-30-second-login-delay/42901#42901. And this is also probably related to an old issue that was closed as not being a real problem, https://lab.civicrm.org/dev/wordpress/-/issues/32.
WordPress 6.x (several versions), CiviCRM several versions (including 5.57.0), JetPack (several versions, including latest), and every theme that I tried that wasn't one included with WordPress (currently using Vantage). Note that I have another WP/CiviCRM/JetPack/Vantage site that does NOT have this problem, so it could be extension or plugin related but I haven't been able to figure out what that might be given all the permutations.
But after going several rounds with JetPack engineering & support taking xdebug traces, their conclusion was the session management from CiviCRM was interfering with sessions in general, causing one of their threads to hang. Logins indirectly depended on JetPack threads, so logins hung. The workaround now is to disable the 'Dedicated Sync' thread (which JetPack has to do on their end). Causes some other minor issues or delays in the background, but at least our logins are fast now.
Reproduction steps
----------------------------------------
Wish I could tell you.
Current behaviour
----------------------------------------
Any login takes 30s before finishing. Looking at web server log (modified ssl_request to include # of seconds), the POST /wp-admin/admin-ajax.php?callback=[stuff] call was the one taking 30s. Trace files give more info, which is what JetPack engineering used.
Expected behaviour
----------------------------------------
Quick logins, which are happening now that JetPack isn't trying to keep a dedicate sync thread running. But I'd like to not have to disable features that I'm paying for in JetPack to have a usable site.
Environment information
----------------------------------------
Browser: All. Personally I've used Safari (latest versions since Oct 2022) and Chrome (latest versions since Oct 2022) on MacOS, but this affected every user.
CiviCRM, all versions since 5.54.0.
PHP: Started with 7.4.x, now on 8.0.27.
WordPress: Latest version since Oct 2022.
Database: MySQL 8.0.30
Web Server: Apache 2.4.53
OS: CentOS Stream 9
Comments
----------------------------------------
Understand that this has no easy fix, but I do want to record the fact that it does in fact have a real world impact, and if there's anything else that can be done to solve/mitigate/whatever it, I am more than happy to help get more information.https://lab.civicrm.org/dev/core/-/issues/4099Form Builder crashes trying to edit Mosaico Templates form.2023-01-30T08:31:04ZRichForm Builder crashes trying to edit Mosaico Templates form.Overview
----------------------------------------
Editing the "Mosaico Templates" form provided by the Mosaico extension causes an AngluarJS crash in Form Builder.
Reproduction steps
----------------------------------------
1. Use Civi...Overview
----------------------------------------
Editing the "Mosaico Templates" form provided by the Mosaico extension causes an AngluarJS crash in Form Builder.
Reproduction steps
----------------------------------------
1. Use Civi 5.57, mosaico ext 2.10.1665574809
1. Go to **Administer » Custom » Form Builder » Search Forms » Edit** on the `afsearchMosaicoTemplateList` one
2. Crash.
Current behaviour
----------------------------------------
Console log first error (there's lots, but I expect it's the first one that causes the others)
> Syntax Error: Token '{' invalid key at column 2 of the expression [{{ts('Configure template categories')}}] starting at [{ts('Configure template categories')}}].
Expected behaviour
----------------------------------------
Should be able to edit the form.
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 110.0b5
* __CiviCRM:__ 5.57
* __PHP:__ 7.4
* __CMS:__ D7
Comments
----------------------------------------
If I edit the .html file in question and remove the {{ }} parts then it's happy. But those {{ }} parts do work when the form is presented; just not in the editor.
I believe this is a core bug and not to do with mosaico.
https://github.com/veda-consulting-company/uk.co.vedaconsulting.mosaico/blob/9ecdf84b65640c79c73162c4659e94e56442ccea/ang/afsearchMosaicoTemplateList.aff.html#L12https://lab.civicrm.org/dev/core/-/issues/4098Feature Request: Ability to hide FormBuilder Search Forms when there are no r...2023-01-30T08:30:41ZbrienneFeature Request: Ability to hide FormBuilder Search Forms when there are no results foundOverview
----------------------------------------
By the combined powers of SearchKit and FormBuilder, you can create Search Forms and display them on the Contact Summary Page. While you can limit the type of contact on which to display ...Overview
----------------------------------------
By the combined powers of SearchKit and FormBuilder, you can create Search Forms and display them on the Contact Summary Page. While you can limit the type of contact on which to display it, i.e. Organization or Individual, it is currently not possible to hide the display when there are no results returned from the SearchKit search.
Example use-case
----------------------------------------
Creating a display block on Organizations to display the "Primary Contact". If the Organization has a primary contact, then the user would want to see that displayed in the block. If they do not have a primary contact, then a user may want to hide that display altogether.
1. Make a SearchKit search with the following criteria:
* Search for *Contacts*
* With (required) *Contact Related Contacts* if Relationship to contact = *Primary Contact of*
* Contact Type = *Organization*
1. Make a Table display for that SearchKit and configure as desired.
2. Make a Form from that display, check the *Add to Contact Summary Page* option, and select **Organization** next to the *For* label.
Current behaviour
----------------------------------------
Currently, it is not possible to hide the display block when there are no results found. Instead, you get a bright blue box on the Contact Summary Page that states "None found".
![Selection_202](/uploads/d03094d0e269f5e8529084f9e3e91ca6/Selection_202.png)
Proposed behaviour
----------------------------------------
There should a variety of options for users to configure how these blocks are displayed/not displayed when there are no options (such as the "no results options with Drupal Views).
For example, there could be a checkbox on the FormBuilder section that adds the display to the Contact Summary Page that gives the option to hide the display when there are no results. This type of checkbox could also be on the SearchKit display options.
![Selection_204](/uploads/cf167a5469addcff5093897b850b790e/Selection_204.png)
![Selection_205](/uploads/004f81cdb74c390c5568a25cfec1ec5c/Selection_205.png)
Comments
----------------------------------------
This is an unfunded feature request of suggestions for UX improvements.https://lab.civicrm.org/dev/core/-/issues/4093Searchkit: Change in place edit fields to textarea2023-01-30T08:26:02Zlevi.kSearchkit: Change in place edit fields to textareaOverview
----------------------------------------
Replace some fields in search kit to textarea
Example use-case
----------------------------------------
1. in place editing on a search display can be frustrating when dealing with more ...Overview
----------------------------------------
Replace some fields in search kit to textarea
Example use-case
----------------------------------------
1. in place editing on a search display can be frustrating when dealing with more than a few words of text
2. The main page for Search Kit also suffers from this issue in the new description field (and same goes for label field altough the label field is usually only a few words)
![image](/uploads/ab66207368f4dd446dba6a8571dc5e72/image.png)
inspired by https://lab.civicrm.org/dev/core/-/issues/3893https://lab.civicrm.org/dev/core/-/issues/4091Smart group contacts from custom search show wrong results2023-02-06T04:26:31ZyashodhaSmart group contacts from custom search show wrong resultsSteps to replicate :
--------------------
- Create a smart group from any of the custom searches
- Remove a few contacts from the smart group
- Go to _Manage Groups_, the count is correct but when you click Contacts link it shows remove...Steps to replicate :
--------------------
- Create a smart group from any of the custom searches
- Remove a few contacts from the smart group
- Go to _Manage Groups_, the count is correct but when you click Contacts link it shows removed Contacts as well.
Count (correct)
![count](/uploads/0875a1556b0aa8bcd8a619d47e22d7fa/count.png)
Contacts link (wrong)
![wrong_results](/uploads/f4d8b04b546712f5166b3424c4263fe7/wrong_results.png)
- Go to _Find Contacts_, search for the smart group - it works as expected
![smart_](/uploads/a5491f1eea0ec5474d003c8aaa70a58a/smart_.png)yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4086`processor_id` and `trxn_id` is not properly being set on recurring contribut...2023-08-08T15:16:15Zbrienne`processor_id` and `trxn_id` is not properly being set on recurring contributions with PayPal ProOverview
----------------------------------------
When a user submits a new, recurring payment on a site that uses PayPal Pro, the `processor_id` and `trxn_id` are immediately set to a long alphanumeric string on submission and these val...Overview
----------------------------------------
When a user submits a new, recurring payment on a site that uses PayPal Pro, the `processor_id` and `trxn_id` are immediately set to a long alphanumeric string on submission and these values are not getting updated with the proper format (a shorter, alphanumeric string that starts with 'I-') that is sent back from PayPal.
This causes an immense issue if the user then wants to cancel their recurring contribution because even though it may seem canceled in CiviCRM, the payment is not canceled on PayPal's side, and so the user continues to be charged. This happens because the PayPalPro IPN is no longer being properly set in the CiviCRM database, so when the request to cancel the recurring payment profile goes to PayPal, it does not have the correct `processor_id` needed to cancel it.
Reproduction steps
----------------------------------------
0. If you don't already have one, set up a PayPal Pro Sandbox account that has DPRP enabled for testing recurring payments. Add the API credentials (found in **Activity > API Access > NVP/SOAP API integration**) of this sandbox account to CivCRM as a test payment processor.
* *Fair warning, this set up process with PayPal was not that easy, so if you don't have PayPal Pro, I wouldn't recommend trying this*
1. From your PayPal Pro Sandbox account settings, go to **Notifications**, then click **Update** on **Instant payment notifications**. If your site is not publicly accessible to the internet (i.e. a local dev site for testing), then set up a [webhook.site](https://webhook.site) listening endpoint.
1. Submit a new, recurring contribution (*while not logged in on CiviCRM and using a [PayPal generated credit card for testing](https://developer.paypal.com/tools/sandbox/card-testing/)*) using the PayPal Pro payment processor.
1. On the web UI of webhook.site, take a look at the `recurring_payment_id` for the POST request that has `'recurring_payment_profile_created'` as the `'txn_type'`.
1. In CiviCRM, either with the API explorer or however you look at the data in the databases, look at the `processor_id` and `trxn_id` in the `civicrm_contribution_recur` table.
1. You will find that these strings don't match.
Current behaviour
----------------------------------------
The `processor_id` and `trxn_id` are being set to long alphanumeric strings, such as 'e13d51f14f7fff9fb6923820022ebc77' upon submission of a recurring payment on a CiviCRM installation that is using PayPal Pro. These values are stored in the `civicrm_contribution_recur` table and become problematic for updating or canceling recurring payments.
Expected behaviour
----------------------------------------
The `processor_id` and `trxn_id` should be set to (and stored as) the PayPal Pro IPN that is generated when the `'txn_type'` is `'recurring_payment_profile_created'`. The PayPal Pro IPN is an alphanumeric string that notably starts with 'I-', such as 'I-818V5WCCXF2H'
Additional Info
----------------------------------------
Some backstory - a few years ago, `processor_id` was initially set to `NULL` and was later updated with the IPN. In that scenario, the logic that CiviCRM used (in `/CRM/Core/PaymentPayPalProIPN.php`) made sense, as it checked if that value was set and returned early if it was. However, [PR #21539](https://github.com/civicrm/civicrm-core/pull/21539) added `processor_id` to parameters that get passed to the `recur()` function in PayPalProIPN.php, so the code that sets the value of `processor_id` (and `trxn_id`) to the properly formatted IPN was not being reached.
@JonGold and I currently have a PR with a fix for this in the works, but are doing further testing with a client.
Given that this issue has been going on for a while (9 months, at least), there are many recurring contributions that have a malformed `processor_id`. The PR that will be submitted also includes a check for when `'txn_type'` is `'recurring_payment'` (i.e. subsequent recurring payments) to update the `processor_id` and `trxn_id` to the proper format, if needed.https://lab.civicrm.org/dev/core/-/issues/4085SearchKit can't export more than a couple thousand rows2023-05-26T16:17:22ZJonGoldSearchKit can't export more than a couple thousand rowsOverview
----------------------------------------
When attempting to "Download Spreadsheet" in SK, it times out with more than a couple thousand rows. It's very PHP-intensive to do the pseudoconstant lookups, Smarty calculations, etc. ...Overview
----------------------------------------
When attempting to "Download Spreadsheet" in SK, it times out with more than a couple thousand rows. It's very PHP-intensive to do the pseudoconstant lookups, Smarty calculations, etc. That's not noticeable when it's calculating a page of 50, but doesn't scale.
Reproduction steps
----------------------------------------
1. Create an SK query that yields a large number of contacts. Ensure you have 2-3 pseudoconstant fields in your `SELECT`.
1. Attempt to export with "Download Spreadsheet"
Current behaviour
----------------------------------------
Times out, but appears to still be downloading.
Expected behaviour
----------------------------------------
Finishes successfully, or at least reports back to the user that the export won't finish.
Comments
----------------------------------------
Most systems that offer exports of large data sets - including our competitors like NationBuilder etc., but also many apps like PayPal - do not attempt to offer the export in real-time. They queue the export, then you visit a queue page to download the completed exports (most systems will email you when it's ready).
@eileen @totten I know you've both been working on queuing mechanisms. I can drum up some funding (maybe $750 USD? Need to check) to support this. I'm not sure if it's a heavy lift or a light one though, so I don't know if that's a substantial amount of funding.
Ideally, this would work like imports or CiviMail, where the queue job can build the export over multiple cron runs. The client who would fund this is on Pantheon, which doesn't have an unlimited cron job run time.https://lab.civicrm.org/dev/core/-/issues/4078Mass SMS with many Contacts causes slow loading of Manage Case screen for ACL...2023-01-12T10:02:37ZjhungerfordMass SMS with many Contacts causes slow loading of Manage Case screen for ACL usersOverview
----------------------------------------
The combination of Mass SMS Activities with many recipients, and ACL access to Contacts for Users who do not have "view/edit all contacts", causes very long loading times for Manage Case ...Overview
----------------------------------------
The combination of Mass SMS Activities with many recipients, and ACL access to Contacts for Users who do not have "view/edit all contacts", causes very long loading times for Manage Case screens.
Mass SMS Activities apply to Contacts, not Cases. Due to the way the `$params` are converted to `$activityParams`, the `$case_id` is never passed to the final API call. This means that non-Case Activities go through permission checks when loading the Manage Case screen. These ACL checks can take quite a long time (e.g. 30 Mass SMS Activities with 2k recipients each means 60k ACL permission checks).
Bulk Email Activities are handled differently (possibly to avoid this type of issue). Changing the Activity Type from Mass SMS to Bulk Email with an SQL query provides a workaround, but not a great solution.
Reproduction steps
----------------------------------------
1. Set up ACL access to Contacts, so a User does not have "view all contacts" or "edit all contacts", but has ACL access to view and edit (at least some) Contacts
2. Enable CiviCase
3. Create a Case for a Contact who can be accessed by the ACL user
4. Create a few (dozen) Mass SMS Activities with thousands of Contacts including the Contact from step 3
5. Log in as the ACL user from step 1
6. Load the Manage Case screen for the Case from step 3
7. Observe that it takes longer than normal
8. Set is_deleted=1 or change the Activity Type to Bulk Email for all Activities created in step 4
9. Load the Manage Case screen again, and observe that it's much faster
Current behaviour
----------------------------------------
Most of the time is spent inside the `controller->run()` call here:
https://lab.civicrm.org/dev/core/-/blob/5.57.0/CRM/Case/Page/Tab.php#L98-112
That whole block can actually be removed, and superficially the page appears to work (without the speed issues), though I haven't tested much. Just noting that it doesn't have any immediately obvious effect on the page.
Looking into why it takes so long, I think it relates to the parameters prepared by this getActivites call:
https://lab.civicrm.org/dev/core/-/blob/5.57.0/CRM/Activity/BAO/Activity.php#L579-583
At that point, `$params["caseId"]` contains an integer. However, it doesn't make it into `$activityParams`. If you observe what happens here, I think `$activityParams["case_id"]` will always contain `['IS NULL' => 1]`.
https://lab.civicrm.org/dev/core/-/blob/5.57.0/CRM/Activity/BAO/Activity.php#L2287-2291
Since `self::activityComponents()` is called without arguments, it will never contain CiviCase:
https://lab.civicrm.org/dev/core/-/blob/5.57.0/CRM/Activity/BAO/Activity.php#L851-861
The comment "In practice this means should we include CiviCase in the results" seems to imply the reverse, but stepping through `activityComponents()` in the debugger, I see:
`$compInfo["CiviCase"]->info["showActivitiesInCore"] = (bool) 0`
Even if CiviCase were included in the results though, the case ID would not make its way from `$params` into `$activityParams`:
https://lab.civicrm.org/dev/core/-/blob/5.57.0/CRM/Activity/BAO/Activity.php#L2289-2291
The end result of all of this is that the controller is checking permissions for every Activity relating to this contact, not just the ones which will be displayed on the Case. When each Activity has thousands of Contacts (as with Mass SMS), these checks become very slow.
Also, the Activities section of the Manage Case screen seems to be populated by a subsequent process. Removing this controller has no obvious effect (except reducing the loading time), raising the question of whether it's needed at all.
Expected behaviour
----------------------------------------
Mass SMS Activities with many contacts should not slow down the loading of Manage Case screens (noting that a Mass SMS cannot be applied to a Case, only to a Contact).
Environment information
----------------------------------------
* __Browser:__ Chromium Version 108.0.5359.124 (Official Build) Arch Linux (64-bit)
* __CiviCRM:__ 5.57.0
* __PHP:__ 7.4
* __CMS:__ Drupal 7.92
* __Database:__ mysql Ver 15.1 Distrib 10.5.18-MariaDB
* __Web Server:__ Apache 2.4