Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-10-22T22:13:14Zhttps://lab.civicrm.org/dev/core/-/issues/4709Custom Field display code assumes option values are numeric2023-10-22T22:13:14ZJonGoldCustom Field display code assumes option values are numericOverview
----------------------------------------
Custom Field display code assumes option values are numeric. This leads to crashing when searching using regex/`LIKE` in Search Builder, and possibly less obsolete parts of Civi as well....Overview
----------------------------------------
Custom Field display code assumes option values are numeric. This leads to crashing when searching using regex/`LIKE` in Search Builder, and possibly less obsolete parts of Civi as well.
Reproduction steps
----------------------------------------
1. Create a new custom field of data type Alphanumeric, HTML type of Select.
1. Go to Search Builder.
1. Search on that field using regex or `LIKE`, with a period in the search term. See attached screenshot.
Current behaviour
----------------------------------------
```
TypeError: round(): Argument #1 ($num) must be of type int|float, string given in round() (line 1332 of /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/BAO/CustomField.php).
```
Expected behaviour
----------------------------------------
Search should complete as normal.
Comments
----------------------------------------
This happens because we assume that a select value either has a corresponding label, or it's a number. Which is true when you're searching for a specific value, but fails when the value is a regex or LIKE statement.
This doesn't happen in SearchKit, but it *does* happen when you use a smart group based on the search.
This is a regression in the technical sense, but it's been broken since at least 5.53.
Backtrace is below:
```
#0 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/CustomField.php(1278): round()
#1 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/CustomField.php(1194): CRM_Core_BAO_CustomField::formatDisplayValue()
#2 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/CustomQuery.php(197): CRM_Core_BAO_CustomField::displayValue()
#3 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/CustomQuery.php(369): CRM_Core_BAO_CustomQuery->where()
#4 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/Query.php(569): CRM_Core_BAO_CustomQuery->query()
#5 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/Query.php(524): CRM_Contact_BAO_Query->initialize()
#6 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/GroupContactCache.php(585): CRM_Contact_BAO_Query->__construct()
#7 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/GroupContactCache.php(777): CRM_Contact_BAO_GroupContactCache::getQueryObjectSQL()
#8 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/GroupContactCache.php(616): CRM_Contact_BAO_GroupContactCache::insertGroupContactsIntoTempTable()
#9 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/GroupContactCache.php(359): CRM_Contact_BAO_GroupContactCache::buildGroupContactTempTable()
#10 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Mailing/BAO/Mailing.php(477): CRM_Contact_BAO_GroupContactCache::load()
#11 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Mailing/BAO/Mailing.php(1647): CRM_Mailing_BAO_Mailing::doSubmitActions()
#12 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/api/v3/utils.php(1294): CRM_Mailing_BAO_Mailing::create()
#13 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/api/v3/Mailing.php(55): _civicrm_api3_basic_create()
#14 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_mailing_create()
#15 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(156): Civi\API\Provider\MagicFunctionProvider->invoke()
#16 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(79): Civi\API\Kernel->runRequest()
#17 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/api/api.php(136): Civi\API\Kernel->runSafe()
#18 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/api/v3/Mailing.php(307): civicrm_api3()
#19 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_mailing_submit()
#20 /home/members/mysite/sites/crm.mysite.org/web/wp-content/civicrm-custom/extensions/uk.co.vedaconsulting.mosaico/CRM/Mosaico/AbDemux.php(128): Civi\API\Provider\MagicFunctionProvider->invoke()
#21 [internal function]: CRM_Mosaico_AbDemux->onSubmitMailing()
#22 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/Civi/API/Provider/WrappingProvider.php(48): call_user_func()
#23 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(156): Civi\API\Provider\WrappingProvider->invoke()
#24 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php(79): Civi\API\Kernel->runRequest()
#25 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/api/api.php(28): Civi\API\Kernel->runSafe()
#26 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Utils/REST.php(288): civicrm_api()
#27 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Utils/REST.php(533): CRM_Utils_REST::process()
#28 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(288): CRM_Utils_REST::ajax()
#29 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem()
#30 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke()
#31 /home/members/mysite/sites/crm.mysite.org/web/wp-content/plugins/civicrm/civicrm.php(1199): CRM_Core_Invoke::invoke()
#32 /home/members/mysite/sites/crm.mysite.org/web/wp-includes/class-wp-hook.php(310): CiviCRM_For_WordPress->invoke()
#33 /home/members/mysite/sites/crm.mysite.org/web/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters()
#34 /home/members/mysite/sites/crm.mysite.org/web/wp-includes/plugin.php(517): WP_Hook->do_action()
#35 /home/members/mysite/sites/crm.mysite.org/web/wp-admin/admin.php(259): do_action()
#36 {main}
```5.68.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4708Memberships by relationship are not created on contact merge2023-10-23T20:45:46ZbrienneMemberships by relationship are not created on contact mergeOverview
----------------------------------------
If two contacts are merged and one has an active membership and the other has active relationships, memberships by relationship are not created for the related contacts.
Reproduction st...Overview
----------------------------------------
If two contacts are merged and one has an active membership and the other has active relationships, memberships by relationship are not created for the related contacts.
Reproduction steps
----------------------------------------
1. Create (or find) two Organization Contacts
* one should have a membership
* one should have at least one relationship of Type 'Employer of'
1. Merge the two Organizations
1. Note that the merged contact has the membership and the relationship, but that the related contact does not have a membership by relationship
Current behaviour
----------------------------------------
Memberships by relationship are not being created for related contacts after a contact merge.
Expected behaviour
----------------------------------------
When contacts with memberships and relationships- such as of Type 'Employer of' - are merged, memberships by relationship should be created for the relevant contacts- i.e. whatever function gets called to create a membership by relationship should be called after contacts are merged, if that contact has a membership.
Environment information
----------------------------------------
* __CiviCRM:__ 5.66https://lab.civicrm.org/dev/core/-/issues/4707[PHP 8.0+?] Empty requires tag in info.xml crashes extension list2023-10-23T20:45:38Zjofranzfranz@systopia.de[PHP 8.0+?] Empty requires tag in info.xml crashes extension listOverview
----------------------------------------
This seems to be working fine on PHP 7.4 tho.
Reproduction steps
----------------------------------------
1. Having an [empty requires tag](https://github.com/Project60/org.project60.mem...Overview
----------------------------------------
This seems to be working fine on PHP 7.4 tho.
Reproduction steps
----------------------------------------
1. Having an [empty requires tag](https://github.com/Project60/org.project60.membership/pull/68/files)
1. Go to: `.../civicrm/admin/extensions?reset=1`
1. See an empty page? Not sure as I have [whoops](https://filp.github.io/whoops/) enabled
Current behaviour
----------------------------------------
```
array_intersect(): Argument #1 ($array) must be of type array, string given
```
Expected behaviour
----------------------------------------
Empty tags should be ignored
Environment information
----------------------------------------
* __Browser:__ _Firefox_
* __CiviCRM:__ _5.65.2_
* __PHP:__ _8.1 (works on 7.4)_
* __CMS:__ _Drupal 9.5.11_
* __Database:__ _Yes :)_
* __Web Server:__ _Apache 2_5.67.0https://lab.civicrm.org/dev/core/-/issues/4706Event Custom Field Overwrite2023-10-19T23:02:35ZguyiacEvent Custom Field Overwrite## Overview
_Please describe your problem or bug in detail._
On custom fields for Events, if you save the record, then leave, then come back in, the custom data doesn't show up in the UI but actually is in the database. Even worse, if ...## Overview
_Please describe your problem or bug in detail._
On custom fields for Events, if you save the record, then leave, then come back in, the custom data doesn't show up in the UI but actually is in the database. Even worse, if you save that record again, the blank fields in the UI overwrite the data in the database. So if you go in to edit the event, and don't notice the blank custom fields, when you save, you will overwrite the custom data and not even know it.
I first noticed this on a client site in WP on 5.66.0, and have confirmed it on wpmaster and d7master on 5.68.alpha1. It doesn't appear to happen on contacts, but I didn't test any other entities.
https://chat.civicrm.org/civicrm/pl/q6jpjss4x7byiqkejar1nbhxkw
## Reproduction steps
## Current behaviour
_What happens currently. Please provide error messages, screenshots or gifs (_[_LICEcap_](http://www.cockos.com/licecap/)_, _[_SilentCast_](https://github.com/colinkeenan/silentcast)_) where appropriate._
```plaintext
```
## Expected behaviour
## Environment information
* **Browser:** _recent chrome and firefox_
* **CiviCRM:** _d7 and wp master 5.68.alpha1, wp 5.66.0_
* **PHP:** 8.1
* **CMS:** _wp and d7_
* **Database:** _MySQL 5_
* **Web Server:** _not sure_
## Comments
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/4705Regression - breakage on quicksearch in conjunction with contact id2023-10-19T21:21:25ZeileenRegression - breakage on quicksearch in conjunction with contact idThis is currently replicable on https://dmaster.demo.civicrm.org/ & intermittently replicable on Civi sites from 5.66 upwards & earlier but with the proviso that I only replicated on earlier (5.65, 5.64) with a db already 'infected' from...This is currently replicable on https://dmaster.demo.civicrm.org/ & intermittently replicable on Civi sites from 5.66 upwards & earlier but with the proviso that I only replicated on earlier (5.65, 5.64) with a db already 'infected' from master
On the demo site
![image](/uploads/9f8ad640c1b5baad4918ff533eb426f4/image.png)
![image](/uploads/ac16e638316e25939d8712fc8032afba/image.png)
![image](/uploads/9e15dd298562998fad9de8f3d65903e2/image.png)
The error occurs when 'id' is in the $_POST
![image](/uploads/4b3506df674d9d5c8ea7d6da183dcc68/image.png)
- with some combo of cache clearing / setting re-setting it switches to contact_id - which does work - I haven't figured out what combo yet
![image](/uploads/f4387184cb6ce03146d6c8728d7cf454/image.png)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/4703Saving a group definition lose the current parent groups2023-10-25T20:49:32ZsamuelsovSaving a group definition lose the current parent groupsTo reproduce:
1. edit a group, add a parent, save -> all good
1. edit a group, don't touch the parent, save -> the parent is lost
Was working in 5.60, doesn't work anymore since at least 5.65 and reproduced in https://dmaster.demo.civic...To reproduce:
1. edit a group, add a parent, save -> all good
1. edit a group, don't touch the parent, save -> the parent is lost
Was working in 5.60, doesn't work anymore since at least 5.65 and reproduced in https://dmaster.demo.civicrm.org5.66.1https://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/4700Email attachments with unicode filename get munged2023-10-13T13:46:38ZJonGoldEmail attachments with unicode filename get mungedOverview
----------------------------------------
If you send an email with an attachment, and the filename has Unicode, the Unicode will be converted to underscores.
Reproduction steps
----------------------------------------
1. Create...Overview
----------------------------------------
If you send an email with an attachment, and the filename has Unicode, the Unicode will be converted to underscores.
Reproduction steps
----------------------------------------
1. Create a new file `Montréal.txt`.
2. Send an email to yourself, attaching the file.
Current behaviour
----------------------------------------
Email attachment is named `Montr_al.txt`.
Expected behaviour
----------------------------------------
Email attachment is named `Montréal.txt`.5.68.0JonGoldJonGoldhttps://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/4697Standalone: civicrm/user path conflicts with existing path to user dashboard2023-11-29T02:10:00ZcolemanwStandalone: civicrm/user path conflicts with existing path to user dashboardThe path `civicrm/user` is declared by the Standalone extension, but it was already in use by core.
See https://lab.civicrm.org/dev/core/-/blob/f04bfacb5ed5131c9d29e8a9c0725c3059caeef0/CRM/Core/xml/Menu/Contact.xml#L213-218The path `civicrm/user` is declared by the Standalone extension, but it was already in use by core.
See https://lab.civicrm.org/dev/core/-/blob/f04bfacb5ed5131c9d29e8a9c0725c3059caeef0/CRM/Core/xml/Menu/Contact.xml#L213-218https://lab.civicrm.org/dev/core/-/issues/4696(5.66 upgrade error) Action Schedule field is too short2023-10-25T20:48:36ZJonGold(5.66 upgrade error) Action Schedule field is too short`civicrm_action_schedule`.`name` is currently `VARCHAR(64)`.
In the upgrade:
`Incremental/sql/5.66.alpha1.mysql.tpl` has the statement:
```
UPDATE `civicrm_action_schedule` a1, `civicrm_action_schedule` a2
SET a2.name = CONCAT(a2.name, ...`civicrm_action_schedule`.`name` is currently `VARCHAR(64)`.
In the upgrade:
`Incremental/sql/5.66.alpha1.mysql.tpl` has the statement:
```
UPDATE `civicrm_action_schedule` a1, `civicrm_action_schedule` a2
SET a2.name = CONCAT(a2.name, '_', a2.id)
WHERE a2.name = a1.name AND a2.id > a1.id;
```
However, the name can quite easily already be 64 characters, so this causes a `data too long` error.
Additionally, `CRM/Upgrade/Incremental/php/FiveSixtySix.php` has the following line:
```
$this->addTask('Make ActionSchedule.name required', 'alterColumn', 'civicrm_action_schedule', 'name', "varchar(64) NOT NULL COMMENT 'physical tablename for entity being joined to discount, e.g. civicrm_event'");
```
So if you manually alter your table, the `varchar(64)` portion of this causes it to break again. I was able to finish the incomplete upgrade via `cv` with `--skip`.5.66.1https://lab.civicrm.org/dev/core/-/issues/4695Deprecated function: Optional parameter $from declared before required parame...2024-01-05T03:43:07ZAndrew WassonDeprecated function: Optional parameter $from declared before required parameter $element## Overview
Deprecated function: Optional parameter $from declared before required parameter $element is implicitly treated as a required parameter in require_once() (line 19 of /sites/all/modules/civicrm/drupal/modules/civicrm_rules/ci...## Overview
Deprecated function: Optional parameter $from declared before required parameter $element is implicitly treated as a required parameter in require_once() (line 19 of /sites/all/modules/civicrm/drupal/modules/civicrm_rules/civicrm_rules.rules.inc).
The deprecated error issue is related to two files in the civicrm_rules sub module.
* line 20 of /civicrm/drupal/modules/civicrm_rules/civicrm_rules.mailing-eval.inc
* line 27 of civicrm/drupal/modules/civicrm_rules/civicrm_rules.contact-eval.inc
_This issue is referenced at:_ https://lab.civicrm.org/dev/core/-/issues/3958#note_152174
## Reproduction steps
1. Provision a new Drupal 7 / CiviCRM site on PHP 8.2 or change an existing site to PHP 8.2
2. Got an error "**Fatal error: Deprecated function: Optional parameter $from declared before required parameter $element is implicitly treated as a required parameter in require_once() (line 19 of /sites/all/modules/civicrm/drupal/modules/civicrm_rules/civicrm\_****rules.rules.inc****).**".
## Environment information
* **CiviCRM:** version 5.66.0 (any version)
* **PHP:** _8.2.x_
* **CMS:** Drupal 7.98 (any Drupal 7 version)
* **Database:** _MySQL 5.7.7/MariaDB 10.4/..._
* **Web Server:** _Apache 2.4/Nginx 1.16/..._
## Comments
The fix is to set the optional parameter $from = NULL to string $from = NULL.
* The sites where I have found this issue all use the Drupal Rules module so this may not impact sites that don't use Drupal Rules in their workflow.
I will create a PR shortly.5.68.0https://lab.civicrm.org/dev/core/-/issues/4694PHP 8.2 Deprecated ${} string interpolation drupal.module file2023-11-06T18:55:40ZAndrew WassonPHP 8.2 Deprecated ${} string interpolation drupal.module file## Overview
_CiviCRM can not be installed or updated on PHP 8.2.x because of a PHP 8.2 Deprecated ${} string interpolation issue with the file at line 1058 of /civicrm/drupal/civicrm.module._
_This issue is referenced at:_ https://lab....## Overview
_CiviCRM can not be installed or updated on PHP 8.2.x because of a PHP 8.2 Deprecated ${} string interpolation issue with the file at line 1058 of /civicrm/drupal/civicrm.module._
_This issue is referenced at:_ https://lab.civicrm.org/dev/core/-/issues/3958#note_152174
## Reproduction steps
1. Provision a Drupal website on PHP 8.2.x
2. Install of update CiviCRM.
3. Got an error "**Fatal error:** _Deprecated ${} string interpolation issue with the file at line 1058 of /civicrm/drupal/civicrm.module._".
## Environment information
* **CiviCRM:** version 5.66.0 (any version)
* **PHP:** _8.2.x_
* **CMS:** Drupal 7.98 (any Drupal 7 version)
* **Database:** _MySQL 5.7.7/MariaDB 10.4/..._
* **Web Server:** _Apache 2.4/Nginx 1.16/..._
## Comments
_Will supply PR shortly._
* How do I add Labels to relate this to PHP 8.2 and Drupal 7?5.68.0https://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/4692Clone command at Manage Contribution Pages doesn't work2023-11-23T07:51:00ZUpperholmeClone command at Manage Contribution Pages doesn't workOverview
----------------------------------------
On the 'Manage Contribution Pages' page at /civicrm/admin/contribute?reset=1 - which is now a packaged search made with Searchkit, there is an option to Clone any listed contribution page...Overview
----------------------------------------
On the 'Manage Contribution Pages' page at /civicrm/admin/contribute?reset=1 - which is now a packaged search made with Searchkit, there is an option to Clone any listed contribution page. Clicking the 'clone' button should presumably refresh the page view and show the user the new list of contribution pages, including the freshly cloned page.
Clicking the button certainly appears to rebuild the page, but no new contribution page is listed. refreshing the page doesn't help, so I'm assuming no new contribution page is created.
Reproduction steps
----------------------------------------
1. Go to 'Manage Contribution Pages' /civicrm/admin/contribute?reset=1
1. Click on the 'clone' button against any listed page.
1. View the refreshed list of pages, which does not include any cloned page.
Expected behaviour
----------------------------------------
I would expect to see my new page, with a name like 'clone of whatever the old page was called'.
Environment information
----------------------------------------
Repeatable in both Firefox and Safari, and on dmaster.