CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2020-09-09T05:24:02Zhttps://lab.civicrm.org/dev/core/-/issues/531Drop support for MySQL 5.1? Maybe more?2020-09-09T05:24:02ZJonGoldDrop support for MySQL 5.1? Maybe more?While reviewing some PRs on the sysadmin docs, it came to my attention that we're currently saying we support MySQL 5.1.3+. MySQL 5.1 has been [EOL since 2013](https://www.fromdual.com/support-for-mysql-from-oracle). 5.5 went EOL at th...While reviewing some PRs on the sysadmin docs, it came to my attention that we're currently saying we support MySQL 5.1.3+. MySQL 5.1 has been [EOL since 2013](https://www.fromdual.com/support-for-mysql-from-oracle). 5.5 went EOL at the end of 2015, with extended support ending this year.
While the impetus to drop support for MySQL isn't as strong as it is for PHP, I think we should consider dropping support before someone reports an issue on an untested configuration and points to the minimum requirements in the docs.
Whether this is just a matter of updating the docs or if we want to set up a check for `MIN_MYSQL_VERSION` and `MIN_RECOMMENDED_MYSQL_VERSION` is something we can discuss. Just updating the docs might be preferable so we don't need to navigate the MySQL/MariaDB/Percona business in code. That said, we should document whether MariaDB/Percona are supported, since we've certainly seen errors particular to one or another.https://lab.civicrm.org/dev/core/-/issues/487Replace ancient menubar plugin with something responsive2023-09-19T00:35:47ZcolemanwReplace ancient menubar plugin with something responsiveThe current menubar jQuery plugin dates back to prehistoric times.
There have been some attempts to work around it with styling in Shoreditch and adding a hamburger menu for small screens with the [slicknav extension](https://github.com/...The current menubar jQuery plugin dates back to prehistoric times.
There have been some attempts to work around it with styling in Shoreditch and adding a hamburger menu for small screens with the [slicknav extension](https://github.com/aghstrategies/com.aghstrategies.slicknav) but IMO we need something better for core.
Plan o' action:
* [x] Create an extension implementing SmartMenus (thanks @ayduns!) https://github.com/aydun/uk.squiffle.kam
* [x] Migrate the [QuickSearch](https://civicrm.org/extensions/quicksearch) extension into core (see https://github.com/civicrm/civicrm-core/pull/13039).
* [x] Add `CRM.menubar` abstraction layer to provide a client-side api for adding/removing menu items, etc.
* [x] Fix click-to-open behavior (interaction is a bit confusing because the menubar opens on hover but closes on click)
* [x] Adjust icon spacing in the markup
* [x] Fix the CMS-specific placement issues (right margin for D7, admin region for Joomla)
* [x] Migrate the extension into Core.
* [ ] Consider bundling the extension into ESR (may not be possible due to core patches required).https://lab.civicrm.org/dev/core/-/issues/464Disabling "Search Primary Details Only" breaks export of primary address2023-06-16T21:12:50ZmfbDisabling "Search Primary Details Only" breaks export of primary addressMigrated from https://issues.civicrm.org/jira/browse/CRM-21423
Disabling the "Search Primary Details Only"* setting switch leads to wrong export of contact primary address.
Reason is that a requested location_type is not set and Export...Migrated from https://issues.civicrm.org/jira/browse/CRM-21423
Disabling the "Search Primary Details Only"* setting switch leads to wrong export of contact primary address.
Reason is that a requested location_type is not set and Export.php's call to CRM_Contact_BAO_Query does not set the default search to use primary location.
A fix was proposed at https://github.com/civicrm/civicrm-core/pull/11274 but has been closed as more tests would need to be written.
\* My anecdotal experience is that, if the user has been merging contacts w/ multiple email addresses such that secondary email addresses are fairly common, then there's a frequent need to search across all email addresses, so this setting does need to be disabled.https://lab.civicrm.org/dev/core/-/issues/456Improve UX of scheduling mass SMS (in progress)2018-11-29T11:38:32ZJKingsnorthImprove UX of scheduling mass SMS (in progress)As an electronic marketer I want to be able to schedule SMS mailings. However the interface can cause unexpected results.
If I leave 'send immediately' ticked, then the 'schedule sms' date is overridden, and 'now' is chosen instead. ie:...As an electronic marketer I want to be able to schedule SMS mailings. However the interface can cause unexpected results.
If I leave 'send immediately' ticked, then the 'schedule sms' date is overridden, and 'now' is chosen instead. ie:
![schedule-err-1](/uploads/f865996febcb0370503c997d293128ca/schedule-err-1.png)
![scheudle-err-2](/uploads/f1e653951c5a88cb74410b68a6242f71/scheudle-err-2.png)
This is very poor UX. As the options should be 'distinct'.
The desired solution would be to use a form the same as when scheduling an email in the, which makes this kind of error impossible. ie: usign radio buttons like the email scheduling tool does.https://lab.civicrm.org/dev/core/-/issues/450ReCaptcha submits empty value when CiviDiscount code is submitted2023-05-11T05:03:25ZtommyboboReCaptcha submits empty value when CiviDiscount code is submittedOn a contribution or event page with both ReCaptcha and CiviDiscount, when the discount code is submitted the page refreshes to an error that the ReCaptcha fails. This is very confusing to end users.
ReCaptcha should only be checked on...On a contribution or event page with both ReCaptcha and CiviDiscount, when the discount code is submitted the page refreshes to an error that the ReCaptcha fails. This is very confusing to end users.
ReCaptcha should only be checked on the final submission of the form, not on every submission/refresh of the page. At the very least there should be a message to end user that the two tools should not be live on the same page.https://lab.civicrm.org/dev/core/-/issues/4065.5.2: Import is not happy on PHP-7.2 (Countable)2019-01-08T02:47:10ZDmitry Smirnov5.5.2: Import is not happy on PHP-7.2 (Countable)~~~~
2018/09/25 18:15:04 [error] 33#33: *451 FastCGI sent in stderr: "PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 375
P...~~~~
2018/09/25 18:15:04 [error] 33#33: *451 FastCGI sent in stderr: "PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 375
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 387
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 396
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 408
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 417
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 426
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 435
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 444
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 455
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 464
PHP message: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /usr/share/civicrm/CRM/Contact/Import/Parser.php on line 476" while reading response header from upstream, client: 192.168.0.2, server: civicrm.local, request: "POST /wp-admin/admin.php?page=CiviCRM&q=civicrm/impor
~~~~5.8https://lab.civicrm.org/dev/core/-/issues/378Add a configuration setting for when to load custom CSS2020-01-28T02:57:05ZjensschuppeAdd a configuration setting for when to load custom CSSWhen debugging a [Shoreditch issue](https://github.com/civicrm/org.civicrm.shoreditch/issues/136) with overridden fonts, we began to wonder why CiviCRM's core and custom styles are being added to every page (at least whenever `civicrm_in...When debugging a [Shoreditch issue](https://github.com/civicrm/org.civicrm.shoreditch/issues/136) with overridden fonts, we began to wonder why CiviCRM's core and custom styles are being added to every page (at least whenever `civicrm_initialize()` gets called), instead of only on CiviCRM pages. A generic switch for that turned out to be non-trivial, as sometimes we do want CiviCRM styles on non-CiviCRM pages (e.g. when using profiles), sometimes we want them on public CiviCRM pages, and sometimes we don't.
This led to a POC for a configuration setting for when to load CiviCRM's custom CSS (in that special case Shoreditch's CSS), allowing administrators to choose between
- "always" (current and default behavior)
- "all CiviCRM pages"
- "all CiviCRM pages except public CiviCRM pages".
Simply adding all styles on every page may be useless on sites with more functionality than just CiviCRM. With shoreditch, that behaviour is just prone to destroying your CMS theme styles.
Patch: [customCSSMode.patch](/uploads/e66373a42af4e7f8f529e0dd18ab63bd/customCSSMode.patch)
Any thoughts?https://lab.civicrm.org/dev/core/-/issues/366Showing Line Items for Contributions with Default Price Sets2022-08-28T05:03:35ZCamilo RodrÃguezShowing Line Items for Contributions with Default Price Sets## Overview
In scenarios like data migration, multiple membership lines might be added to a contribution via the default priceset. The current mechanism prevents these lines from being shown when looking at a contributions detail view (C...## Overview
In scenarios like data migration, multiple membership lines might be added to a contribution via the default priceset. The current mechanism prevents these lines from being shown when looking at a contributions detail view (CRM_Contribute_Form_ContributionView). It makes sense that quick config priceset do not show up in the priceset configuration pages but there are more cons than pros to not show the lines on the actual contributions.
## How it Works Currently
To decide if line items should be shown for the contribution, line items are fetched, ordered by their price field's weight. Then, the price set for the first line item is checked. If the price set's `quick_config` flag is set, then the line items are NOT shown. If the falg is NOT set, the list of line items is shown.
## How it Should Work
List of line items should always be shown, especially if there is more than one of them, even if they're added using the default price set. Not sure what the logic is behind having the list of line items depend on the price set, but it could be better to have the contribution say if it should be shown with line items or not, by adding a new flag, `show_line_items` to the Contribution entity.guanhuanguanhuanhttps://lab.civicrm.org/dev/core/-/issues/311Upgrading multilingual site causes DB Error2018-10-22T19:13:55ZDon WijesooriyaUpgrading multilingual site causes DB ErrorUpgrading from CiviCRM 4.4.7 to 5.4.0 (Drupal), cause a DB error. Upgrade process works fine but when loading any civi page, JavaScript error is displayed on the language file (backtrace displayed after enabling).
![javascript](/upload...Upgrading from CiviCRM 4.4.7 to 5.4.0 (Drupal), cause a DB error. Upgrade process works fine but when loading any civi page, JavaScript error is displayed on the language file (backtrace displayed after enabling).
![javascript](/uploads/cc865f9f1870d12a4b79309623de8147/javascript.PNG)
Checking the error log, few fields relating to uf_group are not getting created during the upgrade.
![errorlog](/uploads/8424555a1c8f657bbab2d6f05d5f4c08/errorlog.PNG)
Further investigation showed that in CRM/Core/I18n, there have been schema changes between the latest SchemaStructure.php and SchemaStructure_4_7_alpha1.php thus we had to copy and rename the file as SchemaStructure_5_4_alpha1.php as mentioned [here.](https://docs.civicrm.org/dev/en/latest/translation/database/#localised-fields-schema-changes)
![schemastructure](/uploads/c05dd2b1213cad872366dc0b5f9a43be/schemastructure.PNG)5.6https://lab.civicrm.org/dev/core/-/issues/236MCrypt extension is abandonware and dependency on it should be removed2022-06-11T16:02:31ZAgilewareMCrypt extension is abandonware and dependency on it should be removedPer the deprecation notes for PHP7.1 - http://php.net/manual/en/migration71.deprecated.php, The MCrypt extension has not been maintained for a long time, and is actually removed from the core distribution to PECL in 7.2.
Apart from inst...Per the deprecation notes for PHP7.1 - http://php.net/manual/en/migration71.deprecated.php, The MCrypt extension has not been maintained for a long time, and is actually removed from the core distribution to PECL in 7.2.
Apart from installing PECL packages not being achievable in many hosting environments, use of an abandonware encryption extension is not great from a confidence perspective. Parts of the system that are currently dependent on MCrypt ought to be retooled to use OpenSSL functions, per the PHP project's recommendations.https://lab.civicrm.org/dev/core/-/issues/115Proposal - create fields array standard & generic field template/s for it & f...2022-10-11T15:26:36ZeileenProposal - create fields array standard & generic field template/s for it & for fields, work towards generic entity form templateWe have a generalised issue where we want people to write extensions to alter CiviCRM but in many cases the way CiviCRM is structured makes that difficult and unmaintainable. As part of pushing people out to extensions we also need to wo...We have a generalised issue where we want people to write extensions to alter CiviCRM but in many cases the way CiviCRM is structured makes that difficult and unmaintainable. As part of pushing people out to extensions we also need to work to improve core code to support that purpose.
In the 5.x series we have made it easier for extension writers to store entity specific data by extending custom fields to (almost) all entities via the api*. However, it is still very difficult for extension writers to inject these fields, or other fields, into forms or to remove or re-order them. In general our approach has been to make things more metadata driven but we have not really standardised how to do this for templates. Conversely we already have examples in our code of templates that have been re-written to support output being modified by a php hook - (notably it is possible to alter the Billing fields on the payment form & the output columns in the contribution search from a php hook because metadata is assigned to the template & processed in the template) but we have not standardised those approaches into a recommendation.
To be clear - this proposal is NOT about going through all our forms and altering them to be more editable - it's about agreeing what we are working towards when we ARE editing forms. Currently it is possible to say
* "we are working towards replacing jcalendar.tpl with datepicker fields and when we touch date fields we should attempt to convert them"
* "we are working towards replacing non-metadata ways of adding fields to a form with addField and when we touch fields not added that way we should attempt to convert them"
Conversely we would say "if you are trying to fix the way a datefield is handling date defaults and the field is a jcalendar field we expect the fix to be converting it to a datepicker field rather than adding extra mangling for the legacy method".
In this case we would say
* "we are working towards assigning a standardised array of fields to a form & a tpl way of handling them and when we are working on a form we should seek to convert them"
(Generally we do require that PRs are improving the consistency & quality of our codebase & compliance with code-directions when we merge them)
I would note that complex forms like Contribution & Event forms might make poor candidates for tpl standardisation but a lot of our forms are simple settings forms or editing basic entities and these are good candidates for being generic & standardised. (This is allied with fixing the forms such that IF custom data is enabled on the entity THEN it can be altered via the form - which I will cover separately)
There are 2 open PRs which revolve around making tpls more generic, more metadata driven & more form-alterable
https://github.com/civicrm/civicrm-core/pull/12128/files#diff-1f76de158e02dfb7afa76303ef60e9ebR27
and https://github.com/civicrm/civicrm-core/pull/12078
The proposal would be that where it is possible to iterate through fields we assign them to the tpl in an array that looks like
```
$this-assign('entityFields', [
'field_1' => [
'name' => 'field_1',
'description' => ts("description to show below field"),
'help' => ['id' => 'id-field_1, 'file' => 'CRM/Contact/Form/Contact',
'is_add_translate_dialog' => 1,
],
'field_1' => ['name' => 'field_1'],
'money_field' => ['name' => 'money', 'formatter' => 'crmMoney'],
'weird_looking_field' => [
'name' => 'weird_looking_field',
'template' => CRM/Member/Form/MembershipType/weird_looking_field.tpl',
```
In practice some helpers would be involved in building the array so that fields like is_add_translate_dialog are derived from existing metadata. That would also potentially apply to keys like description, help & formatter. It is expected that if a field were to use a field specific template it would be under the path of the form.
The form template would then work towards looking more like
```
{foreach from=$entityFields item=fieldSpec}
{assign var=fieldName value=$fieldSpec.name}
<tr class="crm-{$entityInClassFormat}-form-block-{$fieldName}">
{include file="CRM/Core/Form/Field.tpl"}
</tr>
{/foreach}
```
With the tpl being
```
{if $fieldSpec.template}
{include file=$fieldSpec.template}
{else}
<td class="label">{$form.$fieldName.label}
{if $fieldSpec.help}{assign var=help value=$fieldSpec.help}{capture assign=helpFile}{if $fieldSpec.help}
{$fieldSpec.help}
{else}''{/if}
{/capture}{help id=$help.id file=$help.file}{/if}
{if $action == 2 && $fieldSpec.is_add_translate_dialog}{include file='CRM/Core/I18n/Dialog.tpl' table=$entityTable field=$fieldName id=$entityID}{/if}
</td>
<td>{if $form.$fieldName.html}{if $fieldSpec.formatter === 'crmMoney'}{$form.$fieldName.html|crmMoney}{else}{$form.$fieldName.html}{/if}{else}{$fieldSpec.place_holder}{/if}<br />
{if $fieldSpec.description}<span class="description">{$fieldSpec.description}</span>{/if}
</td>
{/if}
```
In some cases it might be too hard to make the form iterate through an array but individual fields could be converted - either in order to make that field hook alterable - (ie. the hook could then change the description metadata, or suppress a field) or as part of chipping away at the conversion
```
{assign var=fieldName value='my_converted_field'}
<tr class="crm-{$entityInClassFormat}-form-block-{$fieldName}">
{include file="CRM/Core/Form/Field.tpl"}
</tr>
```
* Note to enable custom data for a new type in an extension use code like the following
```
$optionValues = civicrm_api3('OptionValue', 'get', [
'option_group_id' => 'cg_extend_objects',
'name' => 'civicrm_relationship_type'
]);
if (!$optionValues['count']) {
civicrm_api3('OptionValue', 'create', [
'option_group_id' => 'cg_extend_objects',
'name' => 'civicrm_relationship_type',
'label' => ts('Relationship Type'),
'value' => 'RelationshipType',
]);
}
```https://lab.civicrm.org/dev/core/-/issues/39Feature: Price set expire on/active on dates relative to event2023-12-14T05:03:25ZjiryuFeature: Price set expire on/active on dates relative to eventMigrated from https://issues.civicrm.org/jira/browse/CRM-21860
I reuse one price set for many similar events throughout the year; for each event, people can register early and get a discount, or register closer to the event's start date...Migrated from https://issues.civicrm.org/jira/browse/CRM-21860
I reuse one price set for many similar events throughout the year; for each event, people can register early and get a discount, or register closer to the event's start date at full price. A price set's active/expire dates works for this, but because they are absolute dates this prevents the price set from being reused for events with different start dates.
I propose active/expire dates for a price set that are relative to the event start date.https://lab.civicrm.org/dev/core/-/issues/4923Possible performance improvement: When a custom field is disabled, automatica...2024-02-08T14:11:58ZDaveDPossible performance improvement: When a custom field is disabled, automatically uncheck the searchable box and remove the db indexSuppose you have about 20 fields in the custom group and they were almost all searchable (had the searchable box checked). Over time let's say half get disabled. The indexes are still in the db, and the searchable checkbox is meaningless...Suppose you have about 20 fields in the custom group and they were almost all searchable (had the searchable box checked). Over time let's say half get disabled. The indexes are still in the db, and the searchable checkbox is meaningless because they don't appear anywhere anyway.
If the table is large, those indexes potentially cause trouble with no benefit.
If you go to re-enable, it's true it won't automatically re-check the searchable box and recreate the index, but there's no real harm, you just go back in and check the box.
An alternative to automatically doing this would be a status check: "The following fields are disabled but marked searchable. Consider making them unsearchable to improve performance on large databases."https://lab.civicrm.org/dev/core/-/issues/4895Can't delete unused financial types2024-01-15T11:38:54ZJonGoldCan't delete unused financial typesOverview
----------------------------------------
Not a regression!
Financial types associated with quick config price sets can never be deleted.
Reproduction steps
----------------------------------------
1. Create a new financial typ...Overview
----------------------------------------
Not a regression!
Financial types associated with quick config price sets can never be deleted.
Reproduction steps
----------------------------------------
1. Create a new financial type.
1. Create a new event.
1. Select the financial type as the default for the event and save.
1. Delete the event.
1. Delete the financial type.
Current behaviour
----------------------------------------
Obtuse error.
```
The following tables have an entry for this financial type: CRM_Price_DAO_PriceSet, CRM_Price_DAO_PriceFieldValue
```
Expected behaviour
----------------------------------------
Financial type should be deletable.
When the warning `Deleting this event will also delete associated Event Registration Page and Event Fee configurations. This action cannot be undone. Do you want to continue?` appears - continuing should delete the price set if it's a quick-config. But since I hope quick config dies a painful death, let's generalize to "deleting an event
Comments
----------------------------------------
Tangentially - you can't delete a price set that has any payments associated with it. This should be doable IMO and I believe is an artifact of pre-CiviAccounts (Civi 4.3) behavior when line items didn't exist.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/4744Proposal - remove 'record contribution' from back office participant form whe...2023-11-02T15:27:49ZeileenProposal - remove 'record contribution' from back office participant form where pending contribution existsIf a participant record is updated where a pending record exists you need to update the status from pending to completed
![image](/uploads/1450500ef919017c7eee5c9ef326de6c/image.png)
![image](/uploads/87bc885b56fd756e897dc416a47eccd9/...If a participant record is updated where a pending record exists you need to update the status from pending to completed
![image](/uploads/1450500ef919017c7eee5c9ef326de6c/image.png)
![image](/uploads/87bc885b56fd756e897dc416a47eccd9/image.png)
However - this ONLY updates the contribution - without a separate action to update the participant status the participant status is unchanged
This is wildly confusing.
I propose we don't show 'record contribution' section when there is an existing payment & instead offer an 'add payment' button that pops up the Add payment form if clicked...https://lab.civicrm.org/dev/core/-/issues/4470Allow disabling household contact type2023-08-04T03:59:56ZlarsssandergreenAllow disabling household contact typeCurrent proposal:
Make it possible to disable household contact type.
Initial: These cannot be disabled. It would be nice to be able to disable them, especially households as many orgs do not use them. I know Spark has households disab...Current proposal:
Make it possible to disable household contact type.
Initial: These cannot be disabled. It would be nice to be able to disable them, especially households as many orgs do not use them. I know Spark has households disabled, so at least disabling households shouldn't break anything. Organizations might be different though and less important to allow disabling. Maybe worth trying to allow disabling households first and then see.https://lab.civicrm.org/dev/core/-/issues/4401SearchKit - Report replacement - as a standard user without edit searchkit pe...2023-07-06T06:37:04ZsamuelsovSearchKit - Report replacement - as a standard user without edit searchkit permission, add a way to show/hide columns in table displayThere is already an [extension](https://lab.civicrm.org/extensions/search_kit_reports) that recreate the queries of core reports into SearchKit so admin/super user can customize and use them instead of report.
However, as a standard use...There is already an [extension](https://lab.civicrm.org/extensions/search_kit_reports) that recreate the queries of core reports into SearchKit so admin/super user can customize and use them instead of report.
However, as a standard user, edit a Searchkit is too complicated and reports is still the better option if we need to provide a lot of flexibility to users.
Currently, in Reports, standard user have access to customize :
- Columns - no way to do this in SK without editing the SK - hence the proposal
- Sorting - already there by clicking on the columns of the SK table
- Filters - already there by configuring them with FormBuilder
- Title and Format - don't think it is required
- Email delivery - missing, already documented in https://lab.civicrm.org/dev/core/-/issues/3478
So I think the main undocumented missing feature if we want to replace the reports is to have a way for a standard user to choose which columns to show/hide in a table display. It needs to apply to the screen and to the Download action.
As an example, I like the way new reports in Quickbooks works with the ability to switch each column on/off and as a bonus allow to change columns order :
![Rapport](/uploads/550ef9e7d7ffd1f19849b4034faa7765/Rapport.png)
As a first step, I don't think we need to save the user preferences but we will probably want to be able to do that / reset to default eventually.https://lab.civicrm.org/dev/core/-/issues/4328Double opt-in requires traditional bounce handling to be enabled2023-06-28T06:55:29ZJonGoldDouble opt-in requires traditional bounce handling to be enabledOverview
----------------------------------------
The default double opt-in email says:
> You have a pending subscription to the {subscribe.group} mailing list. To confirm this subscription, reply to this email or click <a href="{subscri...Overview
----------------------------------------
The default double opt-in email says:
> You have a pending subscription to the {subscribe.group} mailing list. To confirm this subscription, reply to this email or click <a href="{subscribe.url}">here</a>.
However, "reply to this email" requires traditional bounce handling (with a bounce mailbox) to be set up. In this day and age that's less common compared to using a third party mailer that sends bounce notifications via API (to [Airmail](https://civicrm.org/extensions/airmail) or one of its many cousins).
Moreover, it's a usability issue to put "here" as the clickable text. It should be more like: "Please click here to <a href="{subscribe.url}">confirm your subscription.</a>.
I want to get concept approval - and also guidance on whether we should update existing templates or just new installs. Personally I think we should update any non-customized template.https://lab.civicrm.org/dev/core/-/issues/4169Let "Number" and "Money"-type custom fields be nullable2023-03-13T07:39:11ZnoahLet "Number" and "Money"-type custom fields be nullableOverview
----------------------------------------
There are many times when NULL would be a meaningful/useful value in a custom field of type "Number" (float) or "Money" (decimal). However, it is not currently possible, via the form laye...Overview
----------------------------------------
There are many times when NULL would be a meaningful/useful value in a custom field of type "Number" (float) or "Money" (decimal). However, it is not currently possible, via the form layer, to set these fields to NULL. Blank values are currently turned into zero.
Example use-case
----------------------------------------
Let's say we need to track the elevation (meters above or below sea level) of the addresses in our database.
1. Create a custom field "Geographic Elevation" of type "Number", extending the Address entity. Leave the "Default value" blank.
1. Go to a contact and edit one of their addresses, or create a new one.
1. On the create/edit form, leave the "Geographic Elevation" field blank -- because let's say we don't know the elevation at this address.
1. Submit the form and view the saved value.
Current behaviour
----------------------------------------
"Geographic Elevation" is set to zero. That means sea level. But that's not correct -- we actually don't know the elevation.
Proposed behaviour
----------------------------------------
When the field submitted with a blank value (empty string), the database field should be set to NULL, and displayed as blank.
Comments
----------------------------------------
NULL is also a meaningful value for Money fields. Say we have a field on individuals called "Net Worth". Zero (the person is destitute) and NULL (we don't know how much money they have) are quite different.
It _is_ possible to set the field to NULL through the API, but only by passing the string 'null' (due to a PEAR DB limitation).
<details><summary>Show API example</summary>
````php
// NULL will be saved as 0
Civi\Api4\Address::update()
->addValue('Geography.Elevation', NULL)
->addWhere('id', '=', 27)
->execute();
$address = Civi\Api4\Address::get()
->addSelect('Geography.Elevation')
->addWhere('id', '=', 27)
->execute()->single();
// [
// 'id' => 27,
// 'Geography.Elevation' => 0,
// ]
// but 'null' will be saved as NULL
Civi\Api4\Address::update()
->addValue('Geography.Elevation', 'null')
->addWhere('id', '=', 27)
->execute();
$address = Civi\Api4\Address::get()
->addSelect('Geography.Elevation')
->addWhere('id', '=', 27)
->execute()->single();
// [
// 'id' => 27,
// 'Geography.Elevation' => null,
// ]
````
</details>