CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-05-27T04:50:27Zhttps://lab.civicrm.org/dev/core/-/issues/4284Allow deletion of primary email2023-05-27T04:50:27ZlarsssandergreenAllow deletion of primary emailOn the Contact Summary tab, you can delete a contact's non-primary email, but you cannot delete their primary email. Seems like you should be able to delete any email, primary or not. If you delete a primary email, the next email on the ...On the Contact Summary tab, you can delete a contact's non-primary email, but you cannot delete their primary email. Seems like you should be able to delete any email, primary or not. If you delete a primary email, the next email on the list should become primary.
This is also kind of annoying if you want to add a new primary email and delete the old one, in which case you have to add the new email, make it primary, save, re-open the edit window and then delete the old primary email.https://lab.civicrm.org/dev/core/-/issues/4279Add support for loading ECMAScript Modules (ESM)2023-10-16T11:57:58ZtottenAdd support for loading ECMAScript Modules (ESM)Introduction
-------------
There was [a recent announcement](https://web.dev/import-maps-in-all-modern-browsers/) about a milestone -- all major browsers [now support](https://caniuse.com/import-maps) ECMAScript Modules (ESM) with "impo...Introduction
-------------
There was [a recent announcement](https://web.dev/import-maps-in-all-modern-browsers/) about a milestone -- all major browsers [now support](https://caniuse.com/import-maps) ECMAScript Modules (ESM) with "import-maps". Import-maps make ESM viable for complex applications (like CiviCRM) without requiring NodeJS during deployment.
The aim of this issue is to fully support ESM for JS development in CiviCRM -- by leveraging browser support for import-maps. It is broken down into a few sections:
* Part 1: Basic ESM Support
* Part 2: Import Map Support
However, because this is relatively new functionality with some risk and compatibility issues, the approach described here is an incremental phase-in -- where specific files/pages/extensions may use ESM (without requiring it for existing screens).
Background
----------
* As discussed in https://gist.github.com/totten/5c34e3885a4fe7002f990e09395b4294, one major factor in updating CiviCRM's Javascript tooling is support for ECMAScript Modules (ESM).
* ESM has increasingly become necessary for a wide of range Javascript tools and libraries.
* Originally, browsers did not support ESM. Instead, JS developers used NodeJS-based tools (such as Webpack or Rollup) to convert ESM's into basic Javascript. However, browser support for ESM has improved over the years.
* For a decent introduction to the concepts of ESM and its import-maps, see (e.g.) https://blog.logrocket.com/es-modules-in-browsers-with-import-maps/ (**Reading this #4279 will be easier if you've already been introduced to the concepts.**)
* This issue corresponds to [approach 4 in the gist](https://gist.github.com/totten/5c34e3885a4fe7002f990e09395b4294#approaches-to-linkingloading-es6-for-civicrm), except that (now) Firefox and Safari both have native support for import-maps.
Part 1. Basic ESM Support
--------------------------------
CiviCRM currently allows you to add Javascript to a page. For example:
```php
Civi::resources()->addScript('doStuff();');
Civi::resources()->addScriptFile('my_extension', 'js/foo.js');
Civi::resources()->addScriptUrl('https://example.com/bar.js');
```
generates output like:
```html
<script type="text/javascript">
doStuff();
</script>
<script type="text/javascript" src="https://example.com/path/to/my_extension/js/foo.js"></script>
<script type="text/javascript" src="https://example.com/bar.js"></script>
```
ESM documents are slightly different from regular Javascript documents -- e.g. they support the `import` and `export` keywords. Browsers require a different declaration for ESM:
```html
<script type="module">
import doStuff from './do-stuff.js';
doStuff();
</script>
<script type="module" src="https://example.com/path/to/my_extension/js/foo.js"></script>
<script type="module" src="https://example.com/bar.js"></script>
```
On the PHP side, we probably need a way to flag resources as ESMs. Perhaps:
```php
Civi::resources()->addScript('import doStuff from \'./do-stuff.js\'; doStuff();', ['esm' => TRUE]);
Civi::resources()->addScriptFile('my_extension', 'js/foo.js', ['esm' => TRUE]);
Civi::resources()->addScriptUrl('https://example.com/bar.js', ['esm' => TRUE]);
```
or
```php
Civi::resources()->addModule('import doStuff from \'./do-stuff.js\'; doStuff();');
Civi::resources()->addModuleFile('my_extension', 'js/foo.js');
Civi::resources()->addModuleUrl('https://example.com/bar.js');
```
Other considerations:
* Does it matter if or how ESM's appear in `hook_civicrm_coreResourceList`? Assuming we keep our current file-names (`*.js`), then there'd be no way to distinguish vanilla JS files from ESM files. OTOH, that hook was [deprecated circa 5.31](https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_coreResourceList/). The newer `hook_civicrm_alterBundle` should be more agreeable (e.g. allowing `$bundle->addModuleFile()`, `$bundle->filter()`, etc).
* Is it absolutely necessary to add more methods or flags to `Civi::resources()`? Hypothetically, we could do a global swap in all generated HTML (replace `<script type="text/javascript">` with `<script type="module">`). However, [there are differences of interpretation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#other_differences_between_modules_and_standard_scripts) - e.g. wrt scoping and global variables. I did a quick hack to use `type="module"` globally... and the page didn't render. Nothing's impossible, but changing all-at-once feels like a heavier lift.
Part 2. Import Map Support
-----------------------
Outputting `<script type="module">` is a prerequisite for using ESM's in Civi. However, it's not sufficient - a CiviCRM deployment is split across various folders (*what with core, core-exts, downloaded-ext's, CMS plugins, and so on*). With basic ESM's, it's tricky to reference all these folders.
By adding an import-map, we can load dependencies from all these different folders.
For example, on a site with `civicrm`, `search_kit`, and `mosaico`, you might generate an import-map that looks like this:
```html
<script type="importmap">
{
"imports": {
"civicrm/": "https://example.com/modules/civicrm/js/",
"search_kit/": "https://example.com/modules/civicrm/ext/search_kit/js/"
"mosaico/": "https://example.com/files/civicrm/ext/mosaico/js"
}
}
</script>
```
which would enable imports from those paths, as in
```javascript
import searchFoo from 'search_kit/foo.js';
import mosaicoFoo from 'mosaico/foo.js';
```
There are a few important considerations here. In no particular order...
* [Quote](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap): "Only the first import map in the document with an inline definition is processed; any additional import maps and external import maps are ignored." -- This means that the importmap will (eventually) be subject to contention among applications like CiviCRM, Drupal, WordPress, etc. We'll (eventually) need a way to integrate the import-maps from different applications.
* AFAICS, the CMS's do not currently have a standard way to handle import-maps. But it's on their radar. (Ex: [Drupal issue](https://www.drupal.org/project/drupal/issues/3331393), [WP/Gutenberg issue](https://github.com/WordPress/gutenberg/issues/36716)) We should expect that (eventually) some CMS's will define their own registry. Even when they don't, we should expect *other* CMS plugins will start adding import-maps.
* There is a _logical namespace_. We need some guideline for organizing in the logical-namespace.
* Example: Map between CiviCRM extension-names and ESM folders (as in the `search_kit` and `mosaico` items above).
* Given that every page is limited to one import-map, that means the _logical namespace_ will be shared between Civi extensions and `$open_ended_future_cms_stuff`. We should probably use a prefix.
* Should we automatically map all extensions -- or require an opt-in (e.g. `hook_civicrm_esm` or `hook_civicrm_importMaps`)? How confident are we that CiviCRM extensions should be mapped 1-to-1 with ESM's folder namespace?
* "The `src`, `async`, ... attributes must not be specified." ([source](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap)) -- The entire importmap must be outputted inline as part of the top-level HTML page; you can load an external map (`<script type="importmap" src="url">`). However, this should eventually change as [WICG's specs define define a way to move the importmap to a `src`](https://github.com/WICG/import-maps#import-map-processing).
Given the constraints and expectation of future change, this approach comes to mind:
1. Define `hook_civicrm_esmImportMap(array &$importMap)` as a way for CiviCRM (core/exts) to modify the import-map.
2. Define `mixin/esm@1.0.0`. This is our first-best-guess at how to map between extensions and ESM folders, Maybe:
```php
return function ($mixInfo) {
Civi::dispatcher()->addListner('hook_civicrm_esmImportMap', function (&$importMap) use ($mixInfo) {
$logicalPath = 'civicrm/' . $mixInfo->shortName . '/';
$physicalPath = Civi::resources()->getUrl($mixInfo->longName) . '/';
$importMap[$logicalPath] = $physicalPath;
});
}
```
3. Provide an initial implementation which fires `hook_esmImportMap` and outputs the `<script type="importmap">...</script>` in the page-header.
* However, we should expect that (in the future) UF-integrations will need to swap this -- they will instead ask CiviCRM for `$importMap` and pass that to a CMS API.
* Additionally, if this mechanism is swappable, then that should improve the prognosis for adding the [es-module-shims](https://github.com/guybedford/es-module-shims) to extend compatibility to older browsers.https://lab.civicrm.org/dev/core/-/issues/4277Add NOT CONTAINS to API & SearchKit2023-05-29T00:19:12ZlarsssandergreenAdd NOT CONTAINS to API & SearchKitAll of the other operators have a negated equivalent, but not CONTAINS. This would be useful in SearchKit if you wanted to find contacts that don't have a particular Preferred communication method or other similar queries, which currentl...All of the other operators have a negated equivalent, but not CONTAINS. This would be useful in SearchKit if you wanted to find contacts that don't have a particular Preferred communication method or other similar queries, which currently aren't possible.
Will have to update the code in [PR 26068](https://github.com/civicrm/civicrm-core/pull/26068) once this done, to allow this to be used on serialized fields in SearchKit.
I'll give this a shot unless there are objections.https://lab.civicrm.org/dev/core/-/issues/4176Allow to search on participant id2023-03-24T17:21:16ZyashodhaAllow to search on participant idOverview
---------
Allow to search on participant id.
The participant search doesn't have an option to quickly search on ID, this should fix that.
This is already available for contribution and membership search.Overview
---------
Allow to search on participant id.
The participant search doesn't have an option to quickly search on ID, this should fix that.
This is already available for contribution and membership search.5.61.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4127is_drupal: move functionality that calls this deprecated variable to System c...2023-03-03T12:22:06Zherbdoolis_drupal: move functionality that calls this deprecated variable to System classes`CRM_Utils_System::is_drupal` (and `is_wordpress`, `is_joomla`) is deprecated so need to move these to the System classes. Some of these are minor so I figure it's easier to capture a few different PRs with this issue.
1. `CRM_Custom_Fo...`CRM_Utils_System::is_drupal` (and `is_wordpress`, `is_joomla`) is deprecated so need to move these to the System classes. Some of these are minor so I figure it's easier to capture a few different PRs with this issue.
1. `CRM_Custom_Form_Group::postProcess()`
2. `CRM_Utils_System::ipAddress()`
3. `CRM_Core_Error::debug_log_message()`
4. `CRM_Core_BAO_UFMatch::synchronizeUFMatch()`
5. `CRM_UF_Page_Group::profile()`
6. `CRM_Mailing_Info::workflowEnabled()`
7. `CRM_Utils_System_Base::getCiviSourceStorage()`
8. `CRM_Dedupe_Merger::relTables()`
`$config->userFramework` has not been deprecated and might still be useful for templates and such. Should any call to `$config->userSystem->is_drupal` be replaced with the more verbose: `$config->userFramework EQ 'Drupal' || $config->userFramework EQ 'Backdrop' || $config->userFramework EQ 'Drupal8'`.https://lab.civicrm.org/dev/core/-/issues/4076Split up CRM_Utils_System_Base::theme2023-02-14T01:13:59ZherbdoolSplit up CRM_Utils_System_Base::themeSplit up this method into the different classes so it's specific per CMS.Split up this method into the different classes so it's specific per CMS.https://lab.civicrm.org/dev/core/-/issues/4074CRM_Core_BAO_CMSUser - use system specific method rather than checking userFr...2023-01-30T17:18:08ZherbdoolCRM_Core_BAO_CMSUser - use system specific method rather than checking userFrameworkIn `CRM_Core_BAO_CMSUser::formRule()` there is a bunch of logic for specific CMSes that should be in the userSystem for each CMS. This helps make CiviCRM more CMS agnostic.In `CRM_Core_BAO_CMSUser::formRule()` there is a bunch of logic for specific CMSes that should be in the userSystem for each CMS. This helps make CiviCRM more CMS agnostic.https://lab.civicrm.org/dev/core/-/issues/4016Import improvements2023-06-25T18:15:01ZeileenImport improvementsTracking issue for improvements I'd still like to look at
- import templates https://lab.civicrm.org/dev/core/-/issues/4015
Some quick notes that I haven't spun off into issues
- the links from the search go to the import landing pa...Tracking issue for improvements I'd still like to look at
- import templates https://lab.civicrm.org/dev/core/-/issues/4015
Some quick notes that I haven't spun off into issues
- the links from the search go to the import landing page - I think the search kit summary + detailed view (2 links) might be better as an and or an or to that
- ~~when looking at the detailed view the 'import' action only works on rows that are 'validated' - this makes sense in the main import as it doesn't try to import invalid rows but needs some tweaking in that workflow~~ - fixed
- ~~The label for `entity_id` is not the relevant entity in the search display - tracking progress here https://github.com/civicrm/civicrm-core/pull/25097~~ fixed
- I tried embedding a SearchDisplay into the summary/progress screen - https://github.com/civicrm/civicrm-core/pull/25087 - I got it working but the flickering was an issue. Closing the PR & tracking here to think about furtherhttps://lab.civicrm.org/dev/core/-/issues/4015Import templates2023-04-03T02:33:03ZeileenImport templatesOne hope for the import screens is that on the `DataSource` screen it would be possible to put `template_id` in the url. In this case the settings from that import would load (excluding the actual file/data/table).
I think the template_...One hope for the import screens is that on the `DataSource` screen it would be possible to put `template_id` in the url. In this case the settings from that import would load (excluding the actual file/data/table).
I think the template_id could be an import that had been used or one marked as 'is_template' (the latter would ideally be saveable and would not expire like the job ones do).5.61.0https://lab.civicrm.org/dev/core/-/issues/3980SearchKit displays: be able to add description so end user knows the context2022-11-21T19:39:52ZherbdoolSearchKit displays: be able to add description so end user knows the contextCurrently on SearchKit displays we can set the name which ends up being used for the title and the URL. I've tried to add additional information there for end users so they understand the context of the results. E.g. "Only shows results ...Currently on SearchKit displays we can set the name which ends up being used for the title and the URL. I've tried to add additional information there for end users so they understand the context of the results. E.g. "Only shows results for the current campaign". But that's awkward to stuff that all into the title. And also means one has to be careful that on the first save *not* to add those notes to the name so as to prevent an ungainly URL.
(The other option is to embed the SK into an afform, but that's a lot of extra work for just a bit of description.)
So a separate description field would be ideal.https://lab.civicrm.org/dev/core/-/issues/3973SearchKit: be able to choose *which* Actions are available on a display2023-03-02T16:50:05ZherbdoolSearchKit: be able to choose *which* Actions are available on a displayThe Actions for SearchKit displays seem to be automatically chosen based on the entities. And it's an all or nothing deal. In my case, I was hoping to allow staff to *only* download the results and nothing else. But there a bunch that sh...The Actions for SearchKit displays seem to be automatically chosen based on the entities. And it's an all or nothing deal. In my case, I was hoping to allow staff to *only* download the results and nothing else. But there a bunch that show up, including delete, update. Even if the search is using a GROUP BY, which doesn't make much sense I think.https://lab.civicrm.org/dev/core/-/issues/3944SearchKit: Show count on both top and bottom of display2022-10-27T20:47:07ZlarsssandergreenSearchKit: Show count on both top and bottom of displayCurrently, the count of results in a SearchKit display is only shown on the bottom of the page. In core, totals are usually shown at the top and bottom of the page in search results. I think it would be more usable to also show the total...Currently, the count of results in a SearchKit display is only shown on the bottom of the page. In core, totals are usually shown at the top and bottom of the page in search results. I think it would be more usable to also show the total count in SearchKit displays at the top of the page, beside the Actions drop down menu. It's a good sanity check for users to be able to see how many entities they are doing an action on before doing so - they shouldn't have to scroll to the bottom of the page and then back up to see the count. It's also not always easy to see how many are selected or if you've selected just one page of results or the whole list.
Something simple like this, which would also show NNN selected of NNN results when some are selected.
![image](/uploads/0587e86d7faed05a9ecf441a64f93378/image.png)
This could be disabled by disabling show count for the display.https://lab.civicrm.org/dev/core/-/issues/3929SearchKit feature request - filter by data segment2022-11-01T21:47:09ZJonGoldSearchKit feature request - filter by data segmentMy client has a request to be able to filter by data segments in a SK embedded in Form Builder.
My initial thought was that this would have to be done in PHP/JS and not SQL, which would have awful performance - but on further thought, I...My client has a request to be able to filter by data segments in a SK embedded in Form Builder.
My initial thought was that this would have to be done in PHP/JS and not SQL, which would have awful performance - but on further thought, I realized that data segments could be used as WHERE clauses.
If someone wants to message me on Mattermost with an estimate, I could bring it to my client.https://lab.civicrm.org/dev/core/-/issues/3839Add system check for updated clean URL settings2022-09-27T19:51:34ZelilisseckAdd system check for updated clean URL settingsOverview
----------------------------------------
Based on my experience and this conversation: https://chat.civicrm.org/civicrm/pl/56au14c7dpb5ddebj69kbfjdir
Clean URLs should be required at this point. It's not as much of a problem in...Overview
----------------------------------------
Based on my experience and this conversation: https://chat.civicrm.org/civicrm/pl/56au14c7dpb5ddebj69kbfjdir
Clean URLs should be required at this point. It's not as much of a problem in Drupal, but in Wordpress if a site has been upgraded from the old Clean URL settings in civicrm.settings.php and ?civiwp style URLs and civicrm.settings.php has not been updated manually, strange things will being to occur. This largely manifests itself as yellow "Cannot find valid value for ID" error screens that confuse users when registering for an Event or making a Contribution on user-facing forms. This message comes from a tricky session issue and setting clean URLs up has always been the fix.
Current behaviour
----------------------------------------
Clean URL settings are often not updated by unsuspecting admins as older sites are upgraded to versions of CiviCRM where they should be required.
Proposed behaviour
----------------------------------------
System check warning appears for Wordpress users if civicrm.settings.php does not include up-to-date clean URL settings.
Comments
----------------------------------------
This check could be extended to other CMS' now or in the future, which is the motivation behind using its own check class rather than modifying the existing "Cms" for Wordpress checks. I haven't seen this issue with other CMS' so far.
Any thoughts welcome! PR will be provided and linked.https://lab.civicrm.org/dev/core/-/issues/3831PHP 8.2 Deprecated ${} string interpolation2022-10-31T03:45:54ZBradley TaylorPHP 8.2 Deprecated ${} string interpolationIn PHP 8.2 (planned to be released this November) ${} string interpolation has been deprecated:
https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation
```
echo "Hello ${name}"; // Deprecated
echo "Hello {$name}"; // Suppo...In PHP 8.2 (planned to be released this November) ${} string interpolation has been deprecated:
https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation
```
echo "Hello ${name}"; // Deprecated
echo "Hello {$name}"; // Supported
```
There are not loads of places where the deprecated version is used, but there are a few. We should swap the position of the dollar to the non-deprecated version.
(I also realise CiviCRM does not fully support PHP 8.1 yet, but it doesn't hurt to start to get ahead).5.54.0Bradley TaylorBradley Taylorhttps://lab.civicrm.org/dev/core/-/issues/3823Scheduled Reminders' effective start/end date incorrectly described.2022-09-02T15:31:27ZRichScheduled Reminders' effective start/end date incorrectly described.e.g.
![image](/uploads/fc3823cd4ec6e288615934a084db52e1/image.png)
You might think from this screenshot that this reminder won't fire unless the membership end date is at least 26 Aug 2022.
But surprise!, you'd be wrong!
It actually ...e.g.
![image](/uploads/fc3823cd4ec6e288615934a084db52e1/image.png)
You might think from this screenshot that this reminder won't fire unless the membership end date is at least 26 Aug 2022.
But surprise!, you'd be wrong!
It actually won't fire until the *trigger date* is at least 26 Aug 2022, and we set the trigger date above to be 1 week before the membership end date.
Expected behaviour
----------------------------------------
Either the queries should be changed to go on the actual date, as the labels say, OR, the labels should be updated to explain this.
The first feels like poking a hornets nest. The latter is like trying to have a rational debate on twitter.
I think I'd propose:
- Change the "When" label to "When (trigger date)"
- Then in the 'effective' dates' descriptions, just put "Earliest trigger date to include".
If folks agree with my proposal I'm happy to put in a PR for this.5.54.0https://lab.civicrm.org/dev/core/-/issues/3811Allow other extensions to use Recaptcha extension for validation2022-08-22T22:01:15ZKurund JalmiAllow other extensions to use Recaptcha extension for validation5.54.0Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3783Make Recent Items available providers an option group so extensions can exten...2022-08-10T04:17:03ZherbdoolMake Recent Items available providers an option group so extensions can extend itOverview
----------------------------------------
I would like my custom entities to be available to the Recent Items block.
In `CRM_Utils_Recent::getProviders()` there's a comment to make the hard-coded list into an Open Group. I agree...Overview
----------------------------------------
I would like my custom entities to be available to the Recent Items block.
In `CRM_Utils_Recent::getProviders()` there's a comment to make the hard-coded list into an Open Group. I agree. Let's make it so.
Current behaviour
----------------------------------------
Hard-coded list of some core entities.
Proposed behaviour
----------------------------------------
Create an option group and call it from this method.5.53.0https://lab.civicrm.org/dev/core/-/issues/3768Improvement to Case Detail report2024-03-22T05:03:27ZyashodhaImprovement to Case Detail reportExpose some of the useful columns and filters :
- expose city in case detail report
- add filter for 'Activity type of the last activity'Expose some of the useful columns and filters :
- expose city in case detail report
- add filter for 'Activity type of the last activity'yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3757Users with administer_reports should be able to delete dashlets from the dash...2024-03-19T05:03:27ZandyburnsUsers with administer_reports should be able to delete dashlets from the dashboardThe current behavior I see is anyone with `administer_reports` can access the "Access" tab in a given report in CiviReport. Therefore, they can create dashlets. However, upon making a dashlet available for the dashboard, these can not be...The current behavior I see is anyone with `administer_reports` can access the "Access" tab in a given report in CiviReport. Therefore, they can create dashlets. However, upon making a dashlet available for the dashboard, these can not be removed by that same user, potentially resulting in a cluttered dashboard and user frustration.
Non-admins are missing trash can delete function:
![image](/uploads/206f154220c69227a784cc2d40e87a39/image.png)
Admin sees trash can:
![image](/uploads/21dbc1ca9cc3247a4752324df98a68b2/image.png)
Sure, interest in civireport is quite low now but this same behavior affects dashlets created from search kit.
For search kit, I would set that `administer data` or maybe `administer_reports` would be the needed permission to remove dashlets. Currently, it is not enough.