Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-11-02T17:26:41Zhttps://lab.civicrm.org/dev/core/-/issues/4731SearchKit/Form Builder: re-positioning menu links column in table display bre...2023-11-02T17:26:41ZtomrosenbloomSearchKit/Form Builder: re-positioning menu links column in table display breaks csv downloadTo reproduce:
1. add a Menu column to a SK table display - it will appear in the last column by default
2. move menu links column to a different position
3. create afform from this display
4. use action menu to download results to csv
5...To reproduce:
1. add a Menu column to a SK table display - it will appear in the last column by default
2. move menu links column to a different position
3. create afform from this display
4. use action menu to download results to csv
5. now check the download - the column data immediately to the right of the menu column is missing and the data in subsequent columns is shifted to the left
I guess this could be due to something not being closed off properly and corrupting the table, and in that case it could be relevant that one of my menu links is `civicrm/case-detail#/?id=[id]`
EDIT: no, don't think it's that: I removed this link and the problem persists5.68.0https://lab.civicrm.org/dev/core/-/issues/4728Form Builder Issue: Filter for "Contact (Near Side) / Contact (Far Side)" not...2023-10-26T11:44:33ZTobias Voigttobias.voigt@civiservice.deForm Builder Issue: Filter for "Contact (Near Side) / Contact (Far Side)" not workingI start with the "contacts" entity in Search Kit, then include "Contact Related Contacts" as an additonal entity and create a form in Form Builder for this composed search.
In Form Builder I then add a filter for both "Contact (Near Sid...I start with the "contacts" entity in Search Kit, then include "Contact Related Contacts" as an additonal entity and create a form in Form Builder for this composed search.
In Form Builder I then add a filter for both "Contact (Near Side)" and "Contact (Far Side)". When I then search for and choose a contact through one "Contact (Near Side)", the results table shows ALL possible results. When I search for and choose a contact through one "Contact (Far Side)", the results table is empty.
I was able to reproduce this behaviour in https://dmaster.demo.civicrm.org.
Side note: When I create a form directly for the composed search (rather than for a Search Kit table), I also get a warning: "Warning: Trying to access array offset on value of type null in Civi\Api4\Action\SearchDisplay\GetDefault->getColumnLabel() (line 418 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/Api4/Generic/Traits/SavedSearchInspectorTrait.php)."
Not sure if this is related to the issue or not.
If it would work, this filter would be extremely helpful and great to have.https://lab.civicrm.org/dev/core/-/issues/4725Proposal: Don't include "I am contributing on behalf of an organization" on c...2023-11-23T07:51:08ZlarsssandergreenProposal: Don't include "I am contributing on behalf of an organization" on contribution pages when the current contact is an organizationIf an organization receives a personalized link to a contribution page, the user may not realize they are already using the form as an organization (especially because the billing details will show their first and last name if they used ...If an organization receives a personalized link to a contribution page, the user may not realize they are already using the form as an organization (especially because the billing details will show their first and last name if they used them in the past). If they then select "I am contributing on behalf of an organization", they will get a error: `Payment Processor Error message :Invalid Relationship .`
This is because we are attempting to create a new organization with an employer of relationship to the current contact, which fails when the current contact is an organization as this is not allowed.
I think the simplest and most logical way to fix this is simply to not include the on behalf of option on the contribution page if the current contact is an organization and instead show the organization profile by default. If the user wants to contribute on behalf of the current contact organization, then this is fine. If they are contributing on behalf of a different organization or as an individual, they should click the not you link.https://lab.civicrm.org/dev/core/-/issues/4721Get rid of `civicrm_option_value.domain_id`2023-10-26T11:41:06ZcolemanwGet rid of `civicrm_option_value.domain_id`Background/Motivation
------
Most tables with a `domain_id` column have that field *required* for every record.
`civicrm_option_value` is an outlier; most option groups don't care about domains. In fact there are only two that do:
```p...Background/Motivation
------
Most tables with a `domain_id` column have that field *required* for every record.
`civicrm_option_value` is an outlier; most option groups don't care about domains. In fact there are only two that do:
```php
/**
* $_domainIDGroups array maintains the list of option groups for whom
* domainID is to be considered.
*
* FIXME: Hardcoded list = bad. It would be better to make this a column in the civicrm_option_group table
* @var array
*/
public static $_domainIDGroups = [
'from_email_address',
'grant_type',
];
```
The `civicrm_option_value.domain_id` column and that lovely accompanying hardcoded list were added [in this commit](https://github.com/civicrm/civicrm-svn/commit/406091dc969907753a56fd7fae73320b1b012e67) as part of [this issue](https://issues.civicrm.org/jira/browse/CRM-5546). The assumption at the time seemed to be that the list might grow in the future, but that's proven to not be the case. Instead, we have this extra column making the already overloaded `civicrm_option_value` table even more complex to deal with. It would have been better at the time to move those two option groups into their own tables. It may not be too late to do so.
Proposal
-----------
1. Create a new table `civicrm_grant_type` - manage that table from the `civigrant` extension.
2. Create a new table `civicrm_from_email_address`.
3. Migrate all options into the new tables. Update pseudoconstant metadata in the schema.
4. Add some legacy handling at a few key points like `civicrm_api()` & `CRM_Core_OptionGroup::values()` to fetch options from the new table, for backward compatibility.
5. Deprecate the `civicrm_option_value.domain_id` column and eventually drop it.https://lab.civicrm.org/dev/core/-/issues/4715The Search-UI extension gives a menu item Experimental2023-10-26T11:36:52ZjaapjansmaThe Search-UI extension gives a menu item Experimental**Steps to reproduce**
1. Install a fresh CiviCRM (version 5.66)
2. Enable Search UI extension
**Results**
A new menu item called Experimental appears. See attached screenshot
![Untitled](/uploads/219b7c83f1303681f6afbbc15497eacf/Unt...**Steps to reproduce**
1. Install a fresh CiviCRM (version 5.66)
2. Enable Search UI extension
**Results**
A new menu item called Experimental appears. See attached screenshot
![Untitled](/uploads/219b7c83f1303681f6afbbc15497eacf/Untitled.png)
**Why is this an issue?**
This is an issue because the extension ships with a stable version of CiviCRM Core. And installing this on a production site gives some unexpected menu item.
When I download a stable version of CiviCRM I am not sure whether I would expect a menu item Experimental.
**Possible solution**
1. Move the extension out of core. This also has the benefit it can be installed on other versions of CiviCRM as well.
2. Do not use the menu item experimental but place the items provided in this extension in a more suitable place.
My opinion would be as long as this extension is experimental to not ship it with core.https://lab.civicrm.org/dev/core/-/issues/4713Move the Elavon Payment Processor extension out of core2023-11-28T23:54:24ZjaapjansmaMove the Elavon Payment Processor extension out of coreI have just installed CiviCRM 5.66 for a client and I see it ships with an Elavon Payment Processor extension.
I have never heard of Elavon and I believe this extension is very usefull but not in the use cases I have seen so far. (They...I have just installed CiviCRM 5.66 for a client and I see it ships with an Elavon Payment Processor extension.
I have never heard of Elavon and I believe this extension is very usefull but not in the use cases I have seen so far. (They use CiviSepa for direct debits and Mollie for online payments both are not shipped with core).
I also believe that an extension which lives outside of core is also easier to install on CiviCRM installations which does not have this extension shipped by default (when needed).https://lab.civicrm.org/dev/core/-/issues/4712Move the PHP Storm extension out of core2023-10-26T11:37:31ZjaapjansmaMove the PHP Storm extension out of coreI have just installed a fresh Civi 5.66 site for production at a client and I see that core now ships a PHP storm extension.
I believe this extension is very useful for developers but probably not for production sites.
So can this exte...I have just installed a fresh Civi 5.66 site for production at a client and I see that core now ships a PHP storm extension.
I believe this extension is very useful for developers but probably not for production sites.
So can this extension moved out of core? That also gives other flexibility to install this extensions on older CiviCRM sites on which I am doing development on.https://lab.civicrm.org/dev/core/-/issues/4711Make it easier for extensions to add Navigation Menu items2023-10-24T14:13:07ZcolemanwMake it easier for extensions to add Navigation Menu itemsBackground
------
Extensions have a few ways of adding to the navigation menu, and none of them are great.
1. `hook_civicrm_navigationMenu()` - brute-forces an item into the menu. It's relatively easy to implement (thanks to some extra...Background
------
Extensions have a few ways of adding to the navigation menu, and none of them are great.
1. `hook_civicrm_navigationMenu()` - brute-forces an item into the menu. It's relatively easy to implement (thanks to some extra fudging that `civix` does for you) but defeats the whole configurability idea; users and administrators have no control over the item.
2. `install`/`uninstall` hooks - this is hard to implement as there are a lot of edge cases to consider (domains, weights, etc) and you have to manage the full lifecycle yourself (install, disable, enable, uninstall).
3. `hook_civicrm_managed()` - this handles the lifecycle for you, but not the domains, and the weights are completely by guesswork. Changes made by the user (e.g. deleting the menu item) might be undone by `Managed::reconcile`.
4. `.aff.php` - Afforms allow you to declare a navigation menu as part of the form - this gets delegated to `hook_civicrm_managed()`, with all the same problems that carries, plus the additional problem that user-changes to the item can lose sync with the Afform settings (see https://lab.civicrm.org/dev/core/-/issues/4364).
IMO items 1 and 2 are unfixable, but item 3 has promise, and item 4 could be deprecated in favor of 3.
Outstanding problems with Managed Navigation Menu Items.
----------
- [x] 1. ManagedEntities cannot be deleted. If a user deletes a managed Navigation item, it will respawn with the next `Managed::reconcile`.
- [x] 2. Navigation BAO doesn't even call hooks, defeating the ManagedEntity `update=unmodified` mode.
- [x] 3. ManagedEntities are not domain-aware; if you want your navigation item to appear on all domains (which you do, since your extension will be enabled globally - there are no per-domain extensions), you have to declare a managed navigation item once per domain (which is [a bit awkward](https://github.com/civicrm/civicrm-core/blob/f04bfacb5ed5131c9d29e8a9c0725c3059caeef0/ext/legacycustomsearches/managed/Navigation.mgd.php#L7)).
- [ ] 4. Picking a `weight` is pure guesswork. You just have to put in an integer and hope it lands in the right spot. Picking `0` will pretty reliably place it at the top; anything else is a roll of the dice.
Proposed Solutions
-------
1. Fixed via [ManagedEntities - Recreate deleted records at discretion of update policy](https://github.com/civicrm/civicrm-core/pull/27844).
2. Fixed via [dev/core#4364 Use writeRecord for Navigations so menu changes for managed entities don't reset](https://github.com/civicrm/civicrm-core/pull/27832).
3. Fixed via [ManagedEntity - Replicate multi-domain entities when multisite is enabled](https://github.com/civicrm/civicrm-core/pull/27876).
4. [Here is a PR](https://github.com/civicrm/civicrm-core/pull/27894) to add a `previous` and `next` join in APIv4 which would allow you to specify the name of the menu item you wish to insert next to. For example, to add a menu item just below the "Find Contacts" menu item, you'd say `['previous.name' => 'Find Contacts']` in your managed declaration (in lieu of `'weight' => 5').
5. To deprecate the Afform navigation handling, we can still support it in the Admin form, but instead of writing to the `.aff.json` file and that getting picked up by `afform_civicrm_managed()` the admin form could just save the navigation item directly. We can also teach the new [`civix export` command](https://github.com/totten/civix/pull/312) to generate a `.mgd.php` for every navigation menu item associated with an Afform.https://lab.civicrm.org/dev/core/-/issues/4704Event Info displays "registration is closed", but it requires login2023-10-20T17:45:41ZbgmEvent Info displays "registration is closed", but it requires loginIn commit 597e807091d835fba28a636ea8f9da76bf63b1a0, the condition for assigning this variable changed:
```
--- a/CRM/Event/Page/EventInfo.php
+++ b/CRM/Event/Page/EventInfo.php
@@ -280,10 +280,8 @@ class CRM_Event_Page_EventInfo extends...In commit 597e807091d835fba28a636ea8f9da76bf63b1a0, the condition for assigning this variable changed:
```
--- a/CRM/Event/Page/EventInfo.php
+++ b/CRM/Event/Page/EventInfo.php
@@ -280,10 +280,8 @@ class CRM_Event_Page_EventInfo extends CRM_Core_Page {
$this->assign('registerURL', $url);
}
}
- elseif (CRM_Core_Permission::check('register for events')) {
- $this->assign('registerClosed', TRUE);
- }
}
+ $this->assign('registerClosed', !empty($values['event']['is_online_registration']) && !$isEventOpenForRegistration);
$this->assign('allowRegistration', $allowRegistration);
```
The template in `templates/CRM/Event/Page/EventInfo.tpl` has the following code:
```
{if $registerClosed}
<div class="spacer"></div>
<div class="messages status no-popup">
<i class="crm-i fa-info-circle" aria-hidden="true"></i>
{ts}Registration is closed for this event{/ts}
</div>
{/if}
```
On a specific project, we previously had the following conditions:
- People had to login in order to register for an event
- Registrations can be closed at some pointhttps://lab.civicrm.org/dev/core/-/issues/4702Cannot clear country and state/province in contact summary address2023-12-13T20:24:15ZlarsssandergreenCannot clear country and state/province in contact summary address1. Open an address on a contact summary for editing.
2. Remove the country, which clears state/province (or remove state/province and then country).
3. Attempt to save.
Result: ![image](/uploads/4d69fc6535ffa916febbca831c393998/image.pn...1. Open an address on a contact summary for editing.
2. Remove the country, which clears state/province (or remove state/province and then country).
3. Attempt to save.
Result: ![image](/uploads/4d69fc6535ffa916febbca831c393998/image.png)
I think this a problem of the chain select not working correctly to deselect the option value, as it doesn't show a value, but the element still has a value when retrieved [here](https://github.com/civicrm/civicrm-core/blob/c911736f714c1bde28f6cdcc3b1bd0e1afbb894e/CRM/Core/Form.php#L2871). Maybe something between chain select and Select2?
If you save again, it does work.https://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/user-interface/-/issues/61Modals: move from Jquery UI Dialog to something else?2024-02-20T00:52:26ZnicolModals: move from Jquery UI Dialog to something else?At present Civi's modals (aka popups) are generated using [JQuery UI Dialog](https://jqueryui.com/dialog/). This inserts the modal's markup just above the bottom `</body>` closing tag, which is outside of `#crm-container` and `#bootstrap...At present Civi's modals (aka popups) are generated using [JQuery UI Dialog](https://jqueryui.com/dialog/). This inserts the modal's markup just above the bottom `</body>` closing tag, which is outside of `#crm-container` and `#bootstrap-theme` divs. This is perhaps related to [an issue where](https://chat.civicrm.org/civicrm/pl/fywkz1tcetdp5ms6s39zqfxcbw) modals can't render Bootstrap elements from Form Builder output.
![image](/uploads/71aee3e41f4455dfe65476ab6e821fd9/image.png)
JQuery UI dates back to 2007, is tricky to theme, and doesn't include modern accessibility Aria labels. What are the other options?:
1. replace with [Bootstrap 3's modal component](https://getbootstrap.com/docs/3.4/javascript/#modals) that ships with Civi. Upside is it's more accessibile, reduces code, is easier to retheme or share styles with the base theme.
Downside is there's no grabber to resize the modal, and you can't have multiple modals open at the same time, which Civi likes to do at present. Multiple modals is [considered bad UX](https://app.uxcel.com/courses/ui-components-n-patterns/modals--dialogs-best-practices-166) - Bootstrap5 offers [toggling between multiple modals](https://getbootstrap.com/docs/5.3/components/modal/#toggle-between-modals). There's also scripts that extend Bootstrap Modal to support multiple, ie https://codepen.io/neni9/pen/dJVwqr.
![image](/uploads/4dee863b5b5bd40d0d8a0d95084a0c7b/image.png)
2. use an Angular modal method (e.g. https://jasonwatmore.com/post/2016/07/13/angularjs-custom-modal-example-tutorial)
3. use another modal library
4. use the html element `<dialog>` (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog). Accessible by default, requires no javascript library (can use the native [showModal](https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/showModal) method), widely supported, should never grow old/need replacing, easy to theme… (am writing the upsides in the hope someone replies below with the downsides).
5. change nothing, just ensure that #bootstrap-theme can be applied to the contents of a modal.Improve Civi's front-endhttps://lab.civicrm.org/dev/user-interface/-/issues/60Accordions: Eight patterns in Civi markup – reduce & make more accessible?2024-03-06T20:20:40ZnicolAccordions: Eight patterns in Civi markup – reduce & make more accessible?At present [Civi docs recommends](https://docs.civicrm.org/dev/en/latest/framework/ui/#accordions) making an accordion interface element with `.crm-accordion-wrapper`. There's at least another seven ways accordions are implemented in Civ...At present [Civi docs recommends](https://docs.civicrm.org/dev/en/latest/framework/ui/#accordions) making an accordion interface element with `.crm-accordion-wrapper`. There's at least another seven ways accordions are implemented in Civi, as seen in #56. Some of these look/behave differently, and maybe have to be different, but perhaps some could be merged.
Furthermore, none of these use the basic [aria-labels](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-expanded) recommended in the [Bootstrap3 method](https://getbootstrap.com/docs/3.4/javascript/#collapse) (which remains in Bootstrap5), for letting screen-readers know if an accordion is open or closed, and which contents should be read or not. This is a long-standing issue - https://lab.civicrm.org/dev/core/-/issues/3294 - raised by the late accesibility expert Rachel Olivero (the Olivero theme is named after her). Sidenote: Bootstrap's accordion pattern (`.collapse`) doesn't seem to be used anywhere in Civi.
This meta issue is designed to clarify two points, to further the goals of #57 (and support #58 & #59), and follows @eileen's [question here](https://lab.civicrm.org/dev/user-interface/-/issues/59#note_151554):
- [ ] can we reduce the number of accordion markup patterns that a theme must support from 7 to anything less?
- [ ] can we amend the recommend accordion markup (and in turn civi's accordion implementations) to be more accessible (+ modern/responsive)?
#### The patterns:
1. `.crm-accordion-wrapper` - as recommended in the docs UI reference guide
2. (related) `.crm-dashlet-header` - as seen on the home dashboard. Looks the same but only the expand icon (e.g. arrow) is clickable as the rest of the header needs to be a drag-gable region.
3. `.crm-collapsible` - notably used on the field groups on the contact record main tab - it has no background for the header or body
4. (related) `.crm-collapsible` on a fieldset - as seen on event signup pages
5. `.collapsed` in a table - as seen on the extensions listing page
6. using the `.crm-ui-accordion` angular directive. This is a shorthand to generate the `.crm-accordion-wrapper` type accordion top.
7. `.af-collapsible` on a FormBuilder element - as seen in forms generated by Form Builder - a new JS/CSS/markup pattern [added in 2022](https://github.com/civicrm/civicrm-core/blob/master/ext/afform/admin/ang/afGuiEditor/afGuiMenuItemCollapsible.component.js)
8. there's another Jquery/Angular fieldset accordion used in Searchkit builder that's not in ThemeTest yet.
#### Range of characteristics
These eight variations cover 5 different visual/interaction patterns:
- click on full header to expand/close
- click only on expand/close icon to expand/close
- shaded background for header and body
- transparent background for header and body
- expand a region outside of the parent accordion wrapper (5 - maybe soon to be replaced with SK/FB)
#### Merging patterns
Initial thought is that with a bit of extra css and a tiny bit of rewriting, all of these could be done with two patterns - one based on the current recommended `wrapper > header + body`, with the full header clickable and the icon added entirely in css; and one based on an icon wrapped in an <a> tag that toggles the visibility of another region, as seen in patterns 2 and 5 above (while 5 may soon be replaced and 2 is one-off)..
- A utility class like `crm-accordion-clear` could be applied next to `.crm-accordion-wrapper` to provide 1) above with the same UI as 3)
- Likewise two new CSS selectors could allow the same pattern to be applied to 4) & 8) . Both these changes are demonstrated in a new ThemeTest branch: [Proposals](https://lab.civicrm.org/extensions/themetest/-/commits/proposals)
- I'm not sure why in 7) + 8) the new SK/FB Angular accordions diverged in markup/js/css from Civi's recommend accordion - maybe needs @colemanw to feed in.
- The extensions page 5) will be rewritten with FB/SK at some point so can maybe ignore.
- That leaves 2) - an accordion where only the icon triggers an expand/close so the rest the header is a dragable region. I think that making this use the same markup/css pattern as the others would require rewriting all the others, so it might be safest to leave this an exception for now. There is an attempt to merge the patterns in [Proposals](https://lab.civicrm.org/extensions/themetest/-/commits/proposals) but the header is doing a lot - dragging and right-floated icons. A toggle behavior is more compelling than an accordion, even if it should look like an accordion.
- But even with keeping 2), then potentially only 2 patterns left out of 8.
#### Thoughts on accessibility
[Work has been done](https://github.com/civicrm/civicrm-core/pull/11955) to implement [JQuery Accessible Accordion Aria](https://libraries.io/bower/jquery-accessible-accordion-aria) into Civi (demo of the plugin - https://a11y.nicolas-hoffmann.net/accordion/). Not sure if that is still a promising path, or there's a JQuery free methods now.
The current recommended pattern could be made more accessible with something like the following, based on Bootstrap3's collapse. There's fewer ARIA labels than the JQuery plugin, but it makes clear if the accordion is open or not, and links the header to the expand region with an id, two recommendations of [this walkthru](https://www.hassellinclusion.com/blog/accessible-accordion-pattern/) on accessible accordions.
```
<div class="crm-accordion-wrapper collapsed">
<div class="crm-accordion-header" aria-expanded="false" aria-controls="uniqueID">
Accordion Title here
</div>
<div class="crm-accordion-body" id="uniqueID">
<div class="crm-block crm-form-block crm-form-title-here-form-block">
Accordion Body here
</div>
</div>
</div>
```
This would require two changes - a unique ID added to every unique accordion on a page, and an `aria-expanded="false"` attribute that toggles true/false.
#### Questions
- why did the new angular accordions take another approach? Speed of development or something practical?
- is it worth trying to reduce these down to two recommended patterns, by swapping out the new angular patterns and adding a few new css classes into core? Or better to wait and flag this for the future?
- what's the easiest way to make civi accordions more screen reader friendly?Improve Civi's front-endhttps://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 -->