Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-06T20:20:40Zhttps://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/5031Standalone - multi-lingual fatals when accessing OptionValues2024-03-06T15:18:42ZufundoStandalone - multi-lingual fatals when accessing OptionValues@bgm :
> if we enable multi-lingual (tested on 5.72/master), it fatals because it tries to access Option Values before i18n dbLocale seems to have been set (i.e. I see it querying civicrm_option_value and not civicrm_option_value_en_US)...@bgm :
> if we enable multi-lingual (tested on 5.72/master), it fatals because it tries to access Option Values before i18n dbLocale seems to have been set (i.e. I see it querying civicrm_option_value and not civicrm_option_value_en_US).
> It happens immediately after enabling multi-lingual: ex: https://smaster.demo.civicrm.org/civicrm/admin/setting/localization?reset=1
>
> Go to Administer > Localization > Translation. Enable multi-lingual, fatals.
>
> I haven't dug into it, but part of me would be pretty happy to deprecate multi-lingual mode, and not support it in Standalone. I do use it, but there are other ways we could support config translation.https://lab.civicrm.org/dev/core/-/issues/4909Split 'Edit all contacts' permission2024-03-06T10:57:35ZGuillaumeSorelSplit 'Edit all contacts' permissionI jumped into a user case where some admin should be able to edit contacts they're allowed to manage but shouldn't be able to manage tags. After looking inside the documentation, stackexchange and the ACL I discovered that the 'Edit all ...I jumped into a user case where some admin should be able to edit contacts they're allowed to manage but shouldn't be able to manage tags. After looking inside the documentation, stackexchange and the ACL I discovered that the 'Edit all contacts' embeds several sub-permissions like editing the contacts information and also tags or groups. It's everything or nothing within this permission.
I'm not talking about the capability to manage Tags as entity (which as a separate permission) but to manage the use of them.
I think it could be interesting to split this permission with a 'edit all contacts' on the one hand and create a new 'edit contact tags / groups' on the other hand.https://lab.civicrm.org/dev/core/-/issues/3705CiviReport email sending fails if multiple recipient are specified in 'to' field2024-03-05T05:24:43ZKurund JalmiCiviReport email sending fails if multiple recipient are specified in 'to' field### Steps to replicate
1. Create report an instance
2. Configure `Email Delivery Settings`; add multiple emails in `to` field.
3. Configure this report instance to send emails via Scheduled Job
Emails are never sent
## Error in CiviCR...### Steps to replicate
1. Create report an instance
2. Configure `Email Delivery Settings`; add multiple emails in `to` field.
3. Configure this report instance to send emails via Scheduled Job
Emails are never sent
## Error in CiviCRM logs
```bash
[error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => 10006
[message] => Failed to send data [SMTP: Invalid response code received from SMTP server while sending email. This is often caused by a misconfigura
tion in Outbound Email settings. Please verify the settings at Administer CiviCRM >> Global Settings >> Outbound Email (SMTP). (code: 554, response: Tra
nsaction failed: Domain contains illegal character)]
[mode] => 16
[debug_info] =>
[type] => PEAR_Error
[user_info] =>
[to_string] => [pear_error: message="Failed to send data [SMTP: Invalid response code received from SMTP server while sending email. This is often caused by a misconfiguration in Outbound Email settings. Please verify the settings at Administer CiviCRM >> Global Settings >> Outbound Email (SMTP). (code: 554, response: Transaction failed: Domain contains illegal character)]" code=10006 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info=""]
)
```
This happens because multiple emails gets converted in to invalid emails due to `CRM_Utils_Mail::formatRFC822Email()`https://lab.civicrm.org/dev/core/-/issues/4999Imagine a world without CodeGen2024-03-05T04:32:51ZcolemanwImagine a world without CodeGenCurrently we use `CRM_Core_CodeGen` to take our schema/xml files and generate DAO.php, install.sql and uninstall.sql files, which have to be periodically regenerated. This is a minor inconvenience for a core developer, a potential gotcha...Currently we use `CRM_Core_CodeGen` to take our schema/xml files and generate DAO.php, install.sql and uninstall.sql files, which have to be periodically regenerated. This is a minor inconvenience for a core developer, a potential gotcha for an extension developer, and a major coordination difficulty across *all* extensions in `universe` (whenever any aspect of the generated code needs to change).
But what if we didn't have to generate those files? What if we could read schema information directly from the xml (or potentially a different source).
Current Structure:
-----
**Key:** ✍️ Handwritten file | 📠 Generated file
| File | Purpose | In Core | In Extensions |
| --- | --- | --- | --- |
| ✍️ `schema/xml` | Canonical declaration of entity + all metadata | Run `setup.sh -g` | Run `civix generate:entity-boilerplate` |
| 📠 Install sql | Add schema tables | `civicrm.mysql` | `auto_install.sql` |
| 📠 Uninstall sql | Drop schema tables | `civicrm_drop.mysql` | `auto_uninstall.sql` |
| 📠 Entity.php | Declare entity's existence | `AllCoreTables.data.php` | `*.entityType.php` + `entity-types-php` mixin |
| 📠 `CRM/Core/I18n/SchemaStructure.php` | Lists localizable table columns | Seems kinda redundant with other metadata? | Doesn't exist |
| ✍️ `CRM_Core_DAO` | Base class for all generated DAOs | All DAOs extend this class | Extension DAOs also extend core class (makes change-management across `universe` difficult) |
| 📠 `CRM_*_DAO_*` | Generated from the xml file | Must be generated | Must be generated |
The generated DAO file (including stuff it inherits from `CRM_Core_DAO`) serves a variety of purposes:
1. OO class that allows a database table to be used like a php object, e.g.
```
$contact = new CRM_Contact_DAO_Contact();
$contact->first_name = 'Bob';
$contact->save();
```
This is a neat idea and probably ahead of its time, but is basically deprecated now, mostly because, in a relational database, having access to only one table at a time isn't very useful. If it weren't for legacy core & extension code still using this pattern, we could drop it in favor of more robust tools like APIv4.
2. Static methods like `fields()` and `indices()` which return the data from the xml file in php format.
3. Localizes strings, because CodeGen wraps titles and labels in `ts()`.
4. A bunch of other random static methods (e.g. `disableFullGroupByMode()`) which seem like they'd be better-placed in a separate utility class.
New Structure
----------
If we no longer want to generate files and just read from a canonical source, then the main question is, "what should be the canonical source of entity metadata?"
1. **Stick with XML:** Keep the existing xml files but delete the generated stuff. Parse the xml at runtime to get that data.
- Pro: It's already there, no rewrites needed.
- Con: Poor DX (developers don't generally enjoy writing XML files).
- Con: It's very slow (the slowest by far of all the options) so heavy caching would be needed.
- Con: Without generating php files, another method of i18n string extraction would be needed ([such as this](https://github.com/civicrm/civistrings/pull/17)).
2. **DAO Files:** Delete the `schema/xml` files and run everything from the generated DAO files, which going forward will be hand-edited instead of regenerated.
- Pro: DAO files are already there.
- Con: Also poor DX (the boilerplate in those files would not be fun to write/edit by hand).
3. **Somewhere Else:** Move schema info to e.g. json files or better-structured PHP files.
- Pro: DX and performance could be optimized.
- Con: XML files must be rewritten (could be scripted).
- Con: Migration management for core and extensions.
Supporting Dynamic/Virtual Entities
--------
It's also worth keeping in mind that there are now several types of entities that are dynamic & share a DAO:
- Multi-record custom fields
- ECK entities
- SearchKit materialized displays
The DAO structure doesn't cope with this very well, as the assumption has always been 1-1-1 between table, entity & DAO class. But while we're restructuring things let's avoid adding more code that makes this assumption. An ideal DAO from the POV of virtual entities would be an object that takes entity name in its constructor & initializes itself with the appropriately corresponding tablename, fields, and other metadata.https://lab.civicrm.org/dev/user-interface/-/issues/66Add a resets file / section to core CSS. List necessary resets here2024-03-01T23:42:31ZnicolAdd a resets file / section to core CSS. List necessary resets hereOpening this as an issue rather than PR in order to gather sufficient number of resets needed before creating a single place in the CSS folder to put them.
CMS admin themes sometimes clash with Civi's CSS. For e.g. Claro (default admin...Opening this as an issue rather than PR in order to gather sufficient number of resets needed before creating a single place in the CSS folder to put them.
CMS admin themes sometimes clash with Civi's CSS. For e.g. Claro (default admin theme in D9+) does this:
```
td {
height: 4rem;
}
```
which makes Civi tables look like this:
![image](/uploads/b38c89de3e97838a2fc94dd3314dd4d2/image.png)
Instead of
![image](/uploads/d44351e711abbe61b08279ed9f5b73cf/image.png)
(reset with `.crm-container td {height: inherit;}`). These resets will be needed in core and any Civi themes.
Some things are smaller, e.g. the new SearchKit UI on Claro looks like this:
![image](/uploads/b6f81108f635fd89300f1b5be10cde75/image.png)
because of the following non-namespaced CSS that ships in Claro:
```
.panel {
margin-block: 1em 3em;
…
```
which can be reset with putting at the top of Civi's css:
```
.crm-container .panel {
margin-block: 0;
…
```https://lab.civicrm.org/dev/core/-/issues/3912Recreate core screens as Search Displays2024-03-01T22:32:39ZwmortadaRecreate core screens as Search DisplaysSee also dev/core#3761 for the SK/FB roadmap.
This is a meta issue for the work required to recreate many core screens using SearchKit and FormBuilder.
These new screens are in one of three locations:
1. Directly in core ([list](#core...See also dev/core#3761 for the SK/FB roadmap.
This is a meta issue for the work required to recreate many core screens using SearchKit and FormBuilder.
These new screens are in one of three locations:
1. Directly in core ([list](#core-replacements)): these screens replace the old screens, and often the old code is removed. There is no option to revert to the old versions.
2. In the [CiviCRM Administration UI](https://github.com/civicrm/civicrm-core/tree/master/ext/civicrm_admin_ui) extension ([list](#adminui)): these screens replace the old screens but administrators can either disable the extension, or disable individual screens (by removing the URL in FormBuilder). These will eventually become the standard screens and old code removed - but need a bit more testing and verification.
3. In the [CiviCRM Search UI](https://github.com/civicrm/civicrm-core/tree/master/ext/civicrm_search_ui) extension ([list](#searchui)): these screens don't have the full functionality of the screens they will eventually replace. In some cases, new features in SK are needed before they can fully replace existing screens. They are still useful and are a basis for further development. These may eventually migrate into AdminUI.
We welcome contributions from anyone who wants to get involved with this. If you need any help getting started, ask in the \~AdminUI channel on Mattermost.
It builds on the work started by Coleman to create the [CiviCRM Administration UI](https://github.com/civicrm/civicrm-core/tree/master/ext/civicrm_admin_ui) extension. Many more screens were created during the Manchester Sprint in October 2022.
Notes:
1. Join the \~AdminUI channel on Mattermost.
2. If you want to work on any of these, please add your name to the item and keep it updated as work progresses.
3. Look at the screens that have already been converted and try to follow a similar format.
4. The aim is to include all the functionality of the existing screens but without twisting SK in knots to exactly reproduce an existing screen.
5. Each screen will have at least three files: `.aff.html` and `.aff.json` copied from the `<civicrm.files>/ang` directory and `.mgd.php` exported from API Explorer.
6. If you can't reproduce some aspect of an existing screen, create a WIP (Work in Progress) PR and note it below. Someone else may know how to do that, or it may need a new feature adding to SK.
7. Some people found creating the PR harder than creating the new screen. We don't want that to be a barrier to getting these screens converted so if you don't want to create the PR, just [email me](mailto:aidan.saunders@squiffle.uk?subject=%22AdminUI%22) with the 3 files to and I'll do the PR.
8. There are more screens to do than those below. If you want to do something else, please add it to this page.
## AdminUI pages
| Form | URL | Status | PR | Who | Notes |
|------|-----|--------|----|-----|-------|
| Profiles | `civicrm/admin/uf/group` | Merged | [24715](https://github.com/civicrm/civicrm-core/pull/24725) | Alain | |
| Location Types | `civicrm/admin/locationType` | Merged | [24722](https://github.com/civicrm/civicrm-core/pull/24722) | @wmortada | |
| Financial Types | `civicrm/admin/financial/financialType` | Submitted | [24720](https://github.com/civicrm/civicrm-core/pull/24720) | Nicolas | |
| Financial Accounts | `civicrm/admin/financial/financialAccount` | Merged | [24730](https://github.com/civicrm/civicrm-core/pull/24730) | Dave J | |
| Relationship Types | `/civicrm/admin/reltype` | Merged | [24709](https://github.com/civicrm/civicrm-core/pull/24709) | Damilare | |
| Grant Status Options | `/civicrm/admin/options/grant_status` | Submitted | [24729](https://github.com/civicrm/civicrm-core/pull/24729) | Damilare | |
| Grant Type | `/civicrm/admin/options/grant_type` | Submitted | [24729](https://github.com/civicrm/civicrm-core/pull/24729) | Damilare | |
| Option Values | `civicrm/admin/options` | Blocked | | Patrick | To be used for all option values |
| Import/Export Mappings | civicrm/admin/mapping | Submitted | [28509](https://github.com/civicrm/civicrm-core/pull/28509) | @pradeep | |
| Label Formats | civicrm/admin/labelFormats | Done | [28513](https://github.com/civicrm/civicrm-core/pull/28513) | @dewymercerais | |
| Manage Premiums | civicrm/admin/contribute/managePremiums | Submitted | [28540](https://github.com/civicrm/civicrm-core/pull/28540) | @AllenShaw | |
| Personal Campaign Pages | civicrm/admin/pcp | Done | [29541](https://github.com/civicrm/civicrm-core/pull/29541) | @kcristiano | |
| Print Page (PDF) Formats | civicrm/admin/pdfFormats | done | [28520](https://github.com/civicrm/civicrm-core/pull/28520) | @usha.makoa | |
| Settings - SMS Provider | civicrm/admin/sms/provider | Submitted | [28512](https://github.com/civicrm/civicrm-core/pull/28512) | @pradeep | |
| Event Templates | civicrm/admin/eventTemplate | Submitted | [28514](https://github.com/civicrm/civicrm-core/pull/28514) | @pradeep | |
| Event Name Badge Layouts | civicrm/admin/badgelayout | Done | [28518](https://github.com/civicrm/civicrm-core/pull/28518) | @dewymercerais | |
| Settings - Payment Processor | civicrm/admin/paymentProcessor | done | | | |
| Headers, Footers, and Automated Messages | civicrm/admin/component | | [28484](https://github.com/civicrm/civicrm-core/pull/28484) | @kcristiano @19ATF72 | |
| Message Templates | civicrm/admin/messageTemplates | done | | | |
| Membership Types | civicrm/admin/member/membershipType | WIP | | @ayduns | |
| Membership Status Rules | civicrm/admin/member/membershipStatus | Done | [28480](https://github.com/civicrm/civicrm-core/pull/28480) | @usha.makoa | |
| Campaigns | the search doesn't exist in core (the dashboard does and is already in SearchUI) | abandonned | | | |
| Discounts | civicrm/cividiscount | | | Coleman | [CiviDiscount MR](https://lab.civicrm.org/extensions/cividiscount/-/merge_requests/284 "Convert all tables to SearchKit displays") |
| Dedupe Exceptions | civicrm/dedupe/exception | | | | see [comment](https://github.com/civicrm/civicrm-core/pull/25522#issue-1575266329) |
| Contact Types | civicrm/admin/option/subtype | done | | | |
| Joblogs | civicrm/admin/joblog | Merged | [26732](https://github.com/civicrm/civicrm-core/pull/26732) | @ayduns | |
| Mail Accounts | civicrm/admin/mailSettings | Merged | [26733](https://github.com/civicrm/civicrm-core/pull/26733) | @ayduns | Does not yet support oauth-client method to add mail accounts |
| Participant Status | civicrm/admin/participant_status | | | @ayduns | see [conditional in-place edit](https://lab.civicrm.org/dev/core/-/issues/4406 "SearchKit: make 'inplace edit' conditional") |
| Payment Processor Type | civicrm/admin/paymentProcessorType | | | | Doesn't exist in menus. Don't think this is needed as processor types added by extensions, not UI. |
| Date Preferences | civicrm/admin/setting/preferences/date | | [28483](https://github.com/civicrm/civicrm-core/pull/28483) | @pradpnayak | |
| ACL Assign Users to Roles | civicrm/admin/acl/entityrole | Merged | [26925](https://github.com/civicrm/civicrm-core/pull/26925) | @ayduns | |
More challenging:
| Form | URL | Status | PR | Who | Notes |
|------|-----|--------|----|-----|-------|
| Message Templates | civicrm/admin/messageTemplates | On hold | [24981](https://github.com/civicrm/civicrm-core/pull/24981) | @ayduns | There is a new Message Admin Core extension. See comments on PR |
| Option Groups/Values | civicrm/admin/options | In progress | [25387](https://github.com/civicrm/civicrm-core/pull/25387) | @colemanw | |
| Schedule Reminders | civicrm/admin/scheduleReminders | Merged | [26896](https://github.com/civicrm/civicrm-core/pull/26896) | @colemanw | |
| Settings - Scheduled Jobs | civicrm/admin/job | Merged | [26060](https://github.com/civicrm/civicrm-core/pull/26060) | @ayduns | |
| Price Sets | civicrm/admin/price | WIP | | @ayduns | |
| Price set fields | civicrm/admin/price/field | WIP | | @ayduns | |
| Manage Contribution Pages | civicrm/admin/contribute | Merged | [24937](https://github.com/civicrm/civicrm-core/pull/24937) | @ayduns | |
| Manage Events | civicrm/event/manage | Merged | [28476](https://github.com/civicrm/civicrm-core/pull/28476) | @alainb (Alain Benbassat) | |
| CiviCRM Reports | civicrm/report/list | WIP - need PR (see wip [28511](https://github.com/civicrm/civicrm-core/pull/28511)) to add a pseudo field with components list | [28480](https://github.com/civicrm/civicrm-core/pull/28480) | @usha.makoa | |
| Create New Report from Template | civicrm/admin/report/template/list | | | | The Report Templates Entity lacks in SK |
| Manage Groups | civicrm/group | Merged | [26261](https://github.com/civicrm/civicrm-core/pull/26261) | @samuelsov | |
Other Option Values (when main Option Values is done):
| Form | URL | Status | PR | Who | Notes |
|------|-----|--------|----|-----|-------|
| Accepted Credit Cards Options | civicrm/admin/options/accept_creditcard | | | | |
| Activity Type Options | civicrm/admin/options/activity_type | | | | |
| Addressee Type Options | civicrm/admin/options/addressee | | | | |
| Communication Style Options | civicrm/admin/options/communication_style | | | | |
| Custom Search Options | civicrm/admin/options/custom_search | | | | |
| Email Greeting Type Options | civicrm/admin/options/email_greeting | | | | |
| From Email Address Options | civicrm/admin/options/from_email_address | | | | |
| Gender Options | civicrm/admin/options/gender | | | | |
| Individual contact suffixes Options | civicrm/admin/options/individual_suffix | | | | |
| Instant Messenger (IM) screen-names Options | civicrm/admin/options/instant_messenger_service | | | | |
| Languages Options | civicrm/admin/options/languages | | | | |
| Mobile Phone Providers Options | civicrm/admin/options/mobile_provider | | | | |
| Payment Methods Options | civicrm/admin/options/payment_instrument | | | | |
| Phone Type Options | civicrm/admin/options/phone_type | | | | |
| Postal Greeting Type Options | civicrm/admin/options/postal_greeting | | | | |
| Preferred Communication Method Options | civicrm/admin/options/preferred_communication_method | | | | |
| Soft Credit Types Options | civicrm/admin/options/soft_credit_type | | | | |
| Website Type Options | civicrm/admin/options/website_type | | | | |
| Word Replacements | civicrm/admin/options/wordreplacements | | | | |
## SearchUI
These searches should be placed in the SearchUI extension rather than AdminUI. When the new search fully replaces the functionality of the core page it can override the existing URL. Otherwise, create an alternate URL and place a menu entry under Experimental.
<table>
<tr>
<th>Form</th>
<th>URL</th>
<th>Status</th>
<th>PR</th>
<th>Who</th>
<th>Notes</th>
</tr>
<tr>
<td>Find Contacts</td>
<td>civicrm/contact/search</td>
<td>Merged</td>
<td>
[26381](https://github.com/civicrm/civicrm-core/pull/26381)
</td>
<td>
@samuelsov
</td>
<td>
</td>
</tr>
<tr>
<td>Advanced Search</td>
<td>civicrm/contact/search/advanced</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>it doesn't make sense since we can create appropriate searches with SK</td>
</tr>
<tr>
<td>Find Contributions</td>
<td>civicrm/contribute/search</td>
<td>Merged, needs more work</td>
<td>
[26746](https://github.com/civicrm/civicrm-core/pull/26746)
</td>
<td>
@ayduns
</td>
<td>
</td>
</tr>
<tr>
<td>Find Mailings</td>
<td>civicrm/mailing civicrm/mailing/browse/scheduled civicrm/mailing/browse/archived civicrm/mailing/browse/unscheduled</td>
<td>WIP</td>
<td>
[26532](https://github.com/civicrm/civicrm-core/pull/26532)
</td>
<td>
@samuelsov
</td>
<td>
</td>
</tr>
<tr>
<td>Find Memberships</td>
<td>civicrm/membership/search</td>
<td>Submitted</td>
<td>
[29064](https://github.com/civicrm/civicrm-core/pull/29064)
</td>
<td>
@jitendra
</td>
<td>
</td>
</tr>
<tr>
<td>Find Participants</td>
<td>civicrm/event/search</td>
<td>Done</td>
<td>
[28477](https://github.com/civicrm/civicrm-core/pull/28477)
</td>
<td>
@breheret
</td>
<td>
it's staying :
- Add the 'fee level' field which I was unable to put
- Add custom group fields linked to an event/participant
- Add actions that are not native to Searchkit:
- Cancel registration
- Email - send now
- Group - add contacts
- Group - create smart group
- Name badges - print
- PDF letter - print for participants
- Participant status - change
- Print selected rows
- Update multiple participants
</td>
</tr>
<tr>
<td>Find Activities</td>
<td>civicrm/activity/search</td>
<td>Done</td>
<td>
[28480](https://github.com/civicrm/civicrm-core/pull/28480)
</td>
<td>
@usha.makoa
</td>
<td>
</td>
</tr>
<tr>
<td>Cases Dashboard</td>
<td>civicrm/case</td>
<td>Done</td>
<td>
</td>
<td>
@ayduns and @simon.hermann
</td>
<td>
https://lab.civicrm.org/extensions/casesummary/-/merge_requests/3
</td>
</tr>
<tr>
<td>Single Case View</td>
<td>civicrm/contact/view/case</td>
<td>WIP</td>
<td>
</td>
<td>
@simon.hermann
</td>
<td>
</td>
</tr>
</table>
## Core replacements
| Form | URL | Status | PR | Who | Notes |
|------|-----|--------|----|-----|-------|
| Contact summary: Notes tab | civicrm/note | Merged | [27610](https://github.com/civicrm/civicrm-core/pull/27610) | @colemanw | |
| Contact summary: Relationships tab | civicrm/contact/view/rel | Merged | [27701](https://github.com/civicrm/civicrm-core/pull/27701) | @colemanw | |
| Campaign Dashboard | civicrm/campaign, civicrm/petition, civicrm/survey | Merged | [27271](https://github.com/civicrm/civicrm-core/pull/27271) | @colemanw | |
| Contact summary: Membership tab | civicrm/ | Merged | [28810](https://github.com/civicrm/civicrm-core/pull/28810) | @jitendra | |
| Contact summary: Event tab | civicrm/ | Submitted | [29570](https://github.com/civicrm/civicrm-core/pull/29570)| @guyiac | |https://lab.civicrm.org/dev/core/-/issues/4924CiviReport: Contribution Detail Report Joining Incorrectly on civicrm_note2024-03-01T20:08:18Zcrawford.morganCiviReport: Contribution Detail Report Joining Incorrectly on civicrm_noteOverview
----------------------------------------
When 'Contribution Note' is selected as a column in a Contribution Detail report, the join is treated as required and all contributions in the results without notes are filtered out.
Thi...Overview
----------------------------------------
When 'Contribution Note' is selected as a column in a Contribution Detail report, the join is treated as required and all contributions in the results without notes are filtered out.
This issue occurs when using the 'Contribution Detail' report, 'Extended Report - Contributions' report, and 'Extended Report - Bookkeeping with extra fields' report.
Thankfully, reports created in SearchKit function properly (all contributions are returned in the results) and contribution search exports are also functioning properly (including 'Contribution Note' in the exported fields does not affect the records exported).
Reproduction steps
----------------------------------------
1. example.com/civicrm/report/contribute/detail?reset=1
2. View results with Columns > Contribution Note toggled off
3. Toggle Contribution Note on, run report again, note that fewer records are returned
Environment information
----------------------------------------
* CiviCRM: 5.69.2
* PHP:8.1.27
* Drupal: 7.99
* MySQL: 8.0.33
Comments
----------------------------------------
This only recently became an issue after making a minor upgrade to 5.69.2https://lab.civicrm.org/dev/core/-/issues/4462Transactional Authentication (Page-level auth tokens)2024-03-01T19:59:17Zaydunsaidan.saunders@squiffle.ukTransactional Authentication (Page-level auth tokens)Overview
----------------------------------------
Improve the support for transactional approaches in the authentication framework. The current implementation of authentication tokens is more suited to a portal approach than a transacti...Overview
----------------------------------------
Improve the support for transactional approaches in the authentication framework. The current implementation of authentication tokens is more suited to a portal approach than a transactional one.
See [this snippet](https://lab.civicrm.org/-/snippets/92 ) for the background describing how to use authenticated links with forms. This documents the resulting conversation with @totten [here](https://chat.civicrm.org/civicrm/pl/trubx7xwui878nsz3w6ujmf6oc):
(@totten says:) I'd like some language to describe two ways of approaching customized UX for constituents.
- Hypothetical scenario
- You send an email 12 months after a prior donation. You thank the donor for the previous contribution. The message includes some links to update communication preferences, browse past donations, or make a new donation.
- UX Approaches
1. **Transactional Approach / One form at a time / Strict Pageflow / Page-Level Auth**: The email has 3x hyperlinks. Each goes to different form/page. Each link has diff auth code (which confers access to exactly one form).
2. **Portal Approach / Multiple forms at discretion / Open Pageflow / Session-Level Auth**: The email has 3x hyperlinks. All go to pages within the same portal. The user opens the first page which takes their interest. On that page, there are more links (eg via prose or navbar) to go checkout the others.
I don't know a good/simple way to say that one is better than the other. but they are different. I suspect there's some Venn diagram of organizational-scenarios (some better suited to 1; some to 2; some to either 1 or 2)
The current auth-code mechanism is better for "Portal Approach/Open Pageflow" -- and it's worse for Transactional Approach/Strict Pageflow"
(that's not b/c "Open Pageflow" is better -- but at the time of its writing, it was the easier one to support)
From a low-level POV, the auth-codes for them would differ like this:
- For portal/open pageflow, it generates this token -- which is basically a login-token
- -The custom forms use "Role-based" security-(Maybe either security model is ok in this context...)
- For transactional/strict pageflow, you might expect...
- It needs a fine-grained token like this (pseudocode)
```
$bearerToken = "Bearer " . $jwt->encode([
'exp' => $expires,
'sub' => "cid:" . $contactId,
'scope' => 'api4',
'api4.whitelist' => [
['Afform', 'prefill', ['name' =>'xyz']],
['Afform', 'submit', ['name' =>'xyz']],
]);
```
- In PHP, need a mechanism to accept those tokens
- In JS/HTML, need a mechanism to relay that token
- The custom forms use "Form-based" security
See also
--------
- #4463: Authentication tokens: session already active - same user
- #4464: Authentication tokens: session already active - different userhttps://lab.civicrm.org/dev/core/-/issues/5041Make Font Awesome icons more accessible2024-03-01T00:00:50ZnicolMake Font Awesome icons more accessibleIcon fonts aren't accessible by default as, unlike images, they don't have an alt description.
Updating this issue following feedback from @mthompson in the [accessibility channel](https://chat.civicrm.org/civicrm/pl/pa1hs9qsnty75bhb9qy...Icon fonts aren't accessible by default as, unlike images, they don't have an alt description.
Updating this issue following feedback from @mthompson in the [accessibility channel](https://chat.civicrm.org/civicrm/pl/pa1hs9qsnty75bhb9qy54j715w).
We started looking at [Font Awesome's recommendation](https://fontawesome.com/docs/web/dig-deeper/accessibility) to distinguish between icons that are 'decorative', ie not useful and screen readers can ignore, hidden with `aria-hidden="true"`; vs 'semantic', this is meaningful and important, e.g. a bookmark icon.
However, @mthompson said "icons are not really decorative elements (which are commonly excluded). They are functional... Even with decorative it requires a good understanding of what needs to be included and what should be hidden, depending on context and purpose of the decorations. A good rule of thumb is to question why a particular graphic is there and would hiding it be discriminatory or helpful."
I turned then to the [WCAG guidelines on icons](https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA24) (should have started there) and they don't recommend using `aria-hidden="true"`. They instead suggest `role="img"`with `aria-label`, e.g. `<span class="icon icon-email" role="img" aria-label="Email"></span>`.
This isn't what Civi docs or help icon classes do. So this issue has three steps:
- [ ] update the docs, to suggest best practice for icons: https://docs.civicrm.org/dev/en/latest/framework/ui/#icons
- [ ] update the [icon helper functions](https://docs.civicrm.org/dev/en/latest/framework/ui/#icon-helper-functions) that auto-generate icon markup
- [ ] bulk update icons in the Civi UI. It may be that the font-awesome name is helpful in most instances so this could be done by script… e.g. turning `<i class="crm-i fa-birthday-cake" aria-hidden="true"></i>` into `<span class="crm-i fa-birthday-cake" role="img" aria-label="birthday cake"></span>` (emphasis isn't supported for aria-label).https://lab.civicrm.org/dev/core/-/issues/5043Ability to set font type, font size and line spacing as default2024-02-29T16:43:58Zaydunsaidan.saunders@squiffle.ukAbility to set font type, font size and line spacing as default(From a user at a visibility charity.)
When you create a new activity, the text box for the activity defaults to sand-serif and 13 point.
It would be beneficial to have the ability to set a default font type and size, along with defaul...(From a user at a visibility charity.)
When you create a new activity, the text box for the activity defaults to sand-serif and 13 point.
It would be beneficial to have the ability to set a default font type and size, along with default line spacing, for all text boxes.
For example, we mandate Arial, 14 pt and 1.5 line spacing for electronic communications. That’s what we would like to have a standard on our version of CiviCRM. Having the ability to set these as default on CiviCRM saves workers from having to manually change font type and size when using the activity details box.
I don’t think there is any way to set line spacing in Civi. This would be a much-needed addition, if possible.https://lab.civicrm.org/dev/core/-/issues/4986Montreal Sprint Topics2024-02-28T23:28:14ZcolemanwMontreal Sprint TopicsBrainstorming ideas for the Montreal Sprint
- Afform testing. Build on [Dave D's extension](https://lab.civicrm.org/extensions/afformminktests)
- Accessibility improvements: priorities may include
- accordion overhaul (#3294 / [dev/...Brainstorming ideas for the Montreal Sprint
- Afform testing. Build on [Dave D's extension](https://lab.civicrm.org/extensions/afformminktests)
- Accessibility improvements: priorities may include
- accordion overhaul (#3294 / [dev/user-interface#67](https://lab.civicrm.org/dev/user-interface/-/issues/67))
- accordions: review [#29533](https://github.com/civicrm/civicrm-core/pull/29533)
- accordions: JS fixes for [#29448](https://github.com/civicrm/civicrm-core/pull/29448)
- select2 upgrade/replacement (#3292)
- ensure all fields have labels (see [testing by mthompson](https://chat.civicrm.org/civicrm/pl/un7ajre7mbyc3fis4qebnczpse) on MM)
- ensure tabs are accessible
- ensure pop-ups (dialogs, notifications) are accessible
- ensure date fields are accessible
- ensure [validation errors](https://chat.civicrm.org/civicrm/pl/seqg55bm4fn58eaybqaz5e7kcr) use best practices
- Improve loading of SK/FormBuilder content client-side (bundle requests to minimize Civi bootstrap cycles)
- Placing fields in a form that are not saved to Civi (but are recorded in `civicrm_afform_submission`)
- UX improvements to FormBuilder
- Keyboard navigation of edit-in-place SK displays (and other afforms?) -- and accessibility more broadly?
- Making FormBuilder field placement more flexible (independent of container)
- Use the Queue system for SearchKit exports
- [Open AdminUI PRs](https://github.com/civicrm/civicrm-core/pulls?q=adminui+OR+admin_ui+OR+%22admin+ui%22+is%3Apr+is%3Aopen)
- [Open Afform/SK/FB PRs](https://github.com/civicrm/civicrm-core/pulls?q=afform+OR+searchkit+OR%22search+kit%22+OR+formbuilder+OR+%22form+builder%22+is%3Apr+is%3Aopen+)https://lab.civicrm.org/dev/core/-/issues/5033Fatal error visiting event registration page with a disabled pricefield2024-02-28T17:30:52Zmagnolia61Fatal error visiting event registration page with a disabled pricefieldOverview
----------------------------------------
Opening a registration page with a priceset with one of the pricefields disabled results in a fatal error.
TypeError: Argument 1 passed to CRM_Event_Form_Registration::getUsedSeatsCount(...Overview
----------------------------------------
Opening a registration page with a priceset with one of the pricefields disabled results in a fatal error.
TypeError: Argument 1 passed to CRM_Event_Form_Registration::getUsedSeatsCount() must be of the type int, null given, called in /var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Event/Form/Registration.php on line 956 in CRM_Event_Form_Registration->getUsedSeatsCount() (line 1040 of /var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Event/Form/Registration.php).
The problem for us is somewhere in the function isOptionFullID.
Something in our priceset does not resolve to valid value for $optId = $option['id'];
when from IsOptionFullID the function getUsedSeatsCount is called it results in an error because it expects an int value for priceFieldValueID
protected function getUsedSeatsCount(int $priceFieldValueID) : int {
Reproduction steps
----------------------------------------
1. An event has a priceset with one of the pricefields disabled
2. Opening the registration page results in a fatal error
Current behaviour
----------------------------------------
![image](/uploads/041bb8c19666fc3f99c3f5bec78606bb/image.png)
![image](/uploads/2ff1b9c96e300515694d0a6930409328/image.png)
Expected behaviour
----------------------------------------
The registration page would show, with the pricefield disabled
Environment information
----------------------------------------
Current master / sandbox
Comments
----------------------------------------
My limited detective and coding skills enable me to reach this far, I have no clue on where to search further and what piece of code is the root cause of this.5.71.0https://lab.civicrm.org/dev/user-interface/-/issues/58Make a new theme to ship with Civi2024-02-28T17:20:02ZnicolMake a new theme to ship with CiviIn parallel to documenting Civi's Markup in the ThemeTest extension (#56) and agreeing the best markup patterns (#57), produce a new theme to ship with CiviCRM to replace the 15-year-old Greenwich theme.
After extensive discussion @artf...In parallel to documenting Civi's Markup in the ThemeTest extension (#56) and agreeing the best markup patterns (#57), produce a new theme to ship with CiviCRM to replace the 15-year-old Greenwich theme.
After extensive discussion @artfulrobot and I (who each produce a theme - [Aah](https://github.com/artfulrobot/aah) and [Finsbury Park](https://civicrm.org/extensions/finsbury-park-cross-cms-admin-theme)) are deliberately trying to ignore UI specific questions (fonts? colours? flat? shadows? round-corners?) but instead on making those decisions something trivial to change later (and would obviously make them in discussion with the community).
This themes' primary goal is to give Civi a theme backend that will support not just 2023/24's UI trends (shadowy, vs flat, vs skewmorphic), but the trends of the next 20 years. As well as supporting all 7 Civi versions (Backdrop, Drupal 7 with Seven, Drupal 9+ with Claro, Joomla 3, Joomla 4, Standalone, WordPress), the new theme aims to follow several principles:
### Wide use of CSS Variables
Use [CSS Custom Properties](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties) (aka CSS Variables) to make it quick to re-theme. In principle this could make it viable to have a set of Custom property declarations to make the theme look closer to Shoreditch for those whose training materials require that, or for those who need to match a CMS UI or organisation intranet design guidelines.
A test of CSS Custom Properties being used in this way is [currently shipping with the login](https://lab.civicrm.org/extensions/standaloneusers/-/blob/main/templates/CRM/Standaloneusers/Page/Login.tpl) page markup for [CiviCRM Standalone](https://civicrm.org/blog/josh/civicrm-without-cms-welcome-back-standalone). In the screengrab below you can see the three variable arrays for three different UI's
![image](/uploads/d65e77cf87c1208ab0b88af0d515dc35/image.png)
### Bootstrap Subset
Use a Bootstrap subset to continue to support the Bootstrap 3 class names & markup patterns currently in use in post-Shoreditch components (API Explorer, SearchKit, Form Builder, Mosaico, etc). This does not mean Bootstrap 3 as a whole needs to be supported/bundled; and some of Bootstrap 4/5 can be used - but the full Bootstrap 3 or 5 bundle isn't needed.
### Accessibile, responsive, small
Standards in accessibility have evolved fast. Just taking base font-size - the current standard practice is to let the browser define this, with a default of 16px and scale every page font in proportion using Rems. However, in Bootstrap 3: HTML is 10px, body is 14px, all sizes are set in pixels. WordPress and Joomla 3 are worse: both have 13px body size, same as the Seven admin theme on Drupal 7 and 8. Bootstrap 4 & 5, Backdrop, Joomla 4 and Drupal 9 Claro theme get it right: body is 1rem, inheriting pixel size from browser (aka 16px). But it’s an extra complexity for Civi's cross-CMS theming. To understand why this is so important, Rich made a demo: https://artfulrobot.uk/lil/about-rems/.
Mobile and tablet support needs to be added as far as possible.
The theme's filesize should be kept as small as possible within the various constraints described here.
### Structure
Structure the theme to separate style definitions for Style Guide approved markup patterns (#57) and the legacy support for (some of) the older patterns identified in #56, aka 'Civi hacks'. The CSS also needs a CMS Hacks section to handle CMS-specific quirks which often change with new CMS themes, e.g. Drupal 9's Claro). A possible structure below
![image](/uploads/8bd26d331c8a73c8f9f3a54059e8ee07/image.png)
### Separate front theme?
CiviCRM on the front-end has different needs to the backend. Buttons need to match the parent front-end theme style and there's a number of ways to do this, from having separate CSS Variables for front-end pages that users can configure, to having a minimalist front-end theme that inherits more from the parent theme. This will be looked at subject to time and progress of other goals, for now there is a prototype CSS Variable led, minimalist front-end theme that inherits more of a front-end theme while letting the user configure some defaults (ie button colour/size): [Front](https://lab.civicrm.org/nicol/front/-/tree/main).
Related issue: https://lab.civicrm.org/dev/user-interface/-/issues/46. Related [Wiki page](https://lab.civicrm.org/dev/user-interface/-/wikis/DINO:-New-theme(s)).Improve Civi's front-endhttps://lab.civicrm.org/dev/core/-/issues/5034Schedule Reminders task for Events fail to complete when Event tokens used in...2024-02-28T12:49:12ZmarcusjwilsonSchedule Reminders task for Events fail to complete when Event tokens used in combination with "Also include" ContactsOverview
----------------------------------------
When Scheduled Reminders are set up for an Event in CiviCRM, and the content of that email includes Tokens relating to the Event (Event Title, Start Date, etc.) AND the user includes addi...Overview
----------------------------------------
When Scheduled Reminders are set up for an Event in CiviCRM, and the content of that email includes Tokens relating to the Event (Event Title, Start Date, etc.) AND the user includes additional Contacts to include in the Scheduled Reminder (in the "Also include" field), this breaks the Scheduled Reminder scheduled task, and it fails to complete.
Reproduction steps
----------------------------------------
1. From an event, set up a Scheduled Reminder to send based on the Event, i.e. 24 hours before the Start Date
2. In the body content of the Scheduled Reminder email, include one or more Tokens related to the Event (Event Title, Event Start Date)
3. In the "Limit or Add Recipients" field for the Scheduled Reminder "Also include" a Contact who is NOT registered as a Participant for the given event
Current behaviour
----------------------------------------
When the scenario above is in place, Scheduled Reminder task trigger by the CiviCRM Cron starts to fail and not complete.
Expected behaviour
----------------------------------------
Scheduled Reminder tasks should continue to run, complete and include the additional Contacts in the Reminder email as well as the Event Participants.
Environment information
----------------------------------------
* __CiviCRM:__ 5.64.4
* __PHP:__ _7.4/8.0__
* __CMS:__ _WordPress 6.4.3_
Comments
----------------------------------------
Tested and reproduced on production site and on a clean Civi+WP site using CiviBuild in test CiviCRM site.https://lab.civicrm.org/dev/core/-/issues/5028Add CKEditor/WYSIWYG to the Event Confirmation Email Text Field2024-02-28T12:47:28ZpbarmakAdd CKEditor/WYSIWYG to the Event Confirmation Email Text FieldPer a discussion with Eileen, it would be great to finally get the Confirmation Email Text field of Event Online Registrations to use CKEditor. That will allow admins to create much nicer confirmation emails (with embedded graphics and b...Per a discussion with Eileen, it would be great to finally get the Confirmation Email Text field of Event Online Registrations to use CKEditor. That will allow admins to create much nicer confirmation emails (with embedded graphics and branding) without the need to learn HTML. Given the Registration Screen Introductory Text and Thank-you Screen text both have this option, it seems like a good idea to also have it for the confirmation email.https://lab.civicrm.org/dev/core/-/issues/5027Event Confirmation Email Text Token Should be Set as text/html2024-02-28T12:46:59ZpbarmakEvent Confirmation Email Text Token Should be Set as text/htmlPer a chat with Eileen and Seamus, adding a ticket here. The Event confirmation email text is currently not rendering any input HTML tags. It seems this is because the token is not set as "text/html".
Seamus recommended changing https:/...Per a chat with Eileen and Seamus, adding a ticket here. The Event confirmation email text is currently not rendering any input HTML tags. It seems this is because the token is not set as "text/html".
Seamus recommended changing https://github.com/civicrm/civicrm-core/blob/master/CRM/Event/Tokens.php#L239 from this:
```
else {
$tokens[$fieldName]['text/plain'] = $event[$fieldName];
}
```
to this:
```
else {
$type = ($fieldName === 'confirm_email_text' ? 'text/html' : 'text/plain');
$tokens[$fieldName][$type] = $event[$fieldName];
}
```
For my testing, I just added this line around line 227:
`$tokens['confirm_email_text']['text/html'] = $event['confirm_email_text'];`
Either of those seem to solve the issue, converting the value of that field to actual html code.https://lab.civicrm.org/dev/core/-/issues/5022MailingEventSubscribe Error2024-02-28T12:46:24ZjmargrafMailingEventSubscribe ErrorOverview
----------------------------------------
MailingEventSubscribe does result in an error message
Reproduction steps
----------------------------------------
1. Check the ID of an existing mailing list group (eg. 60)
2. Open AP...Overview
----------------------------------------
MailingEventSubscribe does result in an error message
Reproduction steps
----------------------------------------
1. Check the ID of an existing mailing list group (eg. 60)
2. Open API-Explorer
3. Send API-Request:
```
$result = civicrm_api3('MailingEventSubscribe', 'create', [
'group_id' => 60,
'email' => "test@example.com",
]);
```
4. Got Error Message:
```
{
"error_code": 0,
"entity": "MailingEventSubscribe",
"action": "create",
"is_error": 1,
"error_message": "Failed to find key by ID or tag (I2s19RqQP0fDuuRcyoyhUhRQiAY)"
}
```
Current behaviour
----------------------------------------
Error Message: "error_message": "Failed to find key by ID or tag (I2s19RqQP0fDuuRcyoyhUhRQiAY)"
Expected behaviour
----------------------------------------
Subscribe to Mailing-List
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ _Firefox 59.0.1/Chrome 78.0.3904/Safari 13_
* __CiviCRM:__ 5.69.5
* __PHP:__ 8.1
* __CMS:__ Drupal 10.2.3
* __Database:__ MariaDB
* __Web Server:__ Apachehttps://lab.civicrm.org/dev/core/-/issues/3301Contrast ratios2024-02-28T11:51:33ZJoeMurrayContrast ratiosWCAG 2.0 specifies various minimum contrast ratios between foreground and background for different sizes of fonts, and for bolded and non-bolded fonts [https://www.w3.org/TR/WCAG20-TECHS/G18.html](https://www.w3.org/TR/WCAG20-TECHS/G18.h...WCAG 2.0 specifies various minimum contrast ratios between foreground and background for different sizes of fonts, and for bolded and non-bolded fonts [https://www.w3.org/TR/WCAG20-TECHS/G18.html](https://www.w3.org/TR/WCAG20-TECHS/G18.html).
> ...Priority 2 (AA), and Priority 3 (AAA). Whether or not you need to reach an AAA conformance depends on your target audience. Read more about this [on the w3 site](http://www.w3.org/TR/2005/WD-WCAG20-20051123/intro.html#conformance). For large text (over 18 points) the contrast ratio for AA is 3:1 and for AAA 5:1. For small text it's 5:1 for AA and 7:1 for AAA. ([http://www.colorsontheweb.com/Color-Tools/Color-Contrast-Analyzer](http://www.colorsontheweb.com/Color-Tools/Color-Contrast-Analyzer))
More exact ratios and translations of font sizes to px directly from the WCAG first mentioned for bold and non-bold text are:
* **BOLD and < 14pt (18.5px):** 7:1 contrast ratio
* Not bold and < 18pt (24px): 7:1 contrast ratio
*
* **BOLD and >= 14pt (18.5px):** 4.5:1 contrast ratio
* Not bold and >= 18pt (24px): 4.5:1 contrast ratio
Using the contrast analyzer provided on the page above, the current Shoreditch contrast ratios are not sufficient in some contexts.
For example, on pages like New Contact and New Activity we get the following ratios:
Blue font #2786c2 on tan #efefe5 in 13px: 3.44:1 (below 5:1)
Dimmed grey #999999 on offwhite #fff in 13px: 2.85:1 (below 5:1)
![2018-12-04_09-16-41](/uploads/efe32b9def1089f434b0cf1c11ef1b6e/2018-12-04_09-16-41.png)
![2018-12-04_09-33-52](/uploads/171119a46775a677bd44664497507def/2018-12-04_09-33-52.png)
![2018-12-04_09-51-12](/uploads/1a9006ebddb3d210f2b326d41d29f8cc/2018-12-04_09-51-12.png)
We should meet a 5:1 ratio for all text < 18pt.https://lab.civicrm.org/dev/core/-/issues/4237Count is inacurate in Find and Merge Duplicates2024-02-27T01:12:33ZStoobCount is inacurate in Find and Merge DuplicatesIn the attached example has only 800 contacts in the entire Civi although the same person has **several _dozen_ duplicates of themselves**, for whatever reason. The side effect is what appears to be an exponentially inaccurate duplicate ...In the attached example has only 800 contacts in the entire Civi although the same person has **several _dozen_ duplicates of themselves**, for whatever reason. The side effect is what appears to be an exponentially inaccurate duplicate count as well as in the batch merge screen.
![du](/uploads/c74e365a75d2fe01fcca2c39f07b1579/du.png)
![batcha](/uploads/46f2a517bbabadbd953c9b8c7e05661e/batcha.png)