Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-12-02T04:28:01Zhttps://lab.civicrm.org/dev/core/-/issues/4367Apiv4 Order api2023-12-02T04:28:01ZeileenApiv4 Order api
There is general agreement that the biggest issue with the v3 api is the confusing arrays it requires. My preference in fact is for a fairly non-standard Order api - ie
```
Order::create()
->setContributionParameters([
'conta...
There is general agreement that the biggest issue with the v3 api is the confusing arrays it requires. My preference in fact is for a fairly non-standard Order api - ie
```
Order::create()
->setContributionParameters([
'contact_id' => 56,
'financial_type_id:name' => 'Donation',
])
->addLineItem([
'price_field_value_id:name' => 'student_rate',
'entity_id.role_id:name' => 'Attended',
'entity_id.contact_id' => 87,
'entity_id.event_id' => 6,
'entity_table' => 'civicrm_participant',
])
->execute();
```
On update we would have actions like `addLineItem`, `removeLineItem`
Obviously this starts to highlight a whole lot of issues
**1) at the contribution params level**
there are some parameters that we have long-standing discussions around - financial_type_id, receive_date, payment_instrument_id. I think we should probably not start with talking about those as we might never get any further
**2) line items**
- one specific thing I think we all agree on is that we don't want line items to have to belong to the same price set. There will be some fighting with the code to get there but it's probably an issue that lives outside the bike shed
- in the example above the entity_table is passed in. For memberships that can be inferred from the price_field_value_id, but for event participants there is nothing on the price field or price_field_value that declares something as being event related
- for line items we kinda want to require the minimum required info which varies a bit.... ie
**-- if we have only the line_total (in the line item or just the contribution.total_amount) we can assume**
- the price field id is the default contribution price field
- the quantity is 1
- the unit_price is the line_total
**-- if we have only the qty and the unit_price we can assume**
- the price field id is the default contribution price field
- the line_total is unit_price * qty
**-- if we have only the line_total and the entity_table, which is civicrm_membership we can assume**
- the price field id is the default membership field
**but we require one of membership_type_id or price_field_value_id, from which we can determine amounts **
**-- if we have only the price_field_value id we can assume**
- the amount & price field can be looked up from it. We can assume qty to be 1 unless provided
- We need some way of specifying relevant entity values. (I suspect this is where the rubber hits the brake pads in the bikeshedding process). In the above example I have leveraged `entity_id` in the way we do for other apiv4 related entities. The v3 order api had some ideas about entity parameters which didn't align with our specification that closely - I think they were effectively 'sub-participants' and if we want to add that it might be `'entity_id.registered_participants' => []` perhaps. It's also rather tempting to refer to use `participant_id` to stand in for `entity_id` when it reflects the line....
**3) the add payment.**
We currently chain this - I did include above in the first iteration of this but removed based on the discussion. The world won't end if we don't do that.https://lab.civicrm.org/dev/core/-/issues/3109Raise number of email addresses available to inline edit2023-12-01T05:03:20ZAndrew WestRaise number of email addresses available to inline editIn light of #[3106](https://lab.civicrm.org/dev/core/-/issues/3106) ([PR](https://github.com/civicrm/civicrm-core/pull/22908)), is it worth upping the number of email addresses available to inline edit? We're hitting the limit of 6 somet...In light of #[3106](https://lab.civicrm.org/dev/core/-/issues/3106) ([PR](https://github.com/civicrm/civicrm-core/pull/22908)), is it worth upping the number of email addresses available to inline edit? We're hitting the limit of 6 sometimes and having to add directly into civicrm_email. I'd be tempted to make it 25 so it matches websites, but 10 at least?
Our use-case is that we have volunteers who have multiple roles in the organisation. Per GDPR each role needs its own email address. Doesn't take long to get to 6.https://lab.civicrm.org/dev/core/-/issues/1590Scheduled reminder: "Additional recipients" receive reminders under circumsta...2023-12-01T05:03:19ZJonGoldScheduled reminder: "Additional recipients" receive reminders under circumstances where they ought not toThis is a superset of event#28. The issue seems to be more generalized than I'd realized.
"Additional recipients" will receive reminders on events (and presumably other entities) that have been deleted. To test:
* Create a scheduled r...This is a superset of event#28. The issue seems to be more generalized than I'd realized.
"Additional recipients" will receive reminders on events (and presumably other entities) that have been deleted. To test:
* Create a scheduled reminder for an existing event.
* Under *Limit or Add Recipients*, select **Also Include** and add a group or contact(s).
* Delete the event.
* Run the scheduled reminders job.
**Expected result**
No scheduled reminder.
**Actual result**
Scheduled reminder to the "additional recipients".
### Why it happens
Scheduled reminder recipients are decided in two passes. First, whomever qualifies by the "normal" criteria (e.g. event participants) and a second pass for anyone in "Additional Participants".
The first pass is specific to the type of reminder (event, membership, contribution); the second is the same code regardless. This caused event#28; the "additional recipients" pass, by virtue of not being event/membership/etc-specific, wasn't aware that events have the special case of templates, which other entities don't. It also doesn't check for deleted entities.
The solution is to add a new method to the `Civi\ActionSchedule\MappingInterface` interface - a `sendToAdditional` method that returns a boolean. Then, each class that implements this interface can abort the "additional recipients" pass in an entity-specific way. Besides deleted entities and event templates, contributions have templates as well now, so we should check for that.https://lab.civicrm.org/dev/core/-/issues/3835Proposal: Deprecate profile standalone listing mode2023-11-30T17:03:40ZJonGoldProposal: Deprecate profile standalone listing modeProfile standalone listing code is deeply entangled with the query BAOs, and produces weird and wonderful bugs like #3834.
I don't think they're widely used in modern CiviCRM, they seem to have been a stopgap before Views integration, a...Profile standalone listing code is deeply entangled with the query BAOs, and produces weird and wonderful bugs like #3834.
I don't think they're widely used in modern CiviCRM, they seem to have been a stopgap before Views integration, and later for non-Drupal users to get a Views-esque experience. But Search Kit has effectively replaced them - they have feature parity and then some.
I think we can improve the query code if we no longer needed to worry about standalone listing mode.
Proposal:
* Remove the ability to create standalone listings on new installations of CiviCRM.
* Create a check for profiles using standalone listing mode, warning admins if they use it.
We can deprecate this over a long period of time, so the impact should be gentle.
If this proposal is approved, we may also want to consider a function that converts profile listings to SK searches. This will have added utility as we deprecate other uses of profiles (e.g. once SK replaces Advanced Search, Search Profiles will go away).https://lab.civicrm.org/dev/core/-/issues/4815Create Formbuilder page to view Queue status2023-11-30T11:40:03ZdamilareCreate Formbuilder page to view Queue statusWe need a page for CiviCRM administrators with Queue administration privilege to view the status of Civi Queues.
The page can be assigned this link: `https://{CIVI_DOMAIN}/civicrm/admin/queue`We need a page for CiviCRM administrators with Queue administration privilege to view the status of Civi Queues.
The page can be assigned this link: `https://{CIVI_DOMAIN}/civicrm/admin/queue`5.69.0https://lab.civicrm.org/dev/core/-/issues/1586Add ? option? to NOT log to civicrm_log when logging is enabled2023-11-30T05:03:16ZeileenAdd ? option? to NOT log to civicrm_log when logging is enabledI was under the impression that we didn't use the civicrm_log table when we enable logging - certainly it becomes inaccessible through the UI. However, I have discovered that the table has swollen to 32 GB and that new entries are regula...I was under the impression that we didn't use the civicrm_log table when we enable logging - certainly it becomes inaccessible through the UI. However, I have discovered that the table has swollen to 32 GB and that new entries are regularly logged.
I feel like this duplicates the function of logging / is kind of 'logging-lite' and I thought for that reason we didn't do it. However, I realise changing it might cause issues. All I can think of is a setting to not log o civicrm_log if logging is enabled.
@seamuslee @pfigel @jitendra any thoughts?https://lab.civicrm.org/dev/core/-/issues/3086Paypal declines recurring payments with wrong decimal delimiter2023-11-30T05:03:15ZMatthiasKPaypal declines recurring payments with wrong decimal delimiterOverview
----------------------------------------
Recurring paypal payments wont work if the "Decimal Delimiter" is not set to "." which is the usual the case in germany. This happend when using the payment processor "PayPal - Website Pa...Overview
----------------------------------------
Recurring paypal payments wont work if the "Decimal Delimiter" is not set to "." which is the usual the case in germany. This happend when using the payment processor "PayPal - Website Payments Standard".
Example use-case
----------------------------------------
1. Click on **Administer -> Localisation -> Languages, Currency, Locations **.
2. Set "Decimal Delimiter" to "," (common decimal delimiter in germany)
3. Configure Paypal as payment processor with payment processor type "PayPal - Website Payments Standard"
4. Configure an event that requires recurring payments and allow payments via paypal
Current behaviour
----------------------------------------
At the moment recurring payments are only possible if the "Decimal Delimiter" is set to ".". This results in problems and misunderstandings for accounting and when paying contributions.
Proposed behaviour
----------------------------------------
The paypal implementation is done in ** Core/Payment/PayPalImpl.php **. Maybe it could be checked if the "Decimal Delimiter" is set to "." before sending the request to paypal and change it if its not the case.https://lab.civicrm.org/dev/core/-/issues/3152Data stored in universal time does not handle DST consistently2023-11-30T05:00:20ZtottenData stored in universal time does not handle DST consistently[[_TOC_]]
Overview
----------------------------------------
CiviCRM has a number of `TIMESTAMP` columns -- these are stored in universal time (UTC) and displayed in the user's timezone. However, there is a subtle error in handling Dayl...[[_TOC_]]
Overview
----------------------------------------
CiviCRM has a number of `TIMESTAMP` columns -- these are stored in universal time (UTC) and displayed in the user's timezone. However, there is a subtle error in handling Daylight Savings Time (DST): if the current-date and the target-date sit on different sides of the DST-switch, then the time may present as +/- 1 hour.
This bug was one of the major subissues identified in https://lab.civicrm.org/dev/core/-/issues/2122. Although that particular feature was rolled-back/deferred from 5.47, the DST bug still exists -- it's just less obvious.
Example use-case
----------------------------------------
1. Create a contact record.
2. View the contact record. Note the creation time (`civicrm_contact.created_date`).
3. Change the system clock - set to a date where DST differs (eg if today is March 30, then go to December 5).
4. View the contact record. Note the creation time (`civicrm_contact.created_date`).
Current behavior
----------------------------------------
The displayed value of `civicrm_contact.created_date` _appears_ to change by +/- 1 hour, depending on when you view it.
> (Viewed on Mar 31, 2022)
>
> ![Screen_Shot_2022-03-31_at_12.40.53_AM](/uploads/8a2f5a0e4fb6ec884aede78e30d31b1a/Screen_Shot_2022-03-31_at_12.40.53_AM.png)
> (Viewed on Dec 5, 2022)
>
> ![Screen_Shot_2022-12-05_at_12.44.57_AM](/uploads/2df387488ee029a949010da163bf2ea8/Screen_Shot_2022-12-05_at_12.44.57_AM.png)
Why? CiviCRM sends a note to MySQL about the current user's timezone (`SET time_zone = '...'`). However, it doesn't identify the timezone effectively. It gives [the current numeric offset (at the moment of viewing)](https://github.com/civicrm/civicrm-core/blob/5.47.3/CRM/Utils/System/Base.php#L758-L762) - but (in locales with DST) the offsets fluctuate over time.
(_Ex: On Mar 31, the offset in California is `-0700`. Under current/long-standing law, the offset will be `-0800` on Dec 5. Of course, the US Congress is reconsidering this law... so we don't really know what the offset will be!_)
Proposed behavior 1: Fix MySQL timezones
----------------------------------------
CiviCRM should send the timezone as a symbolic name, such as `Europe/Helsinki`, `America/Los_Angeles`, or `Australia/Sydney`. These symbolic-names have an underlying database which allows them adjust automatically based on DST-rules/target-dates/current-law. On the surface, the fix is extremely simple:
```diff
diff --git a/CRM/Utils/System/Base.php b/CRM/Utils/System/Base.php
index a4660834c5..8e40f6da35 100644
--- a/CRM/Utils/System/Base.php
+++ b/CRM/Utils/System/Base.php
@@ -755,10 +755,9 @@ abstract class CRM_Utils_System_Base {
* Set timezone in mysql so that timestamp fields show the correct time.
*/
public function setMySQLTimeZone() {
- $timeZoneOffset = $this->getTimeZoneOffset();
- if ($timeZoneOffset) {
- $sql = "SET time_zone = '$timeZoneOffset'";
- CRM_Core_DAO::executequery($sql);
+ $timeZone = $this->getTimeZoneString();
+ if ($timeZone) {
+ CRM_Core_DAO::executequery('SET time_zone = %1', [1 => [$timeZone, 'String']]);
}
}
```
There are a couple of catches.
* __Timezone rules change__ (occasionally). Any software that supports timezones ultimately needs a _data feed_ with current rules. The good news: IANA publishes a free/open feed (https://www.iana.org/time-zones; aka `tzdata`; aka `zoneinfo`), most Linux/Unix distros have this feed, and MySQL can read it (`mysql_tzinfo_to_sql`). It usually requires one command (which could run during system-config, system-startup, and/or cron):
```bash
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql mysql
```
The problem: we have no measures for (a) how many CiviCRM deployments actually subscribe to this feed and (b) how many could subscribe, if they chose to.
* __Timezone names may be inconsistent__ (occasionally). For example, in different contexts, it's been fashionable to refer to California's timezone as `America/Los_Angeles`, `US/Pacific`, and `PST8PDT`. (The current+official fashion is `America/Los_Angeles` - the others are deprecated.) However, since Civi integrates with various layers (different CMSs; PHP APIs; MySQL APIs), there are edge-case where the layers may choose different names. (*I'm not super-concerned, but we should raise sensible warnings when names are invalid or mismatched.*)
The central issue is - how to cope when data isn't available? This comes to mind:
* (Status check) If the active TZ (`getTimeZoneString()`) has a deprecated name (eg `PST8PDT`) or an offset (eg `-0700`), show a warning.
* (Status check) If the active TZ (`getTimeZoneString()`) isn't supported by MySQL, show a warning.
* (Runtime) If the active TZ (`getTimeZoneString()`) isn't supported by MySQL, fallback to sending offset.
Proposed behavior 2: Change format. Use only PHP TZs.
----------------------------------------
(_This expands on one of @haystack's suggestions in dev/core#2122._)
If you assume that MySQL time services aren't available - what else would you do? You could use PHP time services.
The astute observer will note the status-quo (using both PHP and MySQL time-services) creates two points-of-failure. If either PHP _or_ MySQL has bad/incomplete/old timezone data, then you'll get mis-calculations _somewhere_. Consolidating on PHP time-services would reduce the #dependencies.
Both Drupal and WordPress take this approach. (I suspect this is extremely useful for maximizing compatibility with heterogeneous web-hosts.) They each do it a bit differently, but some central concepts are the same:
* In Drupal, PHP processes read+write temporal data in universal time -- as an `INT` (Unix-style, seconds-since-epoch).
* In WordPress, PHP processes read+write temporal data in universal time -- as a `DATETIME` with a `_gmt` suffix (eg `post_modified_gmt`).
* Hypothetically, you could hardcode MySQL to `SET time_zone='+0:00'`. PHP processes would read+write temporal data in universal time -- as a `TIMESTAMP`.
In all those cases, the onus is on the PHP devs to convert to/from universal-time when implementing functionality (eg "find records from March 1 - March 15" or "find records from this afternoon" or "extract the hour:minute component").
But there is a catch here: Civi already relies on several MySQL time-services. The schema works a certain way; the reports/searches/UIs/APIs expect the schema to work a certain way; etc.
The central issue is - how do you manage/QA all the changes (in schema+logic) required to change time-service?
Comments
----------------------------------------
* I haven't tested, but I'm fairly certain there will be another manifestation in CiviMail scheduling. Ex:
* You live in a timezone where DST changes on March 16.
* On March 10, you schedule a mail-blast for 2:00pm on March 20. It stores the schedule with the wrong offset.
* When March 20 comes, the mailing actually goes out at 3:00pm (or maybe 1:00pm).https://lab.civicrm.org/dev/core/-/issues/4794Premiums notices on Contribution Page2023-11-30T04:28:06ZJoeMurrayPremiums notices on Contribution PageOn dmaster just now (5.69.alpha1) on Help Support CiviCRM! which has a mug Premium on live page (https://dmaster.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=1) I get:
Warning: Undefined array key "thumbnail" in include() (li...On dmaster just now (5.69.alpha1) on Help Support CiviCRM! which has a mug Premium on live page (https://dmaster.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=1) I get:
Warning: Undefined array key "thumbnail" in include() (line 39 of /srv/buildkit/app/private/dmaster/default/civicrm/templates_c/en_US/%%DF/DF4/DF4B6A64%%PremiumBlock.tpl.php).
Warning: Undefined array key "image" in include() (line 39 of /srv/buildkit/app/private/dmaster/default/civicrm/templates_c/en_US/%%DF/DF4/DF4B6A64%%PremiumBlock.tpl.php).
Warning: Undefined array key "allowAutoRenewMembership" in include() (line 420 of /srv/buildkit/app/private/dmaster/default/civicrm/templates_c/en_US/%%3D/3D1/3D13F2BA%%Main.tpl.php).
First two appear to be related to Mug premium.5.68.0https://lab.civicrm.org/dev/core/-/issues/4563Sorting of "matching field" dropdown on contact import is messed up for "rela...2023-11-29T23:24:11ZDaveDSorting of "matching field" dropdown on contact import is messed up for "related contact info"1. Contact import
2. On the map fields page, the second item in the dropdown is "related contact info" but it's not connected to the relationships like before, and the relationships are now mixed in with regular fields instead of their o...1. Contact import
2. On the map fields page, the second item in the dropdown is "related contact info" but it's not connected to the relationships like before, and the relationships are now mixed in with regular fields instead of their own section.
Also I haven't confirmed if it happens elsewhere but on a site with a saved mapping the fields that were "do not import" came up as "related contact info" when using the saved mapping after upgrade (from 5.58).5.68.0https://lab.civicrm.org/dev/core/-/issues/4726On Import in Non English Mode do not import field in saved field mapping is n...2023-11-29T20:14:33ZseamusleeOn Import in Non English Mode do not import field in saved field mapping is not correctly set as default when re-using importOverview
----------------------------------------
When using import contacts for example with a saved field mapping where one of the fields is set to be marked as `do_not_import` in languages other than English this is not always set cor...Overview
----------------------------------------
When using import contacts for example with a saved field mapping where one of the fields is set to be marked as `do_not_import` in languages other than English this is not always set correctly when the MapField form is loaded as per the screenshot below showing the saving of the saved mapping field with the 2nd field as do not import but then when I go to re-use the saved mapping the mapped column does not match do not import
![save_import_map](/uploads/a652dc803fecadde0d5ec7fe0f202f58/save_import_map.jpg)
![use_import_map](/uploads/a2ae9251dbc67491276567473e4668c7/use_import_map.jpg)
Reproduction steps
----------------------------------------
1. Navigate to Administer -> localisation -> Languages ... and Set current language to be French (France)
1. Go to contacts -> Import contacts and proceed to the map field step. Create a mapping and save it making sure that one of the fields is marked as do not import
1. Repeat step 2 but this time re-use the saved mapping from before and find that the field is not mapped to the selection of do not import
ping @eileen @JoeMurray5.67.0https://lab.civicrm.org/dev/core/-/issues/4764SearchKit: permission for entity (expenses) needed to access SearchKit as non...2023-11-29T20:01:34ZMariaVSearchKit: permission for entity (expenses) needed to access SearchKit as non-adminWhen there is a SearchKit form with entity expenses, non-admins without the permission "manage expenses" can not access SearchKit.
When I try to open SearchKit (via Search > SearchKit) without the permission I get the following error mes...When there is a SearchKit form with entity expenses, non-admins without the permission "manage expenses" can not access SearchKit.
When I try to open SearchKit (via Search > SearchKit) without the permission I get the following error message: "Civi\API\Exception\UnauthorizedException: Authorization failed in /html/wordpress/wp-content/plugins/civicrm/civicrm/Civi/API/Kernel.php on line 149"
This seems to be a bug and might be true for other specific entities, too.https://lab.civicrm.org/dev/core/-/issues/4761Copy event fails with DB Error: already exists; Saving new reminder hangs2023-11-29T07:35:34ZBobSCopy event fails with DB Error: already exists; Saving new reminder hangsOverview
----------------------------------------
Copying an event fails with "DB Error: already exists" if a reminder with the same name (but different case) exists in civicrm_action_schedule.
Also, while editing an event, saving a new...Overview
----------------------------------------
Copying an event fails with "DB Error: already exists" if a reminder with the same name (but different case) exists in civicrm_action_schedule.
Also, while editing an event, saving a new event reminder hangs if a reminder with the same name (but different case) exists in civicrm_action_schedule.
Reproduction steps
----------------------------------------
1. Edit an event and create an reminder with name "reminder".
2. Then create a reminder with the name "Reminder".
Current behaviour
----------------------------------------
Infinite spinner.
Environment information
----------------------------------------
* __CiviCRM:__ _5.67_
* __Database:__ _MariaDB 10.4_
* __CMS:__ _Drupal 9.5_
Comments
----------------------------------------
Both issues are due to the 5.66-alpha1 addition of the index `civicrm_action_schedule.UI_name`.
While CRM_Core_DAO::makeNameFromLabel() ensures that the new name is unique in a case-sensitive context, the `name` column has the default ci collation, making the index case insensitive. As a result, violations of the 'unique' constraint can occur.5.68.0https://lab.civicrm.org/dev/core/-/issues/3092Batch search form/results incorrect vis-a-vis status2023-11-29T05:03:26ZlcarterBatch search form/results incorrect vis-a-vis statusThe batch search form searches based on contribution status, but has a results column displaying transaction/payment status. This is confusing and undesirable.
Even when the search is specifically limited to contributions with complete...The batch search form searches based on contribution status, but has a results column displaying transaction/payment status. This is confusing and undesirable.
Even when the search is specifically limited to contributions with completed status, some results may show pending status; this is confusing to the user. See https://www.screencast.com/t/XgNTPieRXz - the box is indicating two transaction records for the same dues payment.
Proposal:
1. Expose a search filter field for civicrm_financial_trxn.status_id as well as contribution status.
2. In Search Results, change the column title from Status to something more clear, like Financial Transaction Status or (slightly inaccurate but generally true and more understandable) Payment Status.
3. In Search Results, add a column title Contribution Status that displays the civicrm_contribution.status_id field.
Discussion:
This functionality has been around for a long time and not used much. Perhaps that because it has a confusing UX. The proposal would not break anything for existing users.
However, for many years there was a desire to get rid of Contribution Status, partly for reasons that @lcarter is raising here: a field on contribution record can't do the job of representing all of the statuses of multiple steps in multiple payments, for example, perhaps followed by refunds or cancellation or some failure attempts in the middle.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/4713Move the Elavon Payment Processor extension out of core2023-11-28T23:54:24ZjaapjansmaMove the Elavon Payment Processor extension out of coreI have just installed CiviCRM 5.66 for a client and I see it ships with an Elavon Payment Processor extension.
I have never heard of Elavon and I believe this extension is very usefull but not in the use cases I have seen so far. (They...I have just installed CiviCRM 5.66 for a client and I see it ships with an Elavon Payment Processor extension.
I have never heard of Elavon and I believe this extension is very usefull but not in the use cases I have seen so far. (They use CiviSepa for direct debits and Mollie for online payments both are not shipped with core).
I also believe that an extension which lives outside of core is also easier to install on CiviCRM installations which does not have this extension shipped by default (when needed).https://lab.civicrm.org/dev/core/-/issues/4450Standalone: set the page title2023-11-28T19:33:31ZbgmStandalone: set the page titleCurrently the `<title>` attribute (in head) is empty.Currently the `<title>` attribute (in head) is empty.RichRichhttps://lab.civicrm.org/dev/core/-/issues/3295Make datepicker accessible2023-11-28T12:49:35ZMonish DebMake datepicker accessibleThe Civi datepicker field aren't accessible which means that other than cursor actions, you can select date from calendar using control keys.
This is about making datepicker accessible and here's a working example how it will look like ...The Civi datepicker field aren't accessible which means that other than cursor actions, you can select date from calendar using control keys.
This is about making datepicker accessible and here's a working example how it will look like after completing changes-
https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker
A user should be able to use datepicker with the help of control keys, not just cursor actions, and tasks involved are:
1. Tab to select date input field
2. On date field select calendar dialog, focus on current or default date.
3. Tab action switches to previous/next/month/year button
4. Show a close button on down right corner that has a tabstop.
5. Left/Right/Up/Down to change day/month/year.
6. Enter to selectMonish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3302Add accessible fieldset for checkboxes and radio buttons2023-11-28T12:49:35ZMonish DebAdd accessible fieldset for checkboxes and radio buttonsAs per https://www.w3.org/WAI/tutorials/forms/grouping , grouped form controls like radio buttons/checkboxes must be enclosed in ```<fieldset>``` and the ```<legend>``` element act as a header to identify the group of elements. Currently...As per https://www.w3.org/WAI/tutorials/forms/grouping , grouped form controls like radio buttons/checkboxes must be enclosed in ```<fieldset>``` and the ```<legend>``` element act as a header to identify the group of elements. Currently, when we review such block with WAVE accessibility tool, it complains about:
![Screen_Shot_2018-06-01_at_6.53.18_PM](/uploads/0782446dde4a776d6ec4a8f5c51edf47/Screen_Shot_2018-06-01_at_6.53.18_PM.png)
## Proposal
1. Enclose the checkbox/radio button block in a fieldset
2. Add a special class to that fieldset say `crm-sr-fieldset` which hides it in front-end forms (public and backoffice forms)
3. Use label of checkbox/radio buttons as its legend header.
Monish DebMonish Debhttps://lab.civicrm.org/dev/user-interface/-/issues/59Cleanup Civi markup to use the 'canonical' style-guide versions2023-11-28T12:49:34ZnicolCleanup Civi markup to use the 'canonical' style-guide versionsThe hoped-for final step of the theme project is to cleanup Civi markup to remove the multitude of patterns found in #56, repolacing them with the canonical versions specified in #57, so that the theme #58 can shrink in size/complexity.
...The hoped-for final step of the theme project is to cleanup Civi markup to remove the multitude of patterns found in #56, repolacing them with the canonical versions specified in #57, so that the theme #58 can shrink in size/complexity.
The further the project of [replacing Civi's Admin UI screens](https://github.com/civicrm/civicrm-core/pull/27422) with SearchKit and FormBuilder gets, the smaller this task becomes.Improve Civi's front-end