Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-02-20T06:21:58Zhttps://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/joomla/-/issues/45Remove sidebar (at least for Joomla 4)2023-08-27T20:55:45ZnicolRemove sidebar (at least for Joomla 4)Joomla 4 has a sidebar, which defaults open, and means the Civi sidebar squashes the important info even more…
As WordPress and Drupal Civi cope ok without this sidebar, maybe it's time to remove the sidebar from Joomla (or at least for...Joomla 4 has a sidebar, which defaults open, and means the Civi sidebar squashes the important info even more…
As WordPress and Drupal Civi cope ok without this sidebar, maybe it's time to remove the sidebar from Joomla (or at least for Joomla 4)
![image](/uploads/c5fdc516916c3d36c925976bbfc3be2c/image.png)https://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/user-interface/-/issues/50Decide upon FA icons for edit/delete/etc2023-03-20T12:55:03ZnicolDecide upon FA icons for edit/delete/etcThe theming docs for the older icon system (https://docs.civicrm.org/dev/en/latest/framework/ui/#older-icon-system) says that most are 'to be decided'…
"The following non CRM-specific icons are available:"
| Icon | Replacement |
| -----...The theming docs for the older icon system (https://docs.civicrm.org/dev/en/latest/framework/ui/#older-icon-system) says that most are 'to be decided'…
"The following non CRM-specific icons are available:"
| Icon | Replacement |
| ------ | ------ |
| edit-icon | To be decided |
| delete-icon | To be decided |
| dashboard-icon | To be decided |
| user-record-icon | To be decided |
| inform-icon | [fa-info-circle](https://fontawesome.com/v4/icon/info-circle) |
| tip-icon | To be decided |
While this older icon system is being phased out – replacing these icons from JQueryUI to Font Awesome needs agreement on which FA icons should be used. If the docs specify this then extension developers can follow the same patterns.
A suggestion for these, following from the pointers [here](https://docs.civicrm.org/dev/en/latest/framework/ui/#icon-meaning-and-consistency) which covers some but not all of these:
| Icon | Replacement |
| ------ | ------ |
| edit-icon | [fa-edit](https://fontawesome.com/v4/icon/pencil-square-o) ![image](/uploads/64cc1db651ac837363050f0bf61b89c1/image.png) |
| delete-icon | [fa-trash](https://fontawesome.com/v4/icon/trash) ![image](/uploads/d3c3871445977924db064fb660c2cef7/image.png) |
| dashboard-icon | [fa-th](https://fontawesome.com/v4/icon/th) ![image](/uploads/db14af0c25bc451e52d7970bcfec7343/image.png) or [fa-home](https://fontawesome.com/v4/icon/home) ![image](/uploads/bec90931c9df85123b51776fa5ed32d7/image.png) |
| user-record-icon | [fa-id-card](https://fontawesome.com/v4/icon/id-card) ![image](/uploads/794b9c212fd3d23ee9d7b4d3f17d037a/image.png) |
| inform-icon | [fa-info-circle](https://fontawesome.com/v4/icon/info-circle) |
| tip-icon | [fa-lightbulb-o](https://fontawesome.com/v4/icon/lightbulb-o) ![image](/uploads/f16f5de3cce1c41178211d68f2da3582/image.png) |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/drupal/-/issues/185CiviCRM public theme always the same as the CiviCRM Administrator theme2023-01-30T10:28:23ZspalmstromCiviCRM public theme always the same as the CiviCRM Administrator themeWhen running CiviCRM 5.57.1 under Drupal 9.5.2 under IIS it seems that the public theme setting is ignored; CiviCRM just uses the theme set for CiviCRM administration. To replicate got to Manage -> Appearance and select the various theme...When running CiviCRM 5.57.1 under Drupal 9.5.2 under IIS it seems that the public theme setting is ignored; CiviCRM just uses the theme set for CiviCRM administration. To replicate got to Manage -> Appearance and select the various themes. It doesn't appear to be browser related, I see the same with Edge, Chrome, Opera and Firefox. I don't know if it is IIS specific, but, of course, being theme related can't be replicated in the Demo environment.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.