CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-06-09T07:50:00Zhttps://lab.civicrm.org/dev/core/-/issues/4346Find Groups improvements2023-06-09T07:50:00ZyashodhaFind Groups improvementsThe idea is to give more insight into the parents and children of the said group. It's hard to understand the complexity of the group in the current UI esp in the scenarios where the smart groups are heavily used.
I am proposing this c...The idea is to give more insight into the parents and children of the said group. It's hard to understand the complexity of the group in the current UI esp in the scenarios where the smart groups are heavily used.
I am proposing this change which should help significantly by adding these 2 columns to the listing :
- Parent - Add parent column which shows parents count which is a url when clicked lists all parents groups
- Children - Add children column which shows children count which is a url when clicked lists all child groupsyashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4339Add hook for member userdashboard for altering results2023-06-09T07:48:14ZyashodhaAdd hook for member userdashboard for altering resultsAdd hook for member userdashboard for altering resultsAdd hook for member userdashboard for altering resultsyashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4332Error in membership status after a) changing membership type followed by b) p...2023-11-23T07:23:38ZJoeMurrayError in membership status after a) changing membership type followed by b) payment failure## Overview
Using a pay later payment when renewing a membership can lead to problems with the membership status, membership end date and membership type being changed at the time of the renewal being initiated ; these fields are update...## Overview
Using a pay later payment when renewing a membership can lead to problems with the membership status, membership end date and membership type being changed at the time of the renewal being initiated ; these fields are updated without a payment being recorded. It is possible that a payment will never be received, or its processing may fail. It is not easy to revert the data to its former state, or what it would have become through time from date of update to when the correction is attempted. For example, a renewal with a delayed payment might change the status from Grace to Current, the End Date from May 14, 2023 to May 14, 2024, and the Membership Type from General to Student.
These are very old problems dating to at least 2013 I believe.
The problem only occurs when both membership types have the same parent organization, and only for paid memberships. It occurs whether the membership period is Rolling or Fixed, and whether a membership type is being changed or not.
## Proposal
Refactor the current implementation so that a second, temporary membership is created that can store the new information without overwriting the old information until a payment is received for it. The new temporary membership would have a status of Pending. The Pending contribution would be related to the temporary rather than existing membership. When the payment is received (status=complete), the Pending membership's information is used to update the permanent membership, and the temporary membership record is deleted.
## Relevant code
In the Contribution Confirmation page postProcess call [legacyProcessMembership](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#L1623), various fields are updated before the doPayment call is processed [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#LL1702C42-L1702C51). As a result, the existing membership record is updated with selected membership type/end date/status after user submits a payment but before the code makes payment request, e.g. to a payment processor. This works if the payment went successfully.
In the case of a payment failure such as for IPN payment processors like Paypal Standard (occasionally when there is a delay on getting IPN callback or if the IPN response is not handled properly like https://lab.civicrm.org/dev/core/-/issues/1931) or for a manual Pay Later payment that isn't received, it leaves the selected membership in current/active state with a changed end date and possibly a different membership type. There is no fallback code written to revert the membership state or set it to Pending, and it isn't easy to reconstruct the data.
## New Behaviour
1. When initiating the Payment for Membership Renewal, create a new membership record and link the contribution in pending status to it. Add a new field, renewing_membership_id, to civicrm_membership to hold a reference from this 'temporary' pending membership to the existing membership that is being renewed. The existing membership record remains unchanged.
2. When the contribution status of the related contribution changes to Complete, update the original membership with the information from the temporary membership and delete the temporary membership.
Recommendation: delay the creation of activities for Membership Renewal (id=8), Change Membership Status (id=35) and Change Membership Type (id=36) until the contribution is completed.
Recommendation: create a new Activity Type, Membership Renewal Pending, to be created when the renewal request is received. In its body, provide: "ID of Membership being renewed: xx, Number of Periods: yy, Membership Type: [Label of Membership Type".
## Implementation:
1. Modify [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#L2900), CRM_Member_BAO_Membership::getContactMembership and [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#L2939).
2. Add / update new / existing unit tests on these new scenarios.EdselopezEdselopezhttps://lab.civicrm.org/dev/core/-/issues/4324Add Contribution Page settings for Review and Make Contribution button text2023-11-23T07:47:54ZlarsssandergreenAdd Contribution Page settings for Review and Make Contribution button textContribution Pages can be important to some organizations who do a lot of fundraising. It would be nice if the buttons were customizable, so they could say 'Donate', 'Give', 'Get Membership' or whatever the user might want.
Proposal: Ad...Contribution Pages can be important to some organizations who do a lot of fundraising. It would be nice if the buttons were customizable, so they could say 'Donate', 'Give', 'Get Membership' or whatever the user might want.
Proposal: Add two fields to Contribution Pages: review_button_text and submit_button_text. These settings could live on the main settings tab, underneath "Use a confirmation page?" with review_button_text hidden and shown conditionally. If these are populated, use these values, if not, fall back to the default (Contribute or Review your contribution followed by Make Contribution).https://lab.civicrm.org/dev/core/-/issues/4322Smart groups in group tab for contact too slow2023-05-31T08:18:14ZyashodhaSmart groups in group tab for contact too slowSmart groups in group tab for contact too slow. This should be optimized.Smart groups in group tab for contact too slow. This should be optimized.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4316Allow administrators to restrict which contacts will receive an email notific...2023-05-31T23:54:42Zayush_compucoAllow administrators to restrict which contacts will receive an email notification when an activity is assigned to a contactHow it works currently:
----------------------------------------
Administrators can only choose either to enable or disable sending email notifications (including a copy of the activity) when an activity is assigned to a contact OR limit...How it works currently:
----------------------------------------
Administrators can only choose either to enable or disable sending email notifications (including a copy of the activity) when an activity is assigned to a contact OR limit it to specific types of activity.
![image](/uploads/15806181b9f0204f847f4e8a8a70b817/image.png)
https://dmaster.demo.civicrm.org/civicrm/admin/setting/preferences/display?reset=1
**Improvement**
----------------------------------------
We would like to allow administrators to specify which groups of users would receive an email so that certain users can be assigned an activity, but they would not receive CiviCRM's default activity assignee email.
**Note**
----------------------------------------
Note, there is already some similar (but subtly different!) functionality on CiviCase for case activities:
![image](/uploads/7683b54741cb91ec61227f47c7eb87cc/image.png)
The above restricts **who can be selected** to be assigned an activity, whereas we are specifying **who would be sent** a notification for an activity.
**Proposed solution**
----------------------------------------
We propose adding a new functionality that allows administrators to specify which CiviCRM groups would receive an email notifications. This can be achieved by introducing a new dropdown field.
We would create 2 new settings for this under the setting for "Do not notify assignees for" <Activity types> on the Display Preferences page: https://dmaster.demo.civicrm.org/civicrm/admin/setting/preferences/display?reset=1 which states:
1. Restrict email recipients to groups
- <Select Group> (list all CiviCRM groups or smart groups)
- Multiselect
- Help: Limit which contacts will receive a CiviCRM activity notification email when an activity is assigned to them. You can select any group or smart group. Leave blank for no restriction. Note that you may still assign an activity to a contact who is not in the group, but they will not receive an email.
If the field is blank there will be no restriction. If a group is selected, emails will be restricted to only go to that group.
2. Restrict email recipients to Website Users
- Checkbox
- Help: Limit which contacts will receive a CiviCRM activity notification email to only be those who have a CMS user when an activity is assigned to them. Note that you may still assign an activity to a contact who does not have a CMS user, but they will not receive an email.
Emails will be suppressed in each case.
**Next steps**
----------------------------------------
We are prepared to submit a pull request (PR) for this feature. If the concept is approved, we will promptly submit the core PR.
Thank you.https://lab.civicrm.org/dev/core/-/issues/4308CryptoKeys - Converting CryptoException into status messages2023-06-05T14:10:29ZVangelisPCryptoKeys - Converting CryptoException into status messages### Overview
From time to time, we clone/replicate our live sites into our development servers to do some reviews/coding enhancements etc. Since the live sites are having a different key from the development site(s), whenever we try to ...### Overview
From time to time, we clone/replicate our live sites into our development servers to do some reviews/coding enhancements etc. Since the live sites are having a different key from the development site(s), whenever we try to access the path `/civicrm/admin/setting/smtp?reset=1` (and assuming that we had set the configuration to SMTP with a username & password in live), we end up with an exception error: "Failed to find key by ID or tag", leaving us unable to access the page so that we can modify or re-enter the SMTP password.
### Reproduction steps
* Configure `CIVICRM_CRED_KEYS`
* Go to `/civicrm/admin/setting/smtp?reset=1`
* Set up the mailer as SMTP and store a password
* Clone the site's database and filebase (except the `civicrm.settings.php`) into another site OR change the `CIVICRM_CRED_KEYS`
* Try to access the page `/civicrm/admin/setting/smtp?reset=1`. You will get an exception error and the page won't load.
### Expected behaviour
* Manage to get to the page `/civicrm/admin/setting/smtp?reset=1` but throw a status message that there's something wrong with the stored password.
### Proposed solution
* On `/Civi/Crypto/CryptoRegistry.php` convert the `CryptoException`s into Status messages
* On `/Civi/Crypto/CryptoToken.php` check if the variable `$key` is null or set and if not, return the `$plaintext`
This way, even if the system cannot decode/decrypt properly the key, we will still be able to return to the password page but also throw the notices to the visitor.
I'm assuming that this exact behaviour/effect fires up wherever we use the crypto functionality.
I am also aware that in order to fix this, one needs to also configure the *same* `CIVICRM_CRED_KEY` as seen in the live site.
If this makes any sense, I can provide a patch/PR.
### Environment information
* CiviCRM: 5.57
* PHP: 7.4.33
* CMS: Drupal 9.4.15https://lab.civicrm.org/dev/core/-/issues/4301FormBuilder: Allow placeholder text to be configured2023-05-24T06:34:31Zaydunsaidan.saunders@squiffle.ukFormBuilder: Allow placeholder text to be configuredIt would be nice to be able to specify placeholder text on form fields such as filters.It would be nice to be able to specify placeholder text on form fields such as filters.https://lab.civicrm.org/dev/core/-/issues/4299Send contribution receipt when contribution completed by recording payment on...2023-08-01T14:42:08ZlarsssandergreenSend contribution receipt when contribution completed by recording payment on the backendThrough discussion in this [PR](https://github.com/civicrm/civicrm-core/pull/26247), it has become clear that there is an inconsistency in which message templates are sent when completing a pending contribution with a payment, depending ...Through discussion in this [PR](https://github.com/civicrm/civicrm-core/pull/26247), it has become clear that there is an inconsistency in which message templates are sent when completing a pending contribution with a payment, depending on where the payment is recorded.
If the payment is recorded via API and the receipt has not yet been set, a contribution receipt template is sent.
If the payment is recorded via a Search Action and the receipt has not been sent, a contribution receipt template is sent.
If the payment is recorded via Record Payment in the UI, there is an option to send to send a receipt, but if selected a "Additional Payment Receipt or Refund Notification" template is sent.
I think that in the third case, for consistency, we should send a contribution receipt template as long as the contribution is now completed. The same logic works with membership receipt templates.https://lab.civicrm.org/dev/core/-/issues/4298CiviMail - throw 400 (Bad Request) rather than 500 (Server Error) if public u...2023-07-27T17:17:06ZufundoCiviMail - throw 400 (Bad Request) rather than 500 (Server Error) if public url endpoints hit with bad parametersOverview
----------------------------------------
Urls for CiviMail public endpoints like `civicrm/mailing/open` have a few required parameters, identifying the user / url etc. How should we handle if params aren't valid?
Current behavi...Overview
----------------------------------------
Urls for CiviMail public endpoints like `civicrm/mailing/open` have a few required parameters, identifying the user / url etc. How should we handle if params aren't valid?
Current behaviour
----------------------------------------
Current standard behaviour Civi-wide for missing/invalid params is a `CRM_Core_Exception`, which in turn results in a 500 server error.
Proposed behaviour
----------------------------------------
I think a 400 Bad Request error is more appropriate, for the "public" CiviMail links in particular.
Comments
----------------------------------------
It also helps with detecting and blocking spammy click behaviour, which I've seen with random permutations of parameters and things like this.5.65.0https://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.