Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-10-03T21:46:14Zhttps://lab.civicrm.org/dev/core/-/issues/4457Entity Reference Custom Field not working as filter in "regular" search2023-10-03T21:46:14ZjensschuppeEntity Reference Custom Field not working as filter in "regular" searchFollow-up to #3721. @fabian_SYSTOPIA found out that filtering doesn't work correctly.
Not sure this is to be fixed, as it's related to the "old-style" searches ...
## Steps to reproduce
* Create an Entity Reference Custom Field on the...Follow-up to #3721. @fabian_SYSTOPIA found out that filtering doesn't work correctly.
Not sure this is to be fixed, as it's related to the "old-style" searches ...
## Steps to reproduce
* Create an Entity Reference Custom Field on the *Participant* entity for referencing an *Event* entity
* Edit a participant and fill out the field by selecting an event
* Use the *Find Participants* search and try to limit the search result to participants with the event previously selected in that field
* Notice that all participants are being found, not only that one with the entity reference field being filledhttps://lab.civicrm.org/dev/core/-/issues/4626Reduce calls to CRM_Utils_System::url() in mailings2023-10-05T11:45:56ZJonGoldReduce calls to CRM_Utils_System::url() in mailingsOn Drupal 8+ and possibly on other CMSes, `CRM_Utils_System::url()` takes an absurdly long time to run. Seems like `\Drupal\Core\Utility\UnroutedUrlAssembler::assemble()` is the main culprit, but even that's only part of the problem.
W...On Drupal 8+ and possibly on other CMSes, `CRM_Utils_System::url()` takes an absurdly long time to run. Seems like `\Drupal\Core\Utility\UnroutedUrlAssembler::assemble()` is the main culprit, but even that's only part of the problem.
When generating VERP URLs, we call `CRM_Utils_System::url()` 5 times per email, to generate almost-identical URLs. Simply reducing that to one call per email cut my test mail sending by just over 25%!
There are further improvements to be made, I'd love to hear folks' feedback.
* Do we even need to call `\Drupal\Core\Url::fromUri()` every time we call `CRM_Utils_System::url()`? Is there a faster way to generate URLs?
* Many email service providers (Mailjet, Sparkpost etc.) emit a webhook on bounce. What if we created a "Disable VERP" setting?JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4673Proposal: SearchKit > Enable use of Extras fields (current date) in Field Tra...2023-10-05T11:51:51ZJustin657Proposal: SearchKit > Enable use of Extras fields (current date) in Field Transformations for Date Comparisons to TodayOverview
----------------------------------------
In SearchKit users/developers should be able to use the UI to add a column that does a datediff between **today** and a selected **date field** using the Field Transformation "Days betwee...Overview
----------------------------------------
In SearchKit users/developers should be able to use the UI to add a column that does a datediff between **today** and a selected **date field** using the Field Transformation "Days between two dates".
Example use-case
----------------------------------------
1. Create a new SearchKit query (saved search)
1. Add a column: Extras > Current Date
1. Open Field Transformations
1. Select "Days between two dates" before the column "Current Date"
1. On the right of that column, select from the dropdown the desired date field to compare to today.
Current behaviour
----------------------------------------
When creating queries in SearchKit, there is currently no easy way in the UI to do a datediff between the current date (CURDATE()) and a date field stored in the database.
Current workaround
----------------------------------------
We can hack our way to doing this by manually editing the SELECT clause of the query API call like this:
`"DATEDIFF(CURDATE(), birth_date) AS DATEDIFF_today_birth_date",`
You can do this directly in the "api_params" field of the saved search.
Or you can export the saved search, edit the API call, and then import the saved search using the SearchKit Import UI.
Comments
----------------------------------------
Verified this behaviour on Civi 5.65.0
See: [StackExchange Thread: How to calculate number of days to/from a date](https://civicrm.stackexchange.com/q/45654/15346)https://lab.civicrm.org/dev/core/-/issues/4636Deleting group invalidates ACL2023-10-05T11:56:00Zaydunsaidan.saunders@squiffle.ukDeleting group invalidates ACLOverview
----------------------------------------
Groups used in ACL's can be deleted without warning resulting in invalid ACL's.
Setup
----------------------------------------
1. Create a group: TestGroup
1. Create an ACL: Role: Every...Overview
----------------------------------------
Groups used in ACL's can be deleted without warning resulting in invalid ACL's.
Setup
----------------------------------------
1. Create a group: TestGroup
1. Create an ACL: Role: Everyone, Operation: View, Type: Group, Group: TestGroup (just created)
1. Note that the ACL display will shows `Type` as 'Group' and shows the group name
1. In SQL, look at the `civicrm_acl` table and note the `object_table` is 'civicrm_group', and `object_id` is the new group id.
Now delete the TestGroup:
- There is no warning that this group is used in an ACL
- In the ACL display the group name is now blank - a situation which cannot be created through the Add or Edit ACL screens.
- In SQL, the `civicrm_acl` table still show the `object_id` as the now non-existent group id.
Prior to https://github.com/civicrm/civicrm-core/pull/27679 this causes DB Syntax Errors when calling `CRM_Contact_BAO_Contact_Permission::allow()`
Expected behaviour
----------------------------------------
Good question! Maybe a warning that the group is being used in an ACL, but what should then happen to the ACL? Disable it?
Environment information
----------------------------------------
* __CiviCRM:__ _Master but may be longstanding_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->https://lab.civicrm.org/dev/drupal/-/issues/190Links in Drupal Views are improperly URL-encoded2023-10-05T12:00:17ZresgaLinks in Drupal Views are improperly URL-encodedOriginal and open issue: [CRM-21716 Links in Drupal Views are improperly URL-encoded](https://issues.civicrm.org/jira/browse/CRM-21716).
As I read https://lab.civicrm.org/infra/ops/-/wikis/gitlab-roadmap#what-about-the-2000-open-issues-...Original and open issue: [CRM-21716 Links in Drupal Views are improperly URL-encoded](https://issues.civicrm.org/jira/browse/CRM-21716).
As I read https://lab.civicrm.org/infra/ops/-/wikis/gitlab-roadmap#what-about-the-2000-open-issues-in-jira-that-are-not-confirmed not all issues were migrated, and it looks like this one wasn't.
The updated code in the issue above works well, and URLs are properly formatted.https://lab.civicrm.org/dev/core/-/issues/4516Rethinking 20 minutes QF session timeouts2023-10-05T15:27:38ZJonGoldRethinking 20 minutes QF session timeoutsThe 20 minute timeout has been a part of Civi for as long as I can remember. It's also caused lost donations, frustrated applicants, and so on. Reading an [article about why short session timeouts aren't helpful](https://www.sjoerdlang...The 20 minute timeout has been a part of Civi for as long as I can remember. It's also caused lost donations, frustrated applicants, and so on. Reading an [article about why short session timeouts aren't helpful](https://www.sjoerdlangkemper.nl/2023/08/16/session-timeout/) made me think about this for Civi.
* What is the original reason? Is it still valid?
* If we lengthen the timeout, do we need to make special arrangements around event registration when there's a maximum number of seats available?https://lab.civicrm.org/dev/core/-/issues/3587Unable to load the recipients group when sending mailing with Civimail2023-10-05T15:41:24ZmarzastUnable to load the recipients group when sending mailing with CivimailI am running CiviCRM 5.17.4 on Wordpress 5.2.3. The problem I am facing is that I am unable to send mailing to mailing lists (defined as groups) via CiviMail.
When I try to enter the group in the Recipients box I get Loading Failed mess...I am running CiviCRM 5.17.4 on Wordpress 5.2.3. The problem I am facing is that I am unable to send mailing to mailing lists (defined as groups) via CiviMail.
When I try to enter the group in the Recipients box I get Loading Failed message and none of the available groups is loaded (see image below). The problem appears for existing and new mailings.
Interestingly when I re-use the existing mailing I can still send it to a previously used group (though I cannot change the recipient lists). The groups load normally in manage group page.
![aE8nz](/uploads/dca6a15c237cbb7612df433a31b769d5/aE8nz.png)
*Issue already reported on CiviCRM Stack Exchange: https://civicrm.stackexchange.com/questions/33070/unable-to-load-the-recipients-group-when-sending-mailing-with-civimail*https://lab.civicrm.org/dev/core/-/issues/4632Keyboard UI for SearchKit in-place editing2023-10-07T08:58:11ZnoahKeyboard UI for SearchKit in-place editingOverview
----------------------------------------
As of CiviCRM 5.66, SearchKit Displays offer "in-place editing" of some fields. The user interface requires a lot of clicking.
Current behaviour
----------------------------------------
...Overview
----------------------------------------
As of CiviCRM 5.66, SearchKit Displays offer "in-place editing" of some fields. The user interface requires a lot of clicking.
Current behaviour
----------------------------------------
To "edit in place", the user must
- click on the editable field (the *resting* version of the field turns into a *single-field mini-form*)
- click within the form control to edit the field's value; depending on the form control, the keyboard may/must be used to manipulate the value
- click a green checkmark button (the value is saved via an AJAX request and the field goes back into *resting* state) or a red "x" button (the field returns to *resting* state without any changes being applied); this step may also be accomplished using the keyboard
This process must be repeated for each editable field in every row.
Goal
----------------------------------------
Make it possible to perform edits within SearchKit Displays without any use of the mouse.
Questions
----------------------------------------
### Design
- What should the UX be, specifically? I.e. which keystrokes should map to which behaviors?
- Should multiple editing modes be available? (e.g. single-field form, single-row form, whole-result set form)?
- How can the UX be accessible to users with various abilities?
Some possible design dimensions:
| from | | to |
|----------------------|-----|---------------------------------------------------------------------|
| emphasis on display | ... | emphasis on editing |
| edit one field | ... | edit many fields fluidly (office app spreadsheet-style interface) |
| civicrm-specific ux | ... | ux paradigm borrowed from elsewhere |
| one-size-fits-all ux | ... | granular control over the ux for each column in each search display |
| hard-wired ux | ... | ux can be modified by hooks/events |
Some ideas that have already been floated:
- Tab/Shift-Tab to navigate between editable fields of the existing *single-field mini-form* style (@noah in [this PR](https://github.com/civicrm/civicrm-core/pull/27638))
- Excel-like spreadsheet UI (@civiuser in [this comment](https://github.com/civicrm/civicrm-core/pull/27638#issuecomment-1736327321))
- "Edit in place" action in the Display's "Actions" menu, which would switch on editing mode for a set of rows; save via "Save all changes" button (@civiuser in [this comment](https://github.com/civicrm/civicrm-core/pull/27638#issuecomment-1736327321))
- Replicate current "profile edit" UI ((@civiuser in [this comment](https://github.com/civicrm/civicrm-core/pull/27638#issuecomment-1736327321))
- add a new row to the table (e.g. Create a new entity) inline (@colemanw in [this chat thread](https://chat.civicrm.org/civicrm/pl/u8myu3q1g3g8jxaoajz5ya5q9w))
- (overlapping discussion) adding some minimal Aria controls to new FB/SK elements where there aren't native html elements (e.g. accordions/tabs) (@nicol in [this chat thread](https://chat.civicrm.org/civicrm/pl/17ytk6g8gbb4jk4csg56hxdjia))
### Development strategy
- What is possible to implement with the least effort/least change to current code (low-hanging fruit)?
- Should we grab that low-hanging fruit even if we haven't organized a larger UX plan?
- How big should we be thinking — i.e. should this discussion extend to FormBuilder as well?https://lab.civicrm.org/dev/user-interface/-/issues/48Swap out CiviCRM logos2023-10-07T10:15:12Zjoshjosh@civicrm.orgSwap out CiviCRM logosRequest to replace the current logos displayed in-app and in the "empowered by" display with current CiviCRM logos. Attached files match the current logo dimensions and file names.
![civi99.svg](/uploads/a78c0fe05886784ef83ad0c4ab6c05e0...Request to replace the current logos displayed in-app and in the "empowered by" display with current CiviCRM logos. Attached files match the current logo dimensions and file names.
![civi99.svg](/uploads/a78c0fe05886784ef83ad0c4ab6c05e0/civi99.svg)
![civi99](/uploads/d629d77f01db2750813f08178c264cbb/civi99.png)
![logo_words_small](/uploads/8c5a775cba670ed1854bcf86468e282c/logo_words_small.png)https://lab.civicrm.org/dev/core/-/issues/3983SearchKit: Exports should include tags2023-10-07T21:13:16ZlarsssandergreenSearchKit: Exports should include tagsMinor issue, but would make sense to also export the tags. Perhaps a complicating factor would be if the Search was imported to a site that didn't have the tag, not sure if we'd have to support adding it in that case.Minor issue, but would make sense to also export the tags. Perhaps a complicating factor would be if the Search was imported to a site that didn't have the tag, not sure if we'd have to support adding it in that case.https://lab.civicrm.org/dev/core/-/issues/3185Tags for attachments are not properly assigned to the attachment2023-10-07T21:15:50ZDaveDTags for attachments are not properly assigned to the attachmentI'm not sure if this is recent or where it's happening. What happens is that civicrm_entity_tag.entity_id is one higher than the appropriate id from civicrm_file, e.g.
civicrm_file:
| id | file_type_id | mime_type | uri ...I'm not sure if this is recent or where it's happening. What happens is that civicrm_entity_tag.entity_id is one higher than the appropriate id from civicrm_file, e.g.
civicrm_file:
| id | file_type_id | mime_type | uri |
|------|--------------|-------------------|-------------------------------------------------|
|__28__| NULL | text/plain | abc_aef1644a7b96451b6c15b7e34b862f5d.txt |
civicrm_entity_tag:
| id | entity_table | entity_id | tag_id |
|----|------------------|---------------|--------|
| 57 | civicrm_file | --> __29__ <--| 31 |
1. Create a tag set for attachments
1. Create some tags for the set
1. Create an activity
1. In the attachments section add a file and choose a tag
1. When you go back to view or edit the activity, the tag isn't displayed. Check the db and you'll see the entity_id doesn't match up.
1. Manually edit the entity_id in the db and then go back to view the activity. Now the tag is displayed.https://lab.civicrm.org/dev/core/-/issues/4454Proposal: Rename "Scheduled Reminders"2023-10-09T22:42:58ZJonGoldProposal: Rename "Scheduled Reminders"From a UX perspective, "Scheduled Reminders" is a poor name. It has uses far beyond reminders, and it's unintuitive to create a birthday email or "welcome series" of emails using a feature called "Scheduled Reminders".
I don't 100% h...From a UX perspective, "Scheduled Reminders" is a poor name. It has uses far beyond reminders, and it's unintuitive to create a birthday email or "welcome series" of emails using a feature called "Scheduled Reminders".
I don't 100% have a term decided on, though everyone loves a good bikeshed. I considered "Scheduled Messages" or "Scheduled Communications" - but I would expect a scheduled CiviMail or SMS to fall under that label (but maybe so does "Scheduled Reminders"?). "Automated Messages" overlaps with the System Messages. "Scheduled Message Rules" is better but long (if we ignore CiviRules momentarily).
Does anyone else have thoughts? I could live with "Scheduled Messages" as an improvement, but perhaps there's something better.https://lab.civicrm.org/dev/core/-/issues/3859Participant's fee amount changes when saving the associated contribution2023-10-12T20:08:01ZJonGoldParticipant's fee amount changes when saving the associated contributionWhen someone registers multiple participants for an event, saving the contribution will change the participant's `fee_amount` for the last participant.
### Replication Steps
* Create a new paid event with online registration (let's say ...When someone registers multiple participants for an event, saving the contribution will change the participant's `fee_amount` for the last participant.
### Replication Steps
* Create a new paid event with online registration (let's say tickets are $5).
* Allow registering multiple participants.
* Register for the event with at least one additional registrant (let's assume one additional person, so $10 total).
* Look at both contact's participant records - their fee amount (on the "Events" tab) will show $5.
* Click **Edit** for the contribution record on the primary registrant and then **Save** with no changes.
### Expected Result
The fee amount on both participant records remains at $5.
### Actual Result
The fee amount on the second participant records changes to $10.
### Analysis
This happens at `CRM_Contribute_Form_Contribution::submit()` [line 1580](https://github.com/civicrm/civicrm-core/blob/76fd5a1cea97f280e24604e741dafa0dad303af5/CRM/Contribute/Form/Contribution.php#L1580).
We call `CRM_Contribute_BAO_Contribution::getComponentDetails()` which claims it "Returns all contribution related object ids" but assumes that there is only one participant (and membership) record tied to a contribution. So it returns the participant ID of the last person registered, and then at line 1611-1614, resaves the participant record with the total amount of the contribution.
### Next Steps
Line 1602 claims we are "updating the line items for participants", and I understand updating the `fee_amount` if the price changes. However, lines 1610-1614 are better out than in - they're more liable to give a wrong answer than a right one. Alternatively, we can limit it to only work on single line item contributions.
The next step would be to deprecate `CRM_Contribute_BAO_Contribution::getComponentDetails($this->_id)` since it can't handle multiple membership/participant records, and replace it with a function that does. Then we can fix the code that calls the deprecated function.
I realize none of this code should be at the form layer - but that's a much larger job.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4499Undefined array key 0 when sending offline event receipt2023-10-13T01:01:38ZDaveDUndefined array key 0 when sending offline event receiptIt seems to be $lineItem[0] at https://github.com/civicrm/civicrm-core/blob/44efaf52507df2445908e02c30caef62ada0100a/CRM/Event/Form/Participant.php#L1353. It looks like it might not always be defined if editing an existing participant. B...It seems to be $lineItem[0] at https://github.com/civicrm/civicrm-core/blob/44efaf52507df2445908e02c30caef62ada0100a/CRM/Event/Form/Participant.php#L1353. It looks like it might not always be defined if editing an existing participant. But it's also confusing because it looks like sometimes it will be 0 and sometimes the array is keyed on price set id.https://lab.civicrm.org/dev/core/-/issues/2945Make CRM_Core_Smarty::singleton() use Civi::statics instead of a static var2023-10-13T05:11:14ZDaveDMake CRM_Core_Smarty::singleton() use Civi::statics instead of a static varDuring unit tests, static vars can be problematic because they don't get reset between tests. There's a point within smarty where if a test fails at that point then its secure mode doesn't get reset. It's come up a couple times and then ...During unit tests, static vars can be problematic because they don't get reset between tests. There's a point within smarty where if a test fails at that point then its secure mode doesn't get reset. It's come up a couple times and then all the tests that use smarty on certain forms fail after it. It's not easy to track down if you haven't seen it before.
There's an argument civi code should be smarty secure-mode-compliant instead, but it isn't at the moment.https://lab.civicrm.org/dev/core/-/issues/4181Custom fields on multiple entities2023-10-13T15:42:00Zaydunsaidan.saunders@squiffle.ukCustom fields on multiple entitiesOverview
----------------------------------------
Currently Custom Fields 'extend' one type of entity, possibly limited to one or more subtypes(*) of that entity.
Sometimes it would be useful to allow a set of Custom Fields to be linked...Overview
----------------------------------------
Currently Custom Fields 'extend' one type of entity, possibly limited to one or more subtypes(*) of that entity.
Sometimes it would be useful to allow a set of Custom Fields to be linked to multiple entities.
[(*) - "subtypes" in a broad sense. In the case of Contacts, the fields can be linked to sub-types. For entities like Activities, fields can be linked to say Phone Calls and Meetings which are not strictly subtypes]
Example use-case
----------------------------------------
1) Suppose we want to create custom fields for 'service providers'. Some 'service providers' are Organizations (subtype SP-O), some are Individuals (subtype SP-I).
Current options are:
- link the fields to Contacts - but the fields are only relevant to small proportion of Contacts.
- duplicate the custom fields for each subtype - need to search multiple similar fields that logically should be one.
2) Suppose we want to create a field common to multiple entities (eg 'is_validated' on Memberships, Contributions & Participants). This would require separate field sets per entity.
Current behaviour
----------------------------------------
The current model comes from a single inheritance background: this set of fields 'extends' a particular entity.
Proposed behaviour
----------------------------------------
A more flexible model is to think of a set of fields 'attached' to a selection of entities.
(Vaguely like PHP traits vs class inheritance.)
Comments
----------------------------------------
Looking for feedback on this in two main areas:
1) Is this desirable?
2) How practical is it? Custom fields are used very widely so figuring out a transition plan is key. If APIv4 can bridge the gap between the current situation and a new world then it becomes feasible. @colemanw - I know you've already done a load of work with APIv4 and Custom Fields and probably best placed to answer this bit.https://lab.civicrm.org/dev/core/-/issues/2486Apiv4 entity parity2023-10-13T21:11:08ZeileenApiv4 entity parity## Here are the entities in APIv3 & not v4
_In some cases by design - others we should maybe add..._
# Prioritised
- [ ] Attachment.php - `get` [has been added to support viewing attachments in SearchKit](https://github.com/civicrm/civ...## Here are the entities in APIv3 & not v4
_In some cases by design - others we should maybe add..._
# Prioritised
- [ ] Attachment.php - `get` [has been added to support viewing attachments in SearchKit](https://github.com/civicrm/civicrm-core/pull/27379) but `create` is still missing
- [ ] Extension.php - various install, uninstall etc functions (support for some actions already implemented)
# Partially done - lets resolve
- [ ] MembershipLog.php https://github.com/civicrm/civicrm-core/pull/21106
# Standard crud - note that doing these involves checking all pseudoconstants are correctly defined
- [ ] SmsProvider.php
- [ ] Premium.php
- [ ] RecurringEntity.php
# Mailing related - in scope
- [ ] MailingAB.php
- [ ] MailingComponent.php
- [ ] MailingContact.php
- [ ] MailingEventResubscribe.php
- [ ] MailingRecipients.php
# From here on down we are out of scope for 'entity parity'
## Order related - needed when we get to afform payment forms - out of scope for entity parity
- [ ] Order.php
- [ ] Payment.php
## Varied utils - out of scope for 'entity parity' - ad hoc
- [ ] SystemLog.php
- [ ] User.php
- [ ] Logging.php
## Migration doubtful - to be done ad hoc if we decide to
- [ ] ReportTemplate.php
- [ ] ParticipantPayment.php - likely should not be brought over
- [ ] CxnApp.php
- [ ] Cxn.php
- [ ] Profile.php
## Do not migrate
- ~~ActivityType.php (by design)~~
- ~~CustomSearch.php (by design)~~
- ~~Constant.php (by design)~~
- ~~SurveyRespondant.php(by design)~~
- ~~MembershipPayment.php (by design - use Line Item)~~
## Done
- [x] ~~AclRole.php~~ ACLEntityRole https://github.com/civicrm/civicrm-core/pull/20474
- [x] Batch.php https://github.com/civicrm/civicrm-core/pull/19931
- [x] CaseContact.php https://github.com/civicrm/civicrm-core/pull/19907
- [x] Case.php https://github.com/civicrm/civicrm-core/pull/19907
- [x] CaseType.php
- [x] ContributionProduct.php https://lab.civicrm.org/dev/core/-/issues/2683
- [x] Dedupe.php
- [x] EntityBatch.php https://lab.civicrm.org/dev/core/-/issues/2682
- [x] EntityFinancialAccount.php - https://github.com/civicrm/civicrm-core/pull/19927
- [x] EntityFinancialTrxn.php - https://github.com/civicrm/civicrm-core/pull/19932
- [x] ~~Exception.php~~ DedupeException.php https://github.com/civicrm/civicrm-core/pull/20466
- [x] File.php (part of attachment) https://github.com/civicrm/civicrm-core/pull/21158
- [x] FinancialItem.php - https://github.com/civicrm/civicrm-core/pull/20433
- [x] Job.php (crud portion)
- [x] Job.php
- [x] JobLog.php
- [x] Mailing.php - there are a bunch of related entities - see further down)
- [x] MailingEventConfirm.php
- [x] MailingEventQueue.php
- [x] MailingEventSubscribe.php
- [x] MailingEventUnsubscribe.php
- [x] MailingGroup.php
- [x] MailingJob.php
- [x] Membership.php - see https://lab.civicrm.org/dev/core/-/issues/2634 https://github.com/civicrm/civicrm-core/pull/21106
- [x] MembershipBlock.php https://github.com/civicrm/civicrm-core/pull/21106
- [x] MembershipStatus.php https://github.com/civicrm/civicrm-core/pull/21106
- [x] ParticipantStatusType.php
- [x] PaymentToken.php
- [x] Pcp.php
- [x] PrintLabel.php https://github.com/civicrm/civicrm-core/pull/21500
- [x] Product.php - since 5.41
- [x] ReportInstance.php
- [x] ~~Rule.php~~ DedupeRule.php https://github.com/civicrm/civicrm-core/pull/20466
- [x] ~~RuleGroup.php~~ DedupeRuleGroup.php https://github.com/civicrm/civicrm-core/pull/20466
- [x] Survey.php https://github.com/civicrm/civicrm-core/pull/21355
- [x] WordReplacement.php https://github.com/civicrm/civicrm-core/pull/20559https://lab.civicrm.org/dev/core/-/issues/4699MessageTemplate - Graduate new editing UI2023-10-16T09:41:00ZtottenMessageTemplate - Graduate new editing UIRe: @eileen's comment on https://github.com/civicrm/civicrm-core/pull/24981#issuecomment-1753901505
> as an aside - I was thinking about the fact there are 2 parts to the message admin - this search display & the edit form (well those a...Re: @eileen's comment on https://github.com/civicrm/civicrm-core/pull/24981#issuecomment-1753901505
> as an aside - I was thinking about the fact there are 2 parts to the message admin - this search display & the edit form (well those are the major parts).
>
> I feel like the edit form is mature enough to remove the quick form one - but where would it sit?
My first impulse was skeptical, but now I kinda see it. Let me try to talk it through:
* When we implemented the new editor (for translatable system-workflow messages), we put it in an extension (`message_admin`) for fear that it wouldn't be at par with the existing editor.
* The "Message Templates" are two things -- "user-defined templates" and "system-workflow messages". The suitability depends on how strongly you make that distinction.
* The attitude can be: "_They're both `MessageTemplate`, so they're the same thing, so they should use the same editor_" ... In that case, no, the current `message_admin` editor is not ready to handle "user-defined templates".
* The attitude can be "_They're really different things, and we should split them apart_" .... In that case, yes, I think we could basically elevate the `message_admin` editor-screen for system-workflow messages on all sites.
* In brainstorming with Coleman for #4454, I quite liked the idea of providing separate nav-links for those screens. (Add a separate link for "Admin > Communications > Workflow Messages".)
There are a few differences between the screens:
* Editing widget
* The old editor uses the `ckeditor` widget. User-defined templates lean more on prose and layout. Using a rich-text widget is more agreeable.
* The new editor uses the `monaco` widget. Workflow-message templates lean more on logic and data. Using a structured widget is more agreeable.
* Missing options
* The old editor has some "PDF" options
* The old editor has an option to upload a document (instead of editing in browser).
* Extra options
* There are various options+buttons that appear in the new workflow-message editor -- but haven't been thought-through for the user-defined stuff - e.g. "Original", "Draft", "Locale", "Activate"
IMHO, this would be the shortest path to elevating/blessing the new editor for all sites:
1. Conceptually, accept "User-defined templates" and "System-workflow messages" as different things (with different screens).
2. Setup separate links/titles for the pages
3. Examine (and possibly port) the missing options (esp PDF dropdown).
4. Move the editor to core.https://lab.civicrm.org/dev/core/-/issues/4617Running Job.update_greeting without updating customized greetings2023-10-18T08:06:00ZCharlotteRunning Job.update_greeting without updating customized greetingsOverview
----------------------------------------
For the scheduled job `update_greeting` there are two options for the parameter `force` which are explained by the [documentation](https://docs.civicrm.org/user/ca/latest/initial-set-up/...Overview
----------------------------------------
For the scheduled job `update_greeting` there are two options for the parameter `force` which are explained by the [documentation](https://docs.civicrm.org/user/ca/latest/initial-set-up/scheduled-jobs/#job_update_greeting) as follows:
- `0` only contacts with null values are updated (default)
- `1` update all contacts
There is no explanation about what happens with customized greetings when using `force = 1`.
It turns out that all customized greetings will be overridden by the standard greeting. I did not expect this.
It would be great to have another option
- `2` update all contacts excluding customized greetings
If this is not possible, then a more detailed documentation could be helpful.
This issue has also been described on [stackexchange](https://civicrm.stackexchange.com/questions/41709/running-job-update-greeting-without-updating-customized-greetings).
Work around
----------------------------------------
Use API v4 to set all greetings that are not customized greetings to NULL.
Here an example for individuals and email greeting:
```
$contacts = civicrm_api4('Contact', 'get', [
'where' => [
['email_greeting_custom', 'IS EMPTY'],
['contact_type', '=', 'Individual'],
],
'chain' => [
'name_me_0' => ['Contact', 'update', ['values' => ['id' => '$id', 'custom_greeting_display' => NULL]]],
],
]);
```
Afterwards, the greetings are not NULL but already contain the new standard greeting. There is no need to run the job `update_greeting` with `force = 0`.
Environment information
----------------------------------------
* __CiviCRM:__ 5.63.2
* __PHP:__ 8.1
* __CMS:__ Drupal 9https://lab.civicrm.org/dev/core/-/issues/3218CSV exports does not respect localization configuration2023-10-19T14:38:19ZmarcusmCSV exports does not respect localization configurationWhen creating CSV exports from searches the e. g. money or date fields are not exported with the configured localization formats.
Configure language: German, decimal separator: ",", thousands sep.: "."
The export looks like this:
```...When creating CSV exports from searches the e. g. money or date fields are not exported with the configured localization formats.
Configure language: German, decimal separator: ",", thousands sep.: "."
The export looks like this:
```
| Nettobetrag |
|-------------|
| 135.00 |
| 20.00 |
| 50.00 |
| 1,130.00 |
should be
| Nettobetrag |
|-------------|
| 135,00 |
| 20,00 |
| 50,00 |
| 1.130,00 |
```
and an example for a date field:
```
| Geburtsdatum |
|--------------|
| 1942-05-02 |
| 1983-06-01 |
should be
| Geburtsdatum |
|--------------|
| 02.05.1942 |
| 01.06.1983 |
```
The export was created with a contribution search.