CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-10-20T07:52:02Zhttps://lab.civicrm.org/dev/core/-/issues/4701Hidden fields do their job too well2023-10-20T07:52:02ZJonGoldHidden fields do their job too well"Hidden" fields are meant to be hidden on profiles, and hidden (but showable) by default on FormBuilder.
It turns out they're hidden on all QuickForm pages. :eye: :mag_right:
Attached are two screenshots of a contribution with a hidden..."Hidden" fields are meant to be hidden on profiles, and hidden (but showable) by default on FormBuilder.
It turns out they're hidden on all QuickForm pages. :eye: :mag_right:
Attached are two screenshots of a contribution with a hidden custom field "Outreach Method", which has a value of "email". Please ignore the other custom fields - I didn't make this db :rolling_eyes:
Now in the longer term we can assume these pages will be replaced by FB and it will be a moot point, but for now, it seems like the correct behavior for hidden fields should be "visible on the back end". There are certainly instances where that wouldn't be desirable, but for now I think we need to accommodate the most common use case. Which this will be until we remove the unfortunate overlap with "reserved" custom fields.
![Selection_2050](/uploads/460114d6d1e110685b27f06a595a90cf/Selection_2050.png)
![Selection_2051](/uploads/31e8e7ba5e89e136030a7b476d306863/Selection_2051.png)https://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/4698Editing a contribution does not consider all related line items.2023-10-20T07:50:26ZjitendraEditing a contribution does not consider all related line items.Original issue raised on webform_civicrm project - https://www.drupal.org/project/webform_civicrm/issues/3390363
Contribution created with multiple line items overwrites the total amount with participant, if tax amount is included for a...Original issue raised on webform_civicrm project - https://www.drupal.org/project/webform_civicrm/issues/3390363
Contribution created with multiple line items overwrites the total amount with participant, if tax amount is included for all the line items.
**Steps to reproduce**
- Create a webform including event registration with participant fee and contribution with at least one additional line item.
- Ensure all the fees have tax included.
- Make a submission to generate a contribution with multiple line items.
- In civicrm access the contribution's edit form and save.
- On submit, the total amount and tax amount is recalculated and will only include the participant fee, additional line items are ignored.
The issue is possibly at this point - https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution.php#L1668
Not sure why its required to update the total amount on edit action, when we have a freezed display of it on screen?https://lab.civicrm.org/dev/core/-/issues/4693Admin UI: Maturation model2023-10-20T07:49:58ZtottenAdmin UI: Maturation model(**This issue is `type:exploration`. It is intended to discuss/explain/invite comment. It is not a singular action-item for implementation. The discussion may lead to other more concrete things. We can close the discussion when the appro...(**This issue is `type:exploration`. It is intended to discuss/explain/invite comment. It is not a singular action-item for implementation. The discussion may lead to other more concrete things. We can close the discussion when the approach is agreed; it doesn't need every possible follow-up task.**)
Context
-------
* Much of CiviCRM UI was originally built with one particular architecture. (Key concepts: `HTML_Quickform`, `Smarty`, `Selector`, `StateMachine`.) (Short-hand: "Civi-Quickform" or "CQF")
* We're in the middle of a multiyear project to convert large swaths of the CiviCRM UI to another architecture. (Key concepts: APIv4, Form Builder, SearchKit, Angular, Managed Entities.) (Short-hand: "SearchKit/FormBuilder" or "SKFB")
* The "Admin UI" extension (`civicrm_admin_ui`) is a bundle of SKFB screens (which replace CQF screens). The bundle currently provides ~20 screens.
Question
--------
As the screens in "Admin UI" mature, how do we roll them out to the user-base?
Opinions/Thoughts
--------
* The great thing about "Admin UI" extension is this: we can "move fast and break things" while keeping the ship "pointed in one direction" and also allowing "real-world testing".
* For site-builders, it's an opt-in that doesn't interfere with their existing screens. They can try new-screens and easily switch back to the familiar screens.
* For developers, it lowers the effort to get started -- you don't need perfection. You can do a first-pass in February -- it's a "good/decent" screen with a couple quirks or missing-features. You can take some time to get feedback or think-through the quirks. Then in May, you come back and make a better version.
* `civicrm_admin_ui` is accumulating a set of viable replacements.
* But they're not *all* equally viable.
* There are still many screens that don't have replacements -- screens which will need their own maturation time.
* There was some discussion about whether we're ready to enable `civicrm_admin_ui` by default. Some options are:
* __No, keep it disabled by default__ (until the entire UI has been re-done). But then a lot users don't get the benefit of perfectly good (*improved*) screens. And developers still have to maintain both the old+new variant of each.
* __Yes, enable it by default__ (while conversions are on-going). But then it puts more pressure for new screens to be perfect. You can't merge a replacement unless you've addressed all the features of the original.
Proposal
--------
Replacement-screens go through process of incubation/graduation, mediated by `civicrm_admin_ui`.
1. __Incubation__: When a new replacement is written in SKFB, put it in `civicrm_admin_ui`. Allow 3-9 months for additional development, real-world usage, etc.
2. __Graduation__: When the replacement is sufficiently mature, move it to a standard/universal folder. (Ex: A new CiviContribute SKFB screen will go to `ext/civi_contribute/`.)
3. __Cleanup__: Three months after graduation, delete the old screen.https://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/4639New approaches to ACL caching (and smart groups?)2024-02-16T16:22:42ZJonGoldNew approaches to ACL caching (and smart groups?)A lot of work has gone into improving the efficiency and frequency of ACL calculation. Let's attack the performance of writing the results to db?
I have a site where contacts change frequently, and ACLed users need to wait for 100,000 ...A lot of work has gone into improving the efficiency and frequency of ACL calculation. Let's attack the performance of writing the results to db?
I have a site where contacts change frequently, and ACLed users need to wait for 100,000 records to be written each time. Disabling opportunistic flushes only partly mitigates the issue.
Here are some ideas:
* Could we move ACL/smart group caching into `\Civi::cache`? Then we could use Redis etc.
* Instead of truncating and writing all contacts - what if we only `INSERT` and `DELETE` changes from the existing cache?
* When a contact's edited, could we just calculate cache for that contact? For any ACL based on a static group, this should be trivial. Even with smart groups/custom code - are there scenarios where we'd ever need to calculate ACLs for anyone but the changed contact and all their related contacts?https://lab.civicrm.org/dev/core/-/issues/4637Profile Update from SearchKit doesn't work2023-10-03T20:55:03ZlarsssandergreenProfile Update from SearchKit doesn't workIf you try to use Profile Update in SK, it pops up a modal to select the profile and then just closes when you click continue. Verified this is the behaviour back to at least 5.58. Probably makes more sense to get in-place editing workin...If you try to use Profile Update in SK, it pops up a modal to select the profile and then just closes when you click continue. Verified this is the behaviour back to at least 5.58. Probably makes more sense to get in-place editing working well enough to replace Profile Update, but at least we should remove it if is broken.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/core/-/issues/4634Replace all form-assigned variables from event workflow templates2024-02-22T05:21:07ZeileenReplace all form-assigned variables from event workflow templates**The goal is to remove all form based variables from the event workflow templates in order to**
1) make them work consistently from whereever they are called
2) make them display in preview mode (eg. with Message Admin extension)
3) re...**The goal is to remove all form based variables from the event workflow templates in order to**
1) make them work consistently from whereever they are called
2) make them display in preview mode (eg. with Message Admin extension)
3) reduce hacky code in the form layer with associated brittleness & fragility
4) eliminate the notices
5) make the code more similar on event templates
**To this end we have a few strategies**
1) Use tokens whereever possible. These are standardised across Workflow Templates & Event templates & follow consistent naming
2) Establish consistent variables to be assigned at the WorkFlow layer where tokens are not suitable
**Status**
**Workflow variables**
- `$participants` - this is an array of all participants associated with the registration with details in subkeys:
- contact_display_name
- line_items
- totals
- `$participantDetail` - the item from the above array that relates to the recipient participant
- `$isPrimary` is this the primary participant
- `$taxTerm` is broadly available in workflow templates - eg 'VAT'
- `$isShowLineItems` (comes from the price set is_quick_config)
**Tokens**
Tokens are available from event, participant, contact & contribution entities
**To do**
- [ ] Work through variables `$isOnWaitlist` `$isRequireApproval` (all event forms)
- [ ] Replace `$participant_status` with a token (online receipt)
- [ ] Replace is_pay_later with token (online receipt)
- [ ] Replace isAmountZero with token (online receipt)
- [ ] Replace isAdditionalParticipant with !$isPrimary (online receipt)
- [ ] Replace {$pay_later_receipt} with token (offline receipt)
- [ ] Replace event_confirm_text with token (online receipt)
- [ ] Replace `$receive_date`, financialType (online receipt)
- [ ] Replace isShowLocation with token (online receipt)
- [ ] Make sense of `$payer.name` (online receipt)
- [ ] Assign billingName, address from the ContributionWorkflowTrait or token - comes from civicrm_contribution.address_id.*
- [ ] Maybe credit_card_type, number etc come from the financial_trxn table
- [ ] Replace `$lineItems|@count` with something from the participant array & doesn't used smarty-2-only |@count (online & offline receipt)
- [ ] Replace $priceSetFieldsCount with something from the workflow message template layer, also `{foreach from=$lineItem item=pcount}` loop
- [ ] Replace $event.confirm_email_text with `$userText` offline receipt
- [ ] Move event_registration_receipt to event cart - this extension is being phased out so we can let it go once that is the case
- [ ] Move assigning `customGroups` to the workflow template (offline receipt) https://github.com/civicrm/civicrm-core/pull/27596
- [ ] Move assigning profiles to the workflow template (online receipt)
- [ ] Get tokens & token substution & examples working for remaining participant templates -transfered, cancelled etc
- [ ] $hookDiscountMessage - ? not surehttps://lab.civicrm.org/dev/core/-/issues/4633Fix extensions to work with Smarty3 - backticks2023-11-17T00:41:05ZeileenFix extensions to work with Smarty3 - backticksIn order to replace Smarty 2 with Smarty 3 we need to make minor changes to extensions so that they are compatible
UPDATE - the backticks seem to be less hurty than I thought so I misunderstood @larssg anaysis of when they DO cause issu...In order to replace Smarty 2 with Smarty 3 we need to make minor changes to extensions so that they are compatible
UPDATE - the backticks seem to be less hurty than I thought so I misunderstood @larssg anaysis of when they DO cause issues
Ref https://github.com/kanshin/CakeSmarty/blob/master/vendors/Smarty-3.0.9/SMARTY2_BC_NOTES
- [ ] Backticks should no longer be used in strings - unfortunately the advertised way of doing crmUrl included backticks - we should add to `civix upgrade` to include doing a regex to fix these
href="{crmURL p='civicrm/participant/add' q="reset=1&action=add&context=standalone&eid=`$event.id`"}"
this regex seems to work to find them
\".*`\$.*`\"
![image](/uploads/51b4097c2491e9d07b432605c7b3ed34/image.png)
![image](/uploads/8241c284e6cff66e766b832b5a3beaf6/image.png)
- [ ] Find extensions with older civix & run regex on them - for those with backticks this will fix. For the others it will allow Smarty3 to be run in the transition period
- [ ] Patch / hack Smarty2 to give deprecation notices for the above
- [ ] When we are closer to transitioning consider temporarily hacking string replace into smarty 3 fetch function
Extension list
- [ ] CiviRules
- [ ] UK Gift Aid https://lab.civicrm.org/extensions/ukgiftaid/-/merge_requests/41
- [ ] CiviCalender https://github.com/agiliway/com.agiliway.civicalendar/pull/34
- [ ] Elections https://lab.civicrm.org/extensions/elections/-/merge_requests/4https://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/core/-/issues/4631CiviGrant labels are...not good2024-02-15T15:50:15ZJonGoldCiviGrant labels are...not goodThe CiviGrant fields are strange.
The "Amount Requested" field has this description: *Requested grant amount, in original currency (optional)*.
"Total Amount" has this description: *Requested grant amount, in default currency*.
If you...The CiviGrant fields are strange.
The "Amount Requested" field has this description: *Requested grant amount, in original currency (optional)*.
"Total Amount" has this description: *Requested grant amount, in default currency*.
If you're creating a FormBuilder form for grant requests, it makes sense that you'd want a "Requested Amount" field - but you actually need to use "Total Amount". This is unintuitive, and there's nothing in the field labels to suggest anything about original vs. default currency.
I don't think "Total Amount" makes any real sense here as a label - if anything, I'd expect that to be the amount granted (except that's the "Amount Granted" field).
**Proposal**
"Total Amount" gets relabeled as "Total Amount Requested".
"Amount Requested" gets relabeled as "Amount Requested in Original Currency".https://lab.civicrm.org/dev/core/-/issues/4629Search Kit: DB Entity needs all columns to work2023-10-20T07:56:29Za.valllloveraSearch Kit: DB Entity needs all columns to workOverview
----------------------------------------
When using DB Entity you cannot delete columns, or the results will not be refreshed on the DB table
Reproduction steps
----------------------------------------
![DB_Entity_Rows](/uploa...Overview
----------------------------------------
When using DB Entity you cannot delete columns, or the results will not be refreshed on the DB table
Reproduction steps
----------------------------------------
![DB_Entity_Rows](/uploads/8ffa61cb9c3b70be840877c4505152e8/DB_Entity_Rows.gif)
Current behaviour
----------------------------------------
If you delete some columns in the DB Entity, you can Save the Search but it will not refresh the results in the DB Table.
The Api4 gets you more information about what's happening:
![image](/uploads/ec5d210a1fc5e4a952ce273f1960b7c7/image.png)
```
"info": "INSERT INTO `civicrm_sk_contacts_db_entity1` (id, sort_name)
SELECT `a`.`id` AS `id`,
`a`.`sort_name` AS `sort_name`,
`a`.`contact_type` AS `contact_type:label`,
`a`.`contact_sub_type` AS `contact_sub_type:label`
FROM civicrm_contact a
WHERE (`a`.`contact_type` = \"Individual\")
ORDER BY `a`.`sort_name` ASC
[nativecode=1136 ** Column count doesn't match value count at row 1]",
"db_error": "value count on row",
```
As you can see, the Insert above is not correct and that (I suspect) is the main reason of this behaviour.
Expected behaviour
----------------------------------------
Can alter the number of columns in the DB Entity, to only save the ones that you want on the DB Table.
Environment information
----------------------------------------
* __CiviCRM:__ _[dmaster](https://dmaster.demo.civicrm.org/civicrm/dashboard?reset=1)_ v.5.67.alpha1https://lab.civicrm.org/dev/core/-/issues/4628Search Kit: DB Entity doesn't work with Data Segment2023-10-20T07:56:10Za.valllloveraSearch Kit: DB Entity doesn't work with Data SegmentOverview
----------------------------------------
When you have fields with Data Segmentation and try to use the DB Entity, the search will never be saved in the database, it will stuck in neverending Saving status.
https://chat.civicrm...Overview
----------------------------------------
When you have fields with Data Segmentation and try to use the DB Entity, the search will never be saved in the database, it will stuck in neverending Saving status.
https://chat.civicrm.org/civicrm/pl/jkbfnoukuid38mhroyj1fer1mh
Reproduction steps
----------------------------------------
1. Create a Data Segmentation
1. Create a SK Search that includes the Data Segmentation previosly created
1. Use the DB Entity and try to Save the search while selecting the Data Segmentation field.
![SK_Db_Entity](/uploads/0dce391d884193738e5ca9f767da59ec/SK_Db_Entity.gif)
Current behaviour
----------------------------------------
When you want to save the Search, the DB Entity it enters into an infinite saving status.
![Saving_forever](/uploads/14c2f4b90e0c45176bd1a8424692df92/Saving_forever.gif)
Via api4 you can see that the table is not created in the DB.
![image](/uploads/24c59f656eb38276978c2a3b7fe00e81/image.png)
Expected behaviour
----------------------------------------
It saves the Search, create the Table in the DB and refresh the table with the content of the search.
Environment information
----------------------------------------
* __CiviCRM:__ [dmaster](https://dmaster.demo.civicrm.org/civicrm/dashboard?reset=1) v.5.67.alpha1https://lab.civicrm.org/dev/core/-/issues/4627Proposal: Membership type label2023-10-01T19:23:57Zmattwiremjw@mjwconsult.co.ukProposal: Membership type labelThe membership type table only has "name" and you cannot specify a separate label/title for display. This makes it problematic for portability/import/export as well as translation.
Proposal: Add new field "label" to MembershipType which...The membership type table only has "name" and you cannot specify a separate label/title for display. This makes it problematic for portability/import/export as well as translation.
Proposal: Add new field "label" to MembershipType which is used for display instead of the name.https://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/4625Inconsistent search result when "Modified By" field and apply an action2023-09-26T12:28:52Zthomas_SYSTOPIAInconsistent search result when "Modified By" field and apply an action**Description:**
When apply an action (like "Tag - add to contacts") on a search result using "Change Log->Modified By" field the result scope is lost. Instead the action would be applied to all contacts.
**Steps to reproduce** (tested...**Description:**
When apply an action (like "Tag - add to contacts") on a search result using "Change Log->Modified By" field the result scope is lost. Instead the action would be applied to all contacts.
**Steps to reproduce** (tested on https://d9-master.demo.civicrm.org/):
1. Use the advanced search form with "Change Log->Modified By" = _admin_. The result includes exactly one contact.
2. Choose "Tag - add to contacts" from the action menu.
3. You'll see "Number of selected contacts: 204" (204 are the sum of all contacts.)https://lab.civicrm.org/dev/core/-/issues/4622Running queues following the docs' example might lead to infinite loops2023-10-27T08:36:37ZjensschuppeRunning queues following the docs' example might lead to infinite loopsFollowing the [_Queue Reference_ example](https://docs.civicrm.org/dev/en/latest/framework/queues/#3-run-the-queue) for running a queue in `CRM_Queue_Runner::ERROR_CONTINUE` mode with a `while` loop that only `break`s for `is_continue!=1...Following the [_Queue Reference_ example](https://docs.civicrm.org/dev/en/latest/framework/queues/#3-run-the-queue) for running a queue in `CRM_Queue_Runner::ERROR_CONTINUE` mode with a `while` loop that only `break`s for `is_continue!=1` will lead to infinite loops when a queue item has not been released yet (e.g. due to the script terminating without an exception being caught and the queue being re-run before release of the next item).
That's because `CRM_Queue_Queue_Sql::claimItem()` fetches the _first_ queue item and filters for `release_time` _afterwards_ - yielding no result, but reporting more items to be in the queue (`is_continue=1`). The only way to catch these cases with code calling the `CRM_Queue_Runner::runNext()` method is to check for `is_error=1` and the `exception` message being `Failed to claim next task`.
So, I've got some questions regarding Queues:
* Is there any best practice for handling errors during `claimItem()` any better?
* Would you agree there should be another indicator in the task result for those cases, or maybe that exception actually being thrown?
* Alternatively, should `is_continue` be `0` instead for those cases (i.e. its meaning would change from _queue finished_ to _queue processing can continue_)?
* Can the `$lease_time` parameter for SQL queues' `claimItem()` be exposed to all queues, so that the caller can modify it?
I see that the query was altered with https://github.com/civicrm/civicrm-core/pull/15421 by @artfulrobothttps://lab.civicrm.org/dev/core/-/issues/4620CiviEvent dashboard: start date is 7 days ago2023-09-26T12:23:49ZmasettoCiviEvent dashboard: start date is 7 days agoI follow up https://civicrm.stackexchange.com/questions/22424/how-to-customize-events-dashboard.
The event dashboard now shows recent and upcoming events (where start date is 7 days ago OR later).
It would be convenient if the numbe...I follow up https://civicrm.stackexchange.com/questions/22424/how-to-customize-events-dashboard.
The event dashboard now shows recent and upcoming events (where start date is 7 days ago OR later).
It would be convenient if the number of days was configurable in the preferences of CiviEvents (`civicrm/admin/setting/preferences/event`).
Do you think it is useful and required by others as well?https://lab.civicrm.org/dev/core/-/issues/4619Eliminate `contributeMode`2023-09-26T12:23:10ZeileenEliminate `contributeMode``contributeMode` is the old concept when we thought we could categorise payment processors into 3-4 basic types that did the same stuff. We have mostly eliminated but it perseveres in a few places we want to kill
| Form | Used for |Alte...`contributeMode` is the old concept when we thought we could categorise payment processors into 3-4 basic types that did the same stuff. We have mostly eliminated but it perseveres in a few places we want to kill
| Form | Used for |Alternative|
| ------ | ------ |------------|
| Contribution_Confirm | Should the form `postProcess` hook be called before `doPayment` |? `$processor->supports('formAssumesNoReturn')` (I kinda feel it should be on the processor to call the hook but...|
| Contribution_Confirm | Should the button be called 'Continue' or 'Make Contribution' |Ditch? always 'Make Contribution'? Or do we need a `getText('continue_contribution_button)`|
|Event_Registration|Should emails be sent from the form (otherwise sent on completetransaction)|? `$processor->supports('formAssumesNoReturn')`|
|Event_Registration_Confirm|Should paypal express code be called|probably just a different hack|
|Event_Registration_Confirm::554|several places tricky stuff around doPayment| will need unravelling|
|Contribution Confirm.tpl|What text should we use for continue_instructions-section|?`paymentObject->getText('continue_contribution_instruction')` ?|
|Registration Thankyou.tpl|What text should be used arount 'Your registration has been processed successfully'|?`paymentObject->getText('event_success_instruction')` ?|
All other places are either doing nothing or are removable