Development issueshttps://lab.civicrm.org/groups/dev/-/issues2020-07-16T17:23:37Zhttps://lab.civicrm.org/dev/drupal/-/issues/3Remove `templates/CRM/common/version.tpl`2020-07-16T17:23:37ZtottenRemove `templates/CRM/common/version.tpl`__Background__: We aim to allow installing CiviCRM on Drupal 8 via `composer`/`git` _without_ requiring the admin to run `GenCode`.
The file `templates/CRM/common/version.tpl` is generated by `GenCode` and then used once... by `GenCod...__Background__: We aim to allow installing CiviCRM on Drupal 8 via `composer`/`git` _without_ requiring the admin to run `GenCode`.
The file `templates/CRM/common/version.tpl` is generated by `GenCode` and then used once... by `GenCode`. If you grep `universe`, there's nothing else that references `CRM/common/version.tpl`.
__Task__:
~~Find the place where `GenCode` relies on `templates/CRM/common/version.tpl`. Get that information a different way (i.e. read `version.xml`). Then, update `GenCode` so that it no longer creates `templates/CRM/common/version.tpl`.~~
EDIT: If the file isn't used, then do we really need to remove it? Perhaps we can keep it around (in tarballs) on the off-chance that some unpublished legacy process relies on it, but omit from the D8 builds?
Stepping back... @dsnopek, I'm a little confused -- because it seems to me like this file isn't used, but your D8 install steps copy it over. Did you put that step in as a matter of speculation or based on a concrete issue?D8 General Availabilityhttps://lab.civicrm.org/dev/drupal/-/issues/4Use `civicrm-setup` to handle installation2020-08-07T03:28:13ZtottenUse `civicrm-setup` to handle installation**Background**: During installation, one must check system-requirements, populate database, etc. To do this, the Drupal 8 integration currently calls some functions from `install/`.
However, the functions in the `install/` folder are t...**Background**: During installation, one must check system-requirements, populate database, etc. To do this, the Drupal 8 integration currently calls some functions from `install/`.
However, the functions in the `install/` folder are too narrowly crafted -- we don't have much ability to add/change/rearrange/remove installer steps. [civicrm-setup](https://civicrm.org/blog/totten/developers-revising-the-civicrm-installer-library-cli-wordpress) aims to redress that limitation and make it easier to iterate on the installer. For any new distribution channels (like D8), we should call `civicrm-setup`.
__Tasks__:
* __(a)__ `civicrm.drush.inc`: The function `drush_civicrm_install()` must use the `civicrm-setup` API (eg `installFiles()`, `installDatabase()`).
* __(b)__ `civicrm.install`: The function `civicrm_install()` must use setup API (eg `installFiles()`, `installDatabase()`).
* __(c)__ `civicrm.install`: The function `civicrm_requirements()` should use the setup API (eg `checkRequirements`, `checkAuthorized`).D8 General Availabilityhttps://lab.civicrm.org/dev/drupal/-/issues/5Add support for Drupal 8 to cv (`Bootstrap.php` and `CmsBootstrap.php`)2020-07-16T17:23:37ZtottenAdd support for Drupal 8 to cv (`Bootstrap.php` and `CmsBootstrap.php`)D8 General Availabilitytottentottenhttps://lab.civicrm.org/dev/drupal/-/issues/6Migrate 8.x branches to separate git repo2020-07-16T17:23:37ZtottenMigrate 8.x branches to separate git repo__Background__: The `civicrm-drupal.git` repo has branches named `8.x-*`. However, these are not detectable/addressable via `composer`/`packagist`.
__Tasks__
* __(a)__: Create new repo `civicrm-drupal-8`. Migrate the `8.x-*` branches, ...__Background__: The `civicrm-drupal.git` repo has branches named `8.x-*`. However, these are not detectable/addressable via `composer`/`packagist`.
__Tasks__
* __(a)__: Create new repo `civicrm-drupal-8`. Migrate the `8.x-*` branches, but remove the `8.x-` prefix.
* __(b)__: Update release process to ensure that these are branched/tagged.D8 General Availabilityhttps://lab.civicrm.org/dev/drupal/-/issues/7Problem: How to address `civicrm.config.php` without running `GenCode`2020-10-01T00:47:38ZtottenProblem: How to address `civicrm.config.php` without running `GenCode`We aim to allow installing CiviCRM on Drupal 8 via composer/git _without_ requiring the admin to run `GenCode`.
The file `civicrm.config.php` is currently produced by `GenCode`, and it's required by various backend scripts (`extern/*` a...We aim to allow installing CiviCRM on Drupal 8 via composer/git _without_ requiring the admin to run `GenCode`.
The file `civicrm.config.php` is currently produced by `GenCode`, and it's required by various backend scripts (`extern/*` and `bin/*`). A naive approach might be to simply commit this file -- however, that's problematic because there are ~4 variants of this file (for `civicrm-drupal`, `civicrm-wordpress`, `civicrm-joomla`, and `civicrm-backdrop`).
There are a couple ways we might do this:
* (a) Audit each entry-point (`extern/*`, `bin/*`). For each, figure out some alternative way to address it without needing `civicrm.config.php`.
* __Challenge__: There are several entry-points, and each will likely have its own series of issues/patches. In this approach, it's hard to control the scope of work.
* (b) Import the universal CMS boot script from `cv.git` or `civicrm-wordpress.git` to `civicrm-core.git` (related: #5). All backend scripts (`extern/*`, `bin/*`) should use a fallback-behavior. (*"If `civicrm.config.php` exists, call it. Otherwise, call the universal boot script."*)
* __Challenge__: People like to do funny things with their builds, and there's no fixed spec for "all possible builds". A "universal" CMS boot script will probably be broken for someone.
* (c) `composer.json` integration -- for anyone installing Civi via `composer`, tell them to put some extra script calls in their root `composer.json`. The script creates `civicrm.config.php`.
* __Challenge__: This makes the installation experience more complicated.
* (d) Update all backend scripts (`extern/*`, `bin/*`) to use a fallback-behavior. (*"If `./drupal/civicrm.config.php.drupal` exists, call it. If `../civicrm.config.php.wordpress` exists, call it. Ad nauseum."*)
* __Challenge__: People like to do funny things with their builds, and there's no fixed spec for "all possible builds". A "universal" CMS boot script will probably be broken for someone.D8 General Availabilityhttps://lab.civicrm.org/dev/drupal/-/issues/8Problem: How to address Bower dependencies installable via `composer`2020-07-16T17:23:37ZtottenProblem: How to address Bower dependencies installable via `composer`D8 General Availabilityhttps://lab.civicrm.org/dev/drupal/-/issues/9Problem: Easily allow 'vendor' directory not under the webroot2020-09-30T12:35:40ZtottenProblem: Easily allow 'vendor' directory not under the webrootThis is currently possible, but requires some patches and a build process.
**Here's the patches and process currently used by myDropWizard for Roundearth.io:**
*Patches:*
1. Find CKEditor relative to the resource URL: https://github.c...This is currently possible, but requires some patches and a build process.
**Here's the patches and process currently used by myDropWizard for Roundearth.io:**
*Patches:*
1. Find CKEditor relative to the resource URL: https://github.com/mydropwizard/civicrm-core/commit/9fc3877e2eb14e2829b530445c5e5491afc4bbe
2. Look for vendor directory above web root: https://github.com/mydropwizard/civicrm-core/commit/f57954392f8026d17b7f19f7c01ceeb65e703384
Both of those could probably be merged upstream?
*Process:*
1. Build process to copy web assets to `WEBROOT/libraries/civicrm` so they are web accessible. Here's the version from [roundearth's build process](https://gitlab.com/mydropwizard/roundearth-drops-8/blob/master/rebuild.sh#L74):
```
# Copy CiviCRM assets
asset_source=./vendor/civicrm/civicrm-core
asset_dest=./web/libraries/civicrm
mkdir -p $asset_dest
rsync -mr --include='*.'{html,js,css,svg,png,jpg,jpeg,ico,gif,woff,woff2,ttf,eot} --include='*/' --exclude='*' $asset_source/ $asset_dest/
rm -rf $asset_dest/tests
cp -r $asset_source/extern $asset_dest/
cp $asset_source/civicrm.config.php $asset_dest/
cat << EOF > $asset_dest/settings_location.php
<?php
define('CIVICRM_CONFDIR', '../../../sites');
EOF
```
2. Set the "Resource URL" to `[cms.root]/libraries/civicrm/`
**Getting support for this upstream:**
1. I think the patches might be good to just commit upstream? They don't seem controversial
2. The build process could be put in a PHP class in civicrm-corm which could be referred to as a script in a sites composer.json
3. We should be able to detect that we're using the vendor outside the webroot - could we somehow make the necessary "Resource URL" the default?5.5.0https://lab.civicrm.org/dev/drupal/-/issues/10Keep `civicrm-version.php` up-to-date without running GenCode on all builds2020-07-16T17:23:38ZtottenKeep `civicrm-version.php` up-to-date without running GenCode on all buildsWe aim to allow installing CiviCRM on Drupal 8 via `composer`/`git` without requiring the admin to run `GenCode`.
The file `civicrm-version.php` is generated by `GenCode`. A typical copy looks like this:
```php
<?php
/**
* Get the Civ...We aim to allow installing CiviCRM on Drupal 8 via `composer`/`git` without requiring the admin to run `GenCode`.
The file `civicrm-version.php` is generated by `GenCode`. A typical copy looks like this:
```php
<?php
/**
* Get the CiviCRM version.
*/
function civicrmVersion() {
return array(
'version' => '4.7.30',
'cms' => 'Drupal',
'revision' => '4.7.30',
);
}
```
A simple fix might be:
* Commit the file to `civicrm-core.git` (much like in #1).
* Update `tools/bin/scripts/set-version.php` to maintain this file. (That script is part of the workflow whenever setup a new release.)
There's one catch: the `cms` field varies depending on the local runtime. *However*, we may be lucky here -- in a cursory check, I only found a couple places that relied on it. ~~The task here would be to take a closer look and potentially remove this element.~~ We'd also need to resolve these stale references to `cms`:
* `civicrm.drush.inc` (in `civicrm-backdrop-1.x`, `civicrm-drupal-6.x`, `civicrm-drupal-7.x`, `civicrm-drupal-8.x`)
* Use constants or functions from Drupal/Drush/Backdrop to detect the active environment.
* `install/index.php` and `install/template.html`
* Remove or rewrite any optional sanity checks that rely on this field.
* Use `$installType` to backfill `$civicrm_version['cms']` (like the WordPress conditional does)D8 General Availabilityhttps://lab.civicrm.org/dev/drupal/-/issues/11Cleanup unnecessary files when running composer in D8 conext2023-02-08T16:48:07ZseamusleeCleanup unnecessary files when running composer in D8 conextCiviCRM's `composer.json` delegates to a post-install script to remove unnecessary and potentially dangerous files (e.g. demo scripts that shouldn't in the public web root). When adding civicrm to composer in Drupal 8, the post-install s...CiviCRM's `composer.json` delegates to a post-install script to remove unnecessary and potentially dangerous files (e.g. demo scripts that shouldn't in the public web root). When adding civicrm to composer in Drupal 8, the post-install scripts do not run automatically (ie `composer.json` does not recursively invoke post-install scripts). Therefore, we may be left dangerous content.D8 General Availabilityhttps://lab.civicrm.org/dev/translation/-/issues/5Cannot export member addresses if the location_type display name has an accent2019-02-24T21:10:49ZbgmCannot export member addresses if the location_type display name has an accentHow to reproduce:
* Add a location type "Expédition", where name = `expedition` and display_name = `expédition`.
* Go to the member dashboard, click to list all active members
* Edit one of the contacts, so that they have an address of ...How to reproduce:
* Add a location type "Expédition", where name = `expedition` and display_name = `expédition`.
* Go to the member dashboard, click to list all active members
* Edit one of the contacts, so that they have an address of type "expédition"
* Back in the search results, export all results
* Select a custom mapping:
* Display name
* City, location type = Expédition
Result: the city is empty (for that contact that was edited).
If we remove the accent from the display name, it works fine. Also, it doesn't seem to be a mismatch issue between the name / display_name, because if it's "Expedition123" it works fine.5.5.0https://lab.civicrm.org/dev/financial/-/issues/2Payment processor names: separate internal and external usage2019-11-01T21:01:36ZAndie HuntPayment processor names: separate internal and external usageThe Name field on payment processors leads to a lot of surprises for users. The name currently appears in four places:
1. Obviously, when managing the payment processors on the site.
2. When configuring a contribution page or event,...The Name field on payment processors leads to a lot of surprises for users. The name currently appears in four places:
1. Obviously, when managing the payment processors on the site.
2. When configuring a contribution page or event, you can choose the processor(s) available.
3. If more than one payment processor and/or pay later is available on an event or contribution page, the options are labeled with the processor names.
4. After completing a contribution or event registration with certain types of processors, the thank you page says it has been submitted to the processor, using the payment processor name.
These four situations are very different in what should display. Moreover, none of these consequences are apparent to the site admin who is deciding on a name for a payment processor.
Many people give the payment processor the name of the bank and/or payment processor, such as "Stripe". This is reasonable in case 4, when donors are told:
> Your contribution has been submitted to Stripe for processing. Please print this page for your records.
However, it's a little confusing in case 3 unless it's obvious that it's a name of a payment processor. A donor might be offered a choice between "Authorize" and "Pay Later", and it's not clear to the layperson that the former is going to charge your credit card.
(It's also not obvious to site admins that this is the case. Someone could have a single payment processor on the site, give it a silly name, and be just fine so long as Pay Later is never an option. However, they could add Pay Later on an event or contribution page at a later point and not realize that donors must select "New SunTrust Authorize.net" in order to pay by credit card.)
We usually suggest calling a payment processor "Credit Card", but this is a problem when organizations need to have multiple payment processors in order to support separate bank accounts and/or organizational entities.
It also looks silly to say,
> Your contribution has been submitted to Credit Card for processing. Please print this page for your records.
I propose two changes:
1. Add a new field for the publicly visible payment processor label. This would allow an admin to know they have "Action Fund Stripe" enabled for a contribution page but call it "Credit Card" on the frontend.
2. Fix those "submitted for processing" pieces to say something either generic or defined by payment processor type.5.20.0https://lab.civicrm.org/dev/core/-/issues/3532Determine CiviCRM host and port in Docker-friendly way - via an environment v...2024-02-25T05:03:20ZMichael McAndrewDetermine CiviCRM host and port in Docker-friendly way - via an environment variablehttps://lab.civicrm.org/dev/core/-/issues/3293Make menu more accessible2022-04-22T16:04:20ZJoeMurrayMake menu more accessiblePreliminary tasks, many from https://lab.civicrm.org/dev/accessibility/issues/1#note_4855 below:
1. [x] Hide D7 menubar
1. [x] Fix for D8
1. [x] After getting focus into top menu, tabbing and back-tabbing revealed there was something hid...Preliminary tasks, many from https://lab.civicrm.org/dev/accessibility/issues/1#note_4855 below:
1. [x] Hide D7 menubar
1. [x] Fix for D8
1. [x] After getting focus into top menu, tabbing and back-tabbing revealed there was something hidden between Quick Search textbox and the CiviCRM icon. Opening submenus and back-tabbing revealed it was the search options for the Quick Search textbox. Please remove this from tab order.
1. [x] After getting focus into top menu, Space did not open (and when repeated, close) child menu on current item. It should act similarly to Return.
1. [x] When focus is on an item that could be selected to navigate somewhere, Return worked fine but Space did not replicate this.
1. [x] When on an open sub-submenu (eg Contributions > Accounting Batches with Open Batches with focus), using left arrow correctly moved focus to Accounting Batches, but it did not close the sub-submenu.
1. [x] When on a submenu, using left arrow should close the submenu and move focus to parent item. Instead it moved focus to menu item to left of parent item. The submenu was left open when it should have been closed.
~~1. [ ] When on a sub-submenu, escape should only close that level of menu but closes both the sub-submenu and the submenu.~~
1. [ ] "First item in menu bar should be in the tab order (tabindex=0)." (https://staff.washington.edu/tft/tests/menus/index.html). This may be a bit of work to implement in all CMSes but I think tabindex=0 for CiviCRM menu makes sense as the default on CiviCRM pages on default CMS installs. The CiviCRM Menu left item should be considered the QuickSearch. There appears to be an item for a div around the textarea and a separate way to focus on the textarea itself. The div around the textarea should be tabindex=0.
1. [ ] The cited spec is relatively silent, but other accessible menus have different implementations on the following: 1) When focus is on top menu item and its submenu is open, left and right cycle focus to left and right top menu items and shift which submenu is open to the one under the top menu focussed item. 2a) When focus is on a submenu item left closes the submenu, cycles focus to left on top menu and opens that top menu's submenu. 2b) When focus is on a submenu item without a subsubmenu, right similarly closes submenu, cycles focus right on top menu and opens that top menu item's submenu. 2c) When focus is on a submenu item with a subsubmenu, right opens the subsubmenu. Let's change behaviour 1), 2a) and 2b) to not opening new submenu. Leave 2c) as is.
~~1. [ ] When focus is not on the menu, cursor hovering over a menu item brings focus to it and opens submenu. Submenu should not open until click, return or space.~~
A user should be able to navigate the menu bar by use of the keyboard:
1. [ ] The menu bar should occupy one tab stop
1. [ ] When focused on a menu at the top level:
1. [ ] The right arrow key should move the user to the next top-level menu
1. [ ] The left arrow key should move the user to the previous top level menu
1. [ ] User focus should wrap to the beginning if the user advances past the final menu item. Likewise, if the user tries to navigate to the previous item from the first menu, focus should wrap to the last menu.
1. [ ] The down-arrow and ENTER keys should expand a child menu and focus the user on the first item
~~1. [ ] When a character is typed, the next menu item starting with that letter receives the focus, circling around to first when there are no more. If no menu item starts with the typed character, focus does not move. (deprecated by HTML 5.2 accesskey standard)~~
1. [ ] When focused on a child menu
1. [ ] The down arrow key should move the user to the next menu item
1. [ ] The up arrow key should move the user to the previous menu item
1. [ ] The right arrow key should expand a menu item with a submenu and place user focus on the first item in that submenu. If there is no submenu, then no action is taken.
1. [ ] The left arrow key should collapse a submenu and place user focus on the parent of that submenu
1. [ ] The ESC key should close the active child menu, and any submenus, and return user focus to the parent menu at the top level.
~~1. [ ] When a character is typed, the next child menu item starting with that letter receives the focus, circling around to first when there are no more. If no child menu item starts with the typed character, focus does not move. (deprecated by HTML 5.2 accesskey standard)~~
Test the menu works on default installs (ie default theme!) on
1. [x] Drupal 7
1. [x] WordPress
1. [x] Joomla
1. [x] Backdrop
1. [x] Drupal 8
(NB: deliberately ignoring support for Drupal 6.)
Test the menu works on:
1. [x] Drupal 7 site with shoreditch theme installed
1. [x] Drupal 7 site with mosaico installed, on a CiviMail mosaico page.
A more detailed functional spec is provided at http://lists.w3.org/Archives/Public/wai-xtech/2007Dec/att-0025/index.html#menu
A good implementation that might be useful for its implementation details (seeing View Source) is https://staff.washington.edu/tft/tests/menus/simplyaccessible/index.html. As there are no sub-submenus, I imagine the code implementation needs to be extended to opening sub-submenus properly.
Was https://issues.civicrm.org/jira/browse/CRM-20824
Original description from https://civicrm.stackexchange.com/questions/17735/access-for-blind-users-to-civicrm/17752#17752
The menu bar is keyboard accessible, but awkwardly. Generally I find it best to focus on the first item then TAB (as opposed to arrowing) to the top level menu the user wants to interact with before pressing ENTER to activate the pop-up menu. You will then have to locate the HTML list element containing the menu choices. Often this element appears after the menu bar, or at the bottom of the virtual document (sometimes depending on the CMS theme, sometimes depending on, seemingly, the browser’s mood). In either case, it will not appear immediately “under” the activated menu.https://lab.civicrm.org/dev/core/-/issues/3294Make accordion panels accessible2024-03-15T20:39:55ZJoeMurrayMake accordion panels accessibleFrom https://civicrm.stackexchange.com/questions/17735/access-for-blind-users-to-civicrm/17752#17752
Accordion panels in the contact record cannot be expanded with the keyboard. In general, panels containing certain contact data (demogr...From https://civicrm.stackexchange.com/questions/17735/access-for-blind-users-to-civicrm/17752#17752
Accordion panels in the contact record cannot be expanded with the keyboard. In general, panels containing certain contact data (demographic information, address, etc.) are collapsed by default. It is necessary to use the mouse (JAWS) cursor in order to expand these panels.
A user should be able to expand an collapse an accordion panel by using the keyboard only and not be required to use the mouse. To accomplish this, elements of crm-acordion-header should be made keyboard focusable and be configured to provide feedback to the screen reader on whether they are collapsed or expanded. At the simplest level, these elements could be made buttons instead of divs and be given the aria-expanded attribute which would be dynamically toggled depending on the panel’s state. This will allow a keyboard user to focus the panel header with the tab key and expand or collapse it with ENTER or SPACE. More in-depth examples of accordion accessibility can be found at OAA Accessibility http://www.oaa-accessibility.org/examplep/accordian1/, and Basic Accessible Accordion Panel for jQuery http://www.jqueryscript.net/accordion/Basic-Accessible-Accordion-Plugin-jQuery.html.
Technical spec to come.
Was https://issues.civicrm.org/jira/browse/CRM-208255.73.0https://lab.civicrm.org/dev/drupal/-/issues/12Keep 'CRM/Core/DAO/AllCoreTables.data.php' up-to-date without running CRM_Cor...2020-07-16T17:23:38ZMonish DebKeep 'CRM/Core/DAO/AllCoreTables.data.php' up-to-date without running CRM_Core_CodeGen_Reflection on all buildsThis file is updated via `CRM_Core_CodeGen_Reflection` and uses `xml/templates/listAll.tpl` to populate all Civi table metadata in this php file - https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/DAO/AllCoreTables.data.php .
...This file is updated via `CRM_Core_CodeGen_Reflection` and uses `xml/templates/listAll.tpl` to populate all Civi table metadata in this php file - https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/DAO/AllCoreTables.data.php .
A simple fix might be:
* Extend plugins/installDatabase/InstallSchema.civi-setup.php to do this task
* Use `CRM_Core_CodeGen_Reflection` workflow to create/update `AllCoreTables.data.php` and notify this task before doing it via installer.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3296Add aria-label (and label?) to form elements missing them2022-04-22T16:04:46ZJoeMurrayAdd aria-label (and label?) to form elements missing themUse accessible labels for all pages/forms following spec at https://www.w3.org/WAI/tutorials/forms/labels.
Tasks will include the following general points. Some details will change to ensure that ts() is handled properly, addField() is...Use accessible labels for all pages/forms following spec at https://www.w3.org/WAI/tutorials/forms/labels.
Tasks will include the following general points. Some details will change to ensure that ts() is handled properly, addField() is used appropriately, etc from comments below:
1. Label without control elements/text: In some pages/forms we are simply declaring labels under `<label>` tag against an element/text.
1. Remove tag when it is declared against a text as in
```
- <div class="label"><label>{ts}Contact{/ts}</label></div>
+ <div class="label">{ts}Contact{/ts}</div>
```
1. Add `aria-labelledby` attribute to tag
```
- <label>{ts}Contact{/ts}</label><input type="text" name="contact_id" id="contact_id">
+ <label aria-labelledby="contact_id">{ts}Contact{/ts}</label><input type="text" name="contact_id" id="contact_id">
```
1. Add aria-label attribute to QuickForm element when label is not declared in tpl: Say for example we are assigning a label to a QuickForm element
`$form->addElement('text', 'pledge_installments', ts('Installments'), array('size' => 3));` but not using it in tpl.
**Fix**: Add aria-label attribute to QuickForm element:
```
- $form->addElement('text', 'pledge_installments', ts('Installments'), array('size' => 3));
+ $form->addElement('text', 'pledge_installments', ts('Installments'), array('size' => 3, 'aria-label' => ts('Pledge Installments')));
```
1. Add aria-label attribute to form element via JS: A special case when after declaring this attribute didn't got added to the QuickForm element as in case of 'Credit card Expiration date' when this element got rendered in the quickform as `$form->add('date', 'credit_card_exp_date', ts('Expiration Date'), ['format' => M Y'])` and thus rendered into two select field without this attribute
**Fix**: Add `aria-label` attribute via JS instead. This might involve modifying $.fn.crmDatepicker in Common.js to add aria-labels to the autogenerated date elements it inserts.
1. Fix date fields.
Focus initially on public facing pages/forms:
1. [x] contribution page
1. [x] event registration page
1. [x] price field block
1. [x] newsletter signup
1. [x] user registration in CMS
1. [x] profile create/edit/search
1. [x] contact dashboard
1. [x] contact summary page
1. [ ] CiviReports
1. [ ] Search Forms
1. [ ] Backend registration forms
https://lab.civicrm.org/dev/core/-/issues/3299Make alerts accessible2022-04-22T16:04:58ZJoeMurrayMake alerts accessibleFrom Clare comes a problem statement and some brainstorming ideas:
> A problem for our low vision users is alerts, their AT software doesn't recognise them, so they miss warnings and end up adding duplicates. It would be great to have s...From Clare comes a problem statement and some brainstorming ideas:
> A problem for our low vision users is alerts, their AT software doesn't recognise them, so they miss warnings and end up adding duplicates. It would be great to have some sort of per user control for setting how alerts display, perhaps even adding audio cues.
Use alert role approach suggested at https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/examples/alert/index.html as this will allow audio cues to be given to users of screen readers.
Note more details at https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/#alert and also https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/#alertdialog
https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-no-exceptions.html indicates that there should be no time limits like quickly disappearing alerts.
As a first pass, let's implement a site wide setting to disable alerts from disappearing. We don't have a good design pattern currently for per user preferences. When we do move to per user preferences, the default should be to have alerts not disappear.justinfreeman (Agileware)justinfreeman (Agileware)https://lab.civicrm.org/dev/core/-/issues/3297replace select2 with latest stable2022-04-22T16:04:56ZJoeMurrayreplace select2 with latest stableCurrently, Civi is using select2 3.5 which we need to upgrade to latest stable 4.0.5, maybe 4.0.6 (https://github.com/select2/select2/releases) and then resolve compatibility issues with CiviCRM.
The upgrade from 3.5 to 4.x contains num...Currently, Civi is using select2 3.5 which we need to upgrade to latest stable 4.0.5, maybe 4.0.6 (https://github.com/select2/select2/releases) and then resolve compatibility issues with CiviCRM.
The upgrade from 3.5 to 4.x contains numerous breaking changes that affect the calling code in CiviCRM.
Major issues:
1. Auto appending values doesn't work anymore
Error: Uncaught TypeError: Cannot read property 'prop' of undefined
LOC - https://github.com/civicrm/civicrm-core/blob/master/js/crm.searchForm.js#L9
Reference - https://select2.org/upgrading/migrating-from-35#select2-val
2. Placeholder broken
Error: Uncaught TypeError: Cannot read property 'id' of undefined
As per 3.5 - placeholderOption is used to set the placeholder value for select2 widget
As per 4.0.4 - placeholder option can now accept placeholder value both in string and object
Reference - https://select2.org/upgrading/migrating-from-35#more-flexible-placeholders
3. EntityRef select2 fields are broken
Error: Uncaught Error: No select2/compat/initSelection
As per 4.0.4 - Removed the requirement of 'initSelection'
Reference - https://select2.org/upgrading/migrating-from-35#removed-the-requirement-of-initselection
4. Navigation menu style is not applied
Error: Uncaught TypeError: Cannot read property 'prop' of undefined
As per 4.0.4 - $("select").val("1").trigger("change"); // instead of $("select").select2("val", "1");
Reference - https://select2.org/upgrading/migrating-from-35#select2-val
Minor issues
1. Multi select2 widget doesn't show downarrow placeholder icon
2. select2 css style isn't applied after upgrade
migration of old JIRA issue with some additional discussion at https://issues.civicrm.org/jira/browse/CRM-21263https://lab.civicrm.org/dev/financial/-/issues/3Migrate from one-2-one forms to many to one for payment & line items2018-03-19T00:01:10ZeileenMigrate from one-2-one forms to many to one for payment & line itemshttps://lab.civicrm.org/dev/financial/-/issues/4Add processor name to recurring contribution overview on Contribution tab2018-04-06T09:59:51Zmattwiremjw@mjwconsult.co.ukAdd processor name to recurring contribution overview on Contribution tabRequires changes in https://issues.civicrm.org/jira/browse/CRM-21784 so data is available to smarty.
The recurring section could do with quite a bit of refactoring to allow things such as sorting, optional columns etc. However, as it s...Requires changes in https://issues.civicrm.org/jira/browse/CRM-21784 so data is available to smarty.
The recurring section could do with quite a bit of refactoring to allow things such as sorting, optional columns etc. However, as it stands a two line change to the template allows us to add additional columns as it currently has less columns than the contribution tab. This PR adds the "processor name" column as this is probably one of the more common bits of useful information that all processors use.
Use case: It allows you to see at a glance who has direct debits setup, who has recurring payments with paypal etc. Currently this information is a bit awkward to find as you have to open each recurring contribution to look at the detail.
Before:
![localhost_8000_civicrm_contact_view_reset_1_cid_206__1_](/uploads/29850d8be3b37711fe398bb1d2b2c922/localhost_8000_civicrm_contact_view_reset_1_cid_206__1_.png)
After:
![localhost_8000_civicrm_contact_view_reset_1_cid_206](/uploads/a4c2c14bbcb7fe6c8dd92bdd6f8d8271/localhost_8000_civicrm_contact_view_reset_1_cid_206.png)