CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-06-08T18:02:44Zhttps://lab.civicrm.org/dev/core/-/issues/4296FormBuilder filters suggestion: text filter as select2023-06-08T18:02:44Zaydunsaidan.saunders@squiffle.ukFormBuilder filters suggestion: text filter as selectOverview
----------------------------------------
For FormBuilder filters, it would be useful to have the option to turn `Text` into `Select`.
Example use-case
----------------------------------------
For a search return results like:
...Overview
----------------------------------------
For FormBuilder filters, it would be useful to have the option to turn `Text` into `Select`.
Example use-case
----------------------------------------
For a search return results like:
```
Org, Contact
------------
Org1, ContactA
Org1, ContactB
Org1, ContactC
Org2, ContactD
Org2, ContactE
```
you can add a filter on Org Display Name which is displayed as a text box.
It would be nice to be able to present this as a `Select` dropdown of 'Org1', 'Org2' etc (or even multi-select). The configuration for the filter provides a `Type` box with several options, so add a `Select` one to that (in addition to the existing `Text`).
The current text filter is a substring match which means that if one display name is a substring of another, you can't filter to just the shorter name. So eg 'Org1', 'Org1 - committee A', 'Org1 - committee B' you can't just show 'Org1'. Turning this into a `Select` should either exact match on the text string or convert to filtering by `id`.https://lab.civicrm.org/dev/core/-/issues/4290SearchKit: Return results faster by optimizing access check2023-05-15T08:14:11ZlarsssandergreenSearchKit: Return results faster by optimizing access checkThrough some testing, it looks like quite a bit of the execution time for SearchKit results on Compose Search, at least for relatively simple queries, is being spent checking the current user's access to edit or delete the specific entit...Through some testing, it looks like quite a bit of the execution time for SearchKit results on Compose Search, at least for relatively simple queries, is being spent checking the current user's access to edit or delete the specific entity for the View / Edit / Delete menu in the last column. It's not too bad with just 50 rows, but if you increase the page size to 100 or more, there's a pretty perceptible difference between checking the access and skipping that access check. I had a few thoughts about how we could improve this:
1. Since we aren't actually showing the links until the user clicks on the hamburger menu, we could just add the links as usual, but then check access in JS and only unhide those that the user has access to. This way we aren't doing 100 checkAccess API calls per page of 50 entities (one for update, one for delete). This would make the Compose Search page faster as well as any Displays that contain the same menu, but wouldn't help if there are links or buttons in a Display.
2. I think quite a few of the users accessing Compose Search probably have superadmin, so we could check that at the start of the process and then skip the access checks for each row.
3. Maybe it would make sense to make it possible to pass an array of ids to the checkAccess API. I don't know the details of how this works, but imagine that would speed up the process. At least for Contacts, there already is `allowList()`, so maybe this could be implemented just for Contacts without too much trouble.https://lab.civicrm.org/dev/core/-/issues/4285Changing participant status should not add an Event Registration activity2023-05-24T06:53:21ZlarsssandergreenChanging participant status should not add an Event Registration activityIf you change a participant status, for example from Registered to Attended, an activity of type Event Registration is added with subject Event Name - Role - Status. It isn't an event registration, so the activity type should probably be...If you change a participant status, for example from Registered to Attended, an activity of type Event Registration is added with subject Event Name - Role - Status. It isn't an event registration, so the activity type should probably be Change Registration, but I'm not sure we want an activity recorded at all. Is this useful or does it just make the Activities tab less useful by filling it up with unimportant details?
For comparison, we don't record an activity for a change in contribution status, but we do record an activity for a change in membership status. This seems reasonable and the change in participant status seems more like a change in contribution status.
If someone cancels through the self service / Transfer or Cancel mechanism, a separate cancellation activity is recorded (so you end up with two activities for the cancellation).
My proposal is to not record an activity on participant status change, except through the self service mechanism.
If people feel like some of those activities are useful, maybe we could only record activities for changes to or to and from cancelled and transferred status. These should be Change Registration type activities and the separate activity from the self service mechanism would have to be removed so there is no duplication.https://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/4273Allow double opt-in email (and other emails that you don't want a reply from)...2023-07-05T23:48:40ZJamie Novick - CompucoAllow double opt-in email (and other emails that you don't want a reply from) to use a user configured "mail from" address**How it works currently:**
Currently CiviCRM forces the double opt in email to an email address which is:
the words "do not reply" + the domain of the site from your default mail account configured here: https://dmaster.demo.civicrm.o...**How it works currently:**
Currently CiviCRM forces the double opt in email to an email address which is:
the words "do not reply" + the domain of the site from your default mail account configured here: https://dmaster.demo.civicrm.org/civicrm/admin/mailSettings?reset=1
https://github.com/civicrm/civicrm-core/blob/6f14847526226279076f63cc472afc18f2ce27e6/CRM/Core/BAO/Domain.php#L364
**What is the issue?**
The problem with this is that the default mail account email domain (used for bounce handling), may not be the same domain that you want to use as the from address for your double opt in emails (or for any other email that you don't want a reply from).
**Proposed solution**
We already have a place to configure the available from addresses in the system. This is the option group here: https://dmaster.demo.civicrm.org/civicrm/admin/options/from_email_address?reset=1
As such I would suggest that:
1. We create a new setting on the CiviMail component settings (https://dmaster.demo.civicrm.org/civicrm/admin/setting/preferences/mailing?reset=1) (suggest this is below "Enable Double Opt-in for Profiles which use the "Add to Group" setting":
- called "Email From Address to use where a reply is not expected".
- Field type - single select,
- Options to show from available "Email From Addresses" here: https://dmaster.demo.civicrm.org/civicrm/admin/options/from_email_address?reset=1.
- Not required
- Help: "Specify an Email From Address to use when the system sends an email but a reply is not expected, for example when a user is sent an email for a double opt-in. Leaving this blank will use the default which will be do-not-reply@default_domain where the default_domain will be the email domain address of your default mailing account also used for bounce handling. You can add additional Email From Addresses here [link to admin/options/from_email_address?reset=1].
2. If an email address is specified in the setting above it should be used instead of the current hardcoded default value.
**Next steps**
We're happy to submit a PR for this so if we can get this concept approved we will submit a core PR asap.
Thankshttps://lab.civicrm.org/dev/core/-/issues/4257Allow editing of payment method on contribution edit form when no payments ar...2023-05-30T22:23:24ZlarsssandergreenAllow editing of payment method on contribution edit form when no payments are associatedCurrently, the contribution edit form does not allow editing of the payment method for a pending contribution. This may be useful for users, for example if someone fills out a contribution page with pay later and so their contribution pa...Currently, the contribution edit form does not allow editing of the payment method for a pending contribution. This may be useful for users, for example if someone fills out a contribution page with pay later and so their contribution payment method is set to check, but they will actually pay with an etransfer and we want to note this. It is also potentially confusing because the user can mark the payment as completed and record the payment two ways, by clicking Record Payment or by changing the status to completed, but only the first of these allows the user to change the payment method.
I think we can safely allow editing of the payment method when there are no payments associated with a contribution.https://lab.civicrm.org/dev/core/-/issues/4255AdminUI breadcrumb links are confusing and unhelpful2023-05-02T07:14:25ZlarsssandergreenAdminUI breadcrumb links are confusing and unhelpfulOverview
----------------------------------------
The breadcrumb links for AdminUI pages are incorrect and confusing for users.
Current behaviour
----------------------------------------
For example for profile fields, the breadcrumb li...Overview
----------------------------------------
The breadcrumb links for AdminUI pages are incorrect and confusing for users.
Current behaviour
----------------------------------------
For example for profile fields, the breadcrumb links are:
`Home › CiviCRM › Admin › FormBuilder › Edit Form › Profile Fields`
If a user clicks the breadcrumb link for Profile Fields, they get all profile fields for all profiles, not just the profile fields for their profile. They also cannot go back to the main profiles page or the settings for the profile they are editing the fields for.
This is the same for custom fields and other AdminUI pages.
Expected behaviour
----------------------------------------
The breadcrumb links should be:
`Home › CiviCRM › Admin › Profiles › PROFILENAME › Profile Fields`
Clicking the breadcrumb links should lead to the expected pages.
Environment information
----------------------------------------
dmasterhttps://lab.civicrm.org/dev/core/-/issues/4243Support APCu with apcu_* functions2023-04-18T17:34:00ZherbdoolSupport APCu with apcu_* functionsAPC and APCu is supported according to https://docs.civicrm.org/sysadmin/en/latest/setup/cache/#config-ref but it currently only supports `apc_*` functions which are ~~backwards-compatible with~~ _not compatible_ with APC. ~~But some set...APC and APCu is supported according to https://docs.civicrm.org/sysadmin/en/latest/setup/cache/#config-ref but it currently only supports `apc_*` functions which are ~~backwards-compatible with~~ _not compatible_ with APC. ~~But some setups may only have the newer `apcu_*` functions so the class should try both functions.~~ APCu only has `apcu_*` functions, but still uses `apc.` for the configuration.
UPDATE: discovered there are some differences between the two in how they handle things, which isn't surprising. So depending on how much they differ, may require different classes.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/4133Search Kit: date field - more transformation options2023-02-20T06:26:43ZherbdoolSearch Kit: date field - more transformation optionsThis is a follow-up to https://lab.civicrm.org/dev/core/-/issues/3700, which despite it's title only dealt with aggregating by partial dates. This one is to expand the date options in the Field Transformations for date fields in SearchKi...This is a follow-up to https://lab.civicrm.org/dev/core/-/issues/3700, which despite it's title only dealt with aggregating by partial dates. This one is to expand the date options in the Field Transformations for date fields in SearchKit.
[As mentioned here](https://lab.civicrm.org/dev/core/-/issues/3700#note_80020), it would something similar to:
![Captura_de_pantalla_de_2022-08-04_18-54-00](https://lab.civicrm.org/dev/core/uploads/aca17ace20d78328c85a71a17fcfbabd/Captura_de_pantalla_de_2022-08-04_18-54-00.png)
---
Note that transforming the dates *is* possible by enabling "Rewrite Text" for a field in a display. Then doing something like:
```
{"[join_date]"|date_format:"%m/%d/%Y"}
```
Or whatever the token is for the date field.
It would be handy to have a section in the [User Guide](https://docs.civicrm.org/user/en/latest/searching/searchkit) on some of these tricks for SearchKit. Would save time from asking in the chat.https://lab.civicrm.org/dev/core/-/issues/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/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/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/4001Quick Search won't consider custom field groups2022-11-30T08:29:56Zartur.smigielskiQuick Search won't consider custom field groupsOverview
----------------------------------------
Quick search menu allow to select searchable custom fields but won't identify them by group
Reproduction steps
----------------------------------------
1. Add two groups for custom field...Overview
----------------------------------------
Quick search menu allow to select searchable custom fields but won't identify them by group
Reproduction steps
----------------------------------------
1. Add two groups for custom fields, any name, ex. group_1, group_2
2. For each of them add field with the same name "customnumber", searchable
3. Fill that field with random values for diffrent users
4. Edit quick search panel and pick one of that fields
5. Use quick search panel in menu
Current behaviour
----------------------------------------
It won't find matching records for group_1.customnumber or group_2.customnumber, it will always be the same field group_2.customnumber.
Reason: \CRM_Admin_Page_AJAX::getSearchOptions won't have info about custom field group, so it is searching only by name
```
CRM_Core_DAO::getFieldValue('CRM_Core_DAO_CustomField', substr($key, 7), 'id', 'name')
```
Expected behaviour
----------------------------------------
Search for group_1.customnumber or group_2.customnumber depending of which will be selected in quicksearch panelhttps://lab.civicrm.org/dev/core/-/issues/3990force deduplication for event registrations: misleading help text → change su...2022-11-17T07:23:57ZAndreasandreas.howiller@civiservice.deforce deduplication for event registrations: misleading help text → change suggested workaround or add feature to CiviEvent?Sometimes you want to intentionally force duplicates for anonymous registrations for certain events. Some users even want this as their default in CiviEvent.
In the profile configuration there is the following hint how you should do th...Sometimes you want to intentionally force duplicates for anonymous registrations for certain events. Some users even want this as their default in CiviEvent.
In the profile configuration there is the following hint how you should do this:
> If you are using the profile as a contact signup and editing form - this option controls what happens if the data matches an existing contact record. Using this option user can update the matching record or create a duplicate record or otherwise he will get a 'duplicate record' warning, and their input will not be saved. Contact matching is based on your configured 'Strict' rule for identifying duplicate contacts. (Weiterlesen...)
>
> This setting is ignored if the profile is embedded in an online contribution, membership signup or event registration form. In this case a contact match always results in the transaction being linked to the matching contact.
>
> In all cases, the check for an existing matching contact uses the default "Individual Strict Duplicate Matching Rule" (match on email address). If you are concerned with existing contact data being over-written by anonymous visitors, you can modify this rule to make matches less likely (or even impossible). For example, if you NEVER want anonymous input to match (i.e. always create a new contact record) - edit that rule and set the 'weight threshold' higher than 10. You will then need to run Find Duplicates periodically using a different rule, and merge any duplicate records with their associated memberships, contributions, etc.
However, this kind of "suggested workaround" no longer works because you can no longer specify an unreachable threshold in the deduplication rules. In any case, the help text would have to be adapted.
However, the question arises how to deal with the actual requirement and I see at least two possibilities:
**Option A: Replacing the workaround**
Recommend in the help text to create an unachievable deduplication rule by using in the rule a field that is never used in the user's event registrations and advice them to set this rule for registrations when needed.
**Option B: add a feature in CiviEvent**
Add a "no deduplication" feature (like there is an option to deactivate deduplication in profiles) and add this option to the duplicate rule dropdown in the event configuration.
Any (other) ideas?