Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-01-25T05:03:22Zhttps://lab.civicrm.org/dev/core/-/issues/3446Please include Contributors and Reviewers website address in the CiviCRM Rele...2024-01-25T05:03:22Zjustinfreeman (Agileware)Please include Contributors and Reviewers website address in the CiviCRM Release Notes and CiviCRM Blog PostThis is a request to please include the Contributors and Reviewers website address in the CiviCRM Release Notes and CiviCRM Blog Post. Currently, no link to their website is shown at all. And there are only links to CiviCRM Partner Profi...This is a request to please include the Contributors and Reviewers website address in the CiviCRM Release Notes and CiviCRM Blog Post. Currently, no link to their website is shown at all. And there are only links to CiviCRM Partner Profiles.
It would be a nice way of giving credit to all people involved by including a link to their website.
Appreciate this requires some changes to how the release notes and blog posts are compiled, happy to help make this happen.https://lab.civicrm.org/dev/core/-/issues/3441When generating emails from Search results, activity is recorded as a Print P...2023-03-06T20:39:37ZStoobWhen generating emails from Search results, activity is recorded as a Print PDF DocumentSteps to reproduce:
1. use Search Kit to generate results as _Contributions_
2. choose to send emails receipts
3. emails are sent, but activity is recorded "Print/Merge Document" rather than Type "Email".
#searchkitSteps to reproduce:
1. use Search Kit to generate results as _Contributions_
2. choose to send emails receipts
3. emails are sent, but activity is recorded "Print/Merge Document" rather than Type "Email".
#searchkithttps://lab.civicrm.org/dev/core/-/issues/3440Check for matching contact on contact add form sends hardcoded fields to dupl...2023-07-06T07:25:40ZdarrickCheck for matching contact on contact add form sends hardcoded fields to duplicatecheck api callOverview
----------------------------------------
If a custom Supervised rule is created using any field not in ['first_name', 'last_name', 'nick_name', 'household_name', 'organization_name', 'email'] then clicking on the **Check for Mat...Overview
----------------------------------------
If a custom Supervised rule is created using any field not in ['first_name', 'last_name', 'nick_name', 'household_name', 'organization_name', 'email'] then clicking on the **Check for Matching Contact** button will return no results.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Find and Merge Duplicate Contacts**.
2. Click on **Add Individual Rule**
3. Add a rule with field phone, weight 10, threshold 10
4. Click on **Change rule** and set to **Supervised**
5. Click on **Contacts -> New Individual**
6. Add a contact with First Name: Bob, Last Name: Dobbs and phone 666.666.6666
7. Save the contact.
8. Click on **Contacts -> New Individual**
9. Add a contact with First Name: Bob, Last Name: Dobbs and phone 666.666.6666
10. Click on **Check for Matching Contact**
Current behaviour
----------------------------------------
A popup displays "Similar contact if found" after entering the First Name and after entering the Last Name in step 9.
After entering the duplicate phone number nothing happens.
After clicking on **Check for Matching Contact** nothing happens.
Expected behavior
----------------------------------------
After entering either First Name or Last Name nothing should happen unless the entered field is included in the Supervised rule.
A popup displaying "Similar contact if found" should happen after the phone number is entered and also after clicking on **Check for Matching Contact**
Comments
----------------------------------------
I ran across this while looking to see if I could fix any other outstanding bugs related dedupe. Was working on this one: (https://lab.civicrm.org/dev/core/-/issues/2966) I wasn't able to reproduce their issue.
It may still be useful to hard code those fields so by default the form always matches on name or email when entering those fields but then the additional fields will also be searched when added using the custom rule. As any fields not needed for the custom rule will just be ignored.https://lab.civicrm.org/dev/drupal/-/issues/180Naming: Drupal "8" references are anachronistic on Drupal 9/102022-11-18T15:01:20ZtottenNaming: Drupal "8" references are anachronistic on Drupal 9/10If you install CiviCRM-Drupal on D9/D10, some of the technical-names have anachronistic references to D8, eg
* The git repo name (`civicrm-drupal-8.git`)
* The composer package name (`civicrm/civicrm-drupal-8`)
* The UF name (`Drupal8`)...If you install CiviCRM-Drupal on D9/D10, some of the technical-names have anachronistic references to D8, eg
* The git repo name (`civicrm-drupal-8.git`)
* The composer package name (`civicrm/civicrm-drupal-8`)
* The UF name (`Drupal8`)
* Any classes based on the UF name (`CRM_Utils_System_{$UF}`, `CRM_Utils_Hook_{$UF}`, `CRM_Core_Permission_{$UF}`)
This is an off-shoot from discussion with @AlanDixon on https://lab.civicrm.org/dev/drupal/-/issues/178#note_74093https://lab.civicrm.org/dev/release/-/issues/18Scheduling/workflow for security updates of dependencies2022-04-29T08:58:12ZtottenScheduling/workflow for security updates of dependencies# Synopsis
The workflow for *first-party/in-house* security updates and the workflow for *third-party/upstream* security updates are qualitatively different
The question of this issue is: Do we keep one general policy/schedule for both...# Synopsis
The workflow for *first-party/in-house* security updates and the workflow for *third-party/upstream* security updates are qualitatively different
The question of this issue is: Do we keep one general policy/schedule for both kinds of security issues, or do we have a more nuanced policy that distinguishes between them?
# Background
CiviCRM's policy for scheduling/workflow on security updates has a few key elements:
* Report and discuss vulnerabilities privately
* Release updates on a designated release window (the first/third Wed of each month)
* Make an effort to pre-announce (often 1-4 weeks in advance)
Those bullets are based on the premise that we control the process for disclosure/development/etc. This is true and appropriate for the common case where the security vulnerability originates in code maintained directly by CiviCRM.
But there is another common case: *dependencies* ("libraries", "packages", "subpackages", etc) used by CiviCRM and maintained by another group. These break the bullet-points from above:
* The purpose of upstream's public advisory is *to notify people like us*. The issue is necessarily public when we get the information.
* There are several different upstreams. Their release scheduling is (on the whole) fluid - some have release-windows; some don't; some make pre-announcements; some don't; each of those policies may change over time.
* The vulnerability is public. Delaying the release (in service of a pre-announcement/spin-up period) exacerbates the risk exposure. We don't want our scheduling to add extra exposure.
The security updates of a dependency affect CiviCRM in a few ways. Anyone reading this probably has some understanding already. But just to be complete, those effects include:
* Dependency-updates require some correlated change in how we use that dependency. In the best case, that just means metadata (eg `composer.json`, `composer.lock`) - but it can also be much more involved. It varies case-by-case.
* Several artifacts need to be republished when a dependency changes (notably the tarballs/zipballs for WP/D7/BD/J - but also any images published via docker, etc).
# Proposal
Security fixes _that have been previously published by an upstream vendor_ should be assimilated through CiviCRM's public development channels (Gitlab/Github/Mattermost/etc). The process should closely match the process for patch-releases that fix recent-regressions:
* Like a regular patch-release...
* Any patches/PRs should be submitted to the RC's public queue.
* After approving the RC PR, then backport to stable/ESR. (Only backport if we believe it to be "likely" exploitable.)
* Discussion about testing, `r-run`, compatibility, etc can happen in the public PR.
* We do not need to assign a CIVI-SA-* identifier or write an "advisory" record.
* In addition, there are extra bits...
* We'll send a mailblast when the stable/ESR updates are published.
* Release notes should highlight the "Security" issue as distinct from any other "Bug fix" issues. They should link to upstream's advisory (in addition to the usual Github/Gitlab links for Civi).
* In the public media, don't discuss how to specifically exploit the vulnerability. If that requires discussion, go to private Mattermost (`security` and/or direct-message). The public PR may have general claims (eg "I have successfully exploited this on my local system"; or "Alice, Bob, and Carol discussed on security channel - and all felt it is probably exploitable.")
* Backports for stable and ESR will be done in parallel. (They may be done by different people).
All other security issues (ie *first-party vulnerabilities; unpublished third-party vulnerabilities; uninvestigated vulnerabilities*) should continue through the current (private) workflows.
We should update https://civicrm.org/security to indicate this distinction.
# Rationale
* If a black hat is motivated enough to monitor CiviCRM's issue/PR queue for heads-up about CiviCRM vulnerabilities, then they can just as easily monitor the official release feeds for `dompdf`, `ckeditor`, etc.
* Github's "dependabot" is already likely to post public PRs when there's a published vulnerability affecting a CiviCRM dependency.
* Pro-active contributors will find it natural to raise these issues publicly (because they're already public).
* This change should reduce typical turn-around-time / duration-of-exposure for this type of issue. (*Compare: 2 weeks vs 0-3 days*)
* Routing dependency-updates through the private security medium adds noise to the private tracker without adding much security benefit.
# Other thoughts
Microsoft made "Patch Tuesday" famous. But they generally own all their dependencies.
Drupal has landed on "third Wed" as their release-window. However, they appear to make an exception when a third-party library publishes outside their preferred schedule (ex: https://www.drupal.org/sa-core-2022-006).
If we relax the scheduling on dependency updates, then we don't need to keep 1st Wed on the books. CiviCRM-specific fixes could be like Drupal -- strictly third Wed.
Anecdotally, I feel upstream announcements land on a weekday (esp Tue/Wed/Thu) -- and this lines up the interest of deployers. We could lean into this (eg dependency updates only happen on weekdays).
Note: Backdrop's release-window is _any Wed_. AFAICS, WordPress, Joomla, and PHP don't have formal release-windows. Based on skimming advisories, Joomla has a strong Tue bias. WP+PHP float around. (Between them, I skimmed ~20 prior releases, and there was only one that landed on a weekend.)https://lab.civicrm.org/dev/core/-/issues/3409Back-office registration of guest participants2023-01-10T15:22:25ZJKingsnorthBack-office registration of guest participants**Motivation:**
Currently it is not possible to add 'additional participants' (guests) to an event booking in the back end. Instead, you need to create a new booking for the guest record, and then there is no way to 'link' them to the le...**Motivation:**
Currently it is not possible to add 'additional participants' (guests) to an event booking in the back end. Instead, you need to create a new booking for the guest record, and then there is no way to 'link' them to the lead booker.
**Solution:**
Allow additional participants (guests) to be added to someone's booking, when managing participants through the back end, eg:
![image](/uploads/00c03cb2e27642db624ec612516927f8/image.png)
**Previous work:**
See https://issues.civicrm.org/jira/browse/CRM-19047 . The PR here (https://github.com/civicrm/civicrm-core/pull/8676) works for adding guests to peoples' bookings in the back end for free events. But we ran into some problems with paid events, because of the way the contribution row is handled.
We are currently working on this and hope to submit a new PR that will work for free and paid events by the end of January.https://lab.civicrm.org/dev/core/-/issues/3408Allow the "Cancellation or transfer time limit (hours)" to be negative2022-04-22T16:23:12ZJonGoldAllow the "Cancellation or transfer time limit (hours)" to be negativeEvents are often multi-day events; in my particular use case, events represent university courses, and there is an add/drop period wherein students may freely cancel their registration in the first week of classes.
This involves changin...Events are often multi-day events; in my particular use case, events represent university courses, and there is an add/drop period wherein students may freely cancel their registration in the first week of classes.
This involves changing the relevant MySQL field from an `unsigned int` to a `signed int`, altering a few lines of form-level validation, and changing some help text to document the change.5.30.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3406Allow duplicate backend registration when event has "allow same participant e...2022-04-22T16:23:05ZbgmAllow duplicate backend registration when event has "allow same participant emails"We have the following use-case:
* Organisation using CiviEvent for a box office, i.e. to sell tickets for concerts
* People may buy multiple tickets for concerts, and often not at the same time.
For example, they may have bought a tick...We have the following use-case:
* Organisation using CiviEvent for a box office, i.e. to sell tickets for concerts
* People may buy multiple tickets for concerts, and often not at the same time.
For example, they may have bought a ticket during pre-sales, then later bought a ticket as a gift for a friend.
The front-end allows this, thanks for the "allow same participant emails". However the backend does not validate this option. When adding a backend registration, if the participant has already bought a ticket, the admin will get an error message: "This contact has already been assigned to this event."
Looking at Stack Exchange, I found this thread:
https://civicrm.stackexchange.com/questions/15826/enable-multiple-event-registration-for-same-purchaser-participant
Since we use the Event Cart and the [boxoffice](https://lab.civicrm.org/extensions/boxoffice) extension, I implemented a workaround here:
https://lab.civicrm.org/extensions/boxoffice/commit/526703f40c772930bac18e16f71e918e5bd50fb1#d8fbb70d3d7f43c0bde3f9f1385c3d03e740a39f_0_79
but we could avoid all those overrides by adding those 4 lines of code to CRM_Event_Form_Participant.
cc @cmtool5.17.0https://lab.civicrm.org/dev/core/-/issues/3405Event Templates: do not auto-populate the Start Date / End Date2022-04-22T16:23:02ZbgmEvent Templates: do not auto-populate the Start Date / End DateWhen creating an event using an event template, the Start Date is automatically set to the date when the template was created.
To reproduce:
* Create an Event Template (Administer > Events > Event Templates)
* Wait one day, or set the ...When creating an event using an event template, the Start Date is automatically set to the date when the template was created.
To reproduce:
* Create an Event Template (Administer > Events > Event Templates)
* Wait one day, or set the `start_date` to some past date (templates are saved as regular events in the `civicrm_event` database table).
* Create a new Event, and use the template that was created.
* Notice how the start date is automatically set.
This might not sound like a big deal, but when the event template was created in 2015, it gets pretty annoying to have to also click to change the year (and it's easy to overlook).
This was also reported on Stack Exchange:
https://civicrm.stackexchange.com/questions/28159/event-template-start-date
cc @justinfreeman @cividesk @lcdweb (because you seem to be using Events a lot)5.17.0https://lab.civicrm.org/dev/core/-/issues/3402Hide explanatory text about multiple participants unless 2 or more participan...2022-09-30T23:21:23ZlarsssandergreenHide explanatory text about multiple participants unless 2 or more participants selectedOn event registration pages, when multiple participants is enabled, there is a lengthy bit of explanatory text shown:
"Fill in your registration information on this page. If you are registering additional people, you will be able to ente...On event registration pages, when multiple participants is enabled, there is a lengthy bit of explanatory text shown:
"Fill in your registration information on this page. If you are registering additional people, you will be able to enter their registration information after you complete this page and click "Continue"."
It would be better to hide this text until the user selects a number of participants greater than one. I'll submit a patch if this change is supported.https://lab.civicrm.org/dev/core/-/issues/3389Implement tests for Event Registration pages2024-01-11T05:03:25Zmattwiremjw@mjwconsult.co.ukImplement tests for Event Registration pages`CRM/Event/Form/Registration/Register.php` needs to be refactored like `CRM/Contribute/Form/Contribution.php` so that we can implement tests on submit.
`CRM_Event_Form_Registration_Register::postProcess()` needs splitting up to call a n...`CRM/Event/Form/Registration/Register.php` needs to be refactored like `CRM/Contribute/Form/Contribution.php` so that we can implement tests on submit.
`CRM_Event_Form_Registration_Register::postProcess()` needs splitting up to call a new function `CRM_Event_Form_Registration_Register::submit()`.
Then we need to add `CRM_Event_Form_Registration_Register::testSubmit()` and write some tests to call this function.https://lab.civicrm.org/dev/core/-/issues/3381Event Registration Confirm/Thank You pages show incorrect currency2024-02-08T23:37:57ZbwheelerEvent Registration Confirm/Thank You pages show incorrect currencyThe event registration confirmation/thank you pages display the incorrect currency. Steps to reproduce:
* Create a new event with a non-default currency (in my case EUR)
* Add a price set to fees and allow registration
The main event p...The event registration confirmation/thank you pages display the incorrect currency. Steps to reproduce:
* Create a new event with a non-default currency (in my case EUR)
* Add a price set to fees and allow registration
The main event page, confirmation and thank you pages will all show the incorrect currency.
We fixed this for a client by doing the following:
````
diff --git a/sites/all/modules/contrib/civicrm/CRM/Event/Form/Registration.php b/sites/all/modules/contrib/civicrm/CRM/Event/Form/Registration.php
index 74526af6a..947cc051e 100644
--- a/sites/all/modules/contrib/civicrm/CRM/Event/Form/Registration.php
+++ b/sites/all/modules/contrib/civicrm/CRM/Event/Form/Registration.php
@@ -452,6 +452,8 @@ class CRM_Event_Form_Registration extends CRM_Core_Form {
}
}
+ $this->assign('currency', $params['currencyID']);
+
$this->assign('address', CRM_Utils_Address::getFormattedBillingAddressFieldsFromParameters($params, $this->_bltID));
// The concept of contributeMode is deprecated.
````
The problem is that `templates/CRM/Price/Form/LineItem.tpl` uses the `$currency` variable, but `Event/Form/Registration.php` sets `$currencyID` and not `$currency`
However, it still doesn't work for on-the-fly (non-price-set) prices.
This bug may be related to the following:
* https://lab.civicrm.org/dev/core/-/issues/2930
* https://lab.civicrm.org/dev/core/-/issues/4115.71.0https://lab.civicrm.org/dev/core/-/issues/3366Price option reaches max amount causes critical error.2022-04-22T16:21:52ZBruce ThompsonPrice option reaches max amount causes critical error.If a price field is setup with price options that have a max amount when that max amount of registrations is met the site throw a critical error in WordPress. First noticed this in CiviCRM v 5.35.1. I updated a site to 5.36 with the same...If a price field is setup with price options that have a max amount when that max amount of registrations is met the site throw a critical error in WordPress. First noticed this in CiviCRM v 5.35.1. I updated a site to 5.36 with the same result and then tested on https://wpmaster.demo.civicrm.org/ which is currently running 5.38.alpha1 and I received similar results xcept I didn't get the WP critical error message just a http 500 notice. Here is the error message sent via WordPress after the critical error page. There is nothing in the CiviCRM logs.
> An error of type E_ERROR was caused in line 209 of the file /home/account_name/public_html/wp-content/plugins/civicrm/civicrm/CRM/Price/BAO/PriceField.php. Error message: Uncaught Error: Call to a member function freeze() on string in /home/account_name/public_html/wp-content/plugins/civicrm/civicrm/CRM/Price/BAO/PriceField.php:209
Stack trace:
#0 /home/account_name/public_html/wp-content/plugins/civicrm/civicrm/CRM/Price/BAO/PriceField.php(439): CRM_Price_BAO_PriceField::freezeIfEnabled('
Happy to provide additional information.5.36.1https://lab.civicrm.org/dev/core/-/issues/3358Add option to include guest information in back-office confirmation emails2024-01-07T05:03:23ZJKingsnorthAdd option to include guest information in back-office confirmation emailsProblem: when you send a confirmation email from the back-end after registering a participant, or editing their booking, it only includes the information for the 'current' participant (ie, just the lead booker). It does not include any '...Problem: when you send a confirmation email from the back-end after registering a participant, or editing their booking, it only includes the information for the 'current' participant (ie, just the lead booker). It does not include any 'additional participants' (guests) linked to their registration.
Solution: suggested CiviCRM core patch to add a checkbox to 'include guest information' for confirmation emails for participants that have guests attached to them. This would include the guest information int he email, as though it was from a front-end booking.
ie: IF the booking has additional participants, display a new checkbox:
![image](/uploads/2dbec13b633d9be6e880c2fb255a4b80/image.png)
If the checkbox is ticked, then add in the guest information, in the same way as a 'front-end' registration would add their information.https://lab.civicrm.org/dev/core/-/issues/3342Memberships of disabled membership types do not appear on the membership tab ...2024-01-04T05:03:20ZalicefruminMemberships of disabled membership types do not appear on the membership tab BUT do throw duplicate Membership WarningIf a contact has a Membership of the Membership Type "Student"
and the membership type "Student" gets disabled
On the contacts membership tab you will see no memberships but when you try and create a new membership for this contact a "D...If a contact has a Membership of the Membership Type "Student"
and the membership type "Student" gets disabled
On the contacts membership tab you will see no memberships but when you try and create a new membership for this contact a "Duplicate Membership" warning will appear.
To some extent this makes sense because if one were to re enable the disabled student membership type and a user had created a new membership that could be problematic. However from a UI perspective it seems like it would be useful for disabled memberships to be listed.https://lab.civicrm.org/dev/core/-/issues/3341Prevent Duplicate memberships2024-01-03T05:03:26ZprdufresnePrevent Duplicate membershipsThere needs to be a mechanism to prevent duplicate memberships for the same user. There are legitimate circumstances for there to be multiple memberships, but there needs to be a way to prevent it as well.
I propose two options:
1. A ...There needs to be a mechanism to prevent duplicate memberships for the same user. There are legitimate circumstances for there to be multiple memberships, but there needs to be a way to prevent it as well.
I propose two options:
1. A checkbox in the Contribution Page settings Memberships tab to "Prevent duplicate memberships"
2. A checkbox in the Membership Types page that "Allows duplicate membership of this type"
In either case, the verification logic should be specific to that membership type.https://lab.civicrm.org/dev/core/-/issues/3339Wrong frequency when purchasing a membership2024-01-05T03:42:45ZsudomanWrong frequency when purchasing a membershipWe patched a bug in CiviCRM core that has been around for a while now. When buying an annual membership, sometimes donors are charged the annual price, but on a monthly basis. (We offer both annual and monthly memberships on the same mem...We patched a bug in CiviCRM core that has been around for a while now. When buying an annual membership, sometimes donors are charged the annual price, but on a monthly basis. (We offer both annual and monthly memberships on the same membership page). This patch is a hack that works for us, but may have some hard coded values for our instance.
One way to check if your server has this problem is to use a payment processor like PayPal, which lets you see the recurring contrib details before you actually pay. This issue comes up somewhat randomly, so you might have to try a few times.
Thanks! : )
```
diff --git a/CRM/Contribute/Form/ContributionBase.php b/CRM/Contribute/Form/ContributionBase.php
index 41fcb7da3e..075d29ab20 100644
--- a/CRM/Contribute/Form/ContributionBase.php
+++ b/CRM/Contribute/Form/ContributionBase.php
@@ -1371,7 +1371,14 @@ class CRM_Contribute_Form_ContributionBase extends CRM_Core_Form {
$this->_params['is_recur'] = $this->_values['is_recur'] = 1;
// check if price set is not quick config
if (!empty($this->_params['priceSetId']) && !CRM_Core_DAO::getFieldValue('CRM_Price_DAO_PriceSet', $this->_params['priceSetId'], 'is_quick_config')) {
- list($this->_params['frequency_interval'], $this->_params['frequency_unit']) = CRM_Price_BAO_PriceSet::getRecurDetails($this->_params['priceSetId']);
+
+ // Extract the ids for all of the line items that have been chosen.
+ $priceFieldValueIds = array_keys($this->_lineItem[$this->_params['priceSetId']])[0];
+ if (empty($priceFieldValueIds))
+ $priceFieldValueIds = array_keys($this->_params['price_126'])[0];
+ list($this->_params['frequency_interval'], $this->_params['frequency_unit']) = CRM_Price_BAO_PriceSet::getRecurDetails($this->_params['priceSetId'], $priceFieldValueIds);
}
else {
// FIXME: set interval and unit based on selected membership type
diff --git a/CRM/Price/BAO/PriceSet.php b/CRM/Price/BAO/PriceSet.php
index 91118ecd97..0277bdbaed 100644
--- a/CRM/Price/BAO/PriceSet.php
+++ b/CRM/Price/BAO/PriceSet.php
@@ -1332,13 +1332,14 @@ GROUP BY mt.member_of_contact_id ";
* @return array
* associate array of frequency interval and unit
*/
- public static function getRecurDetails($priceSetId) {
+ public static function getRecurDetails($priceSetId, $priceFieldValueIds) {
$query = 'SELECT mt.duration_interval, mt.duration_unit
FROM civicrm_price_field_value pfv
INNER JOIN civicrm_membership_type mt ON pfv.membership_type_id = mt.id
INNER JOIN civicrm_price_field pf ON pfv.price_field_id = pf.id
- WHERE pf.price_set_id = %1 LIMIT 1';
+ WHERE pf.price_set_id = %1 AND pfv.id = '
+ . $priceFieldValueIds . ' LIMIT 1';
$params = [1 => [$priceSetId, 'Integer']];
$dao = CRM_Core_DAO::executeQuery($query, $params);
```5.69.0https://lab.civicrm.org/dev/core/-/issues/3325Using separate donation with free membership result into Pending (incomplete ...2023-11-10T01:45:09ZMonish DebUsing separate donation with free membership result into Pending (incomplete transaction) 0$ contributionSteps to replicate:
1. Create a 0$ fixed membership type
2. Configure a new/existing online contribution page, with separate donation and choose 0$ membership type under `Membership Fee`
3. Do a online contribution with $1 separate dona...Steps to replicate:
1. Create a 0$ fixed membership type
2. Configure a new/existing online contribution page, with separate donation and choose 0$ membership type under `Membership Fee`
3. Do a online contribution with $1 separate donation with 0$ membership
Bug:
Two donation are created, one with Completed 1$ contribution and other `Pending (Incomplete Transaction)` 0$ contribution linked with Pending free membership:
![Screenshot_2021-06-22_at_2.06.49_PM](/uploads/0cbd58fb74d7bc9467613571f70bb74a/Screenshot_2021-06-22_at_2.06.49_PM.png)
Expected result:
Complete 0$ membership's donation associated with `new` free membership
cc @eileen @JoeMurrayMonish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3303Front End Event Registration Form - Drop Down Select List Labels not accessible2023-12-28T05:03:24ZndavisFront End Event Registration Form - Drop Down Select List Labels not accessibleOn front end registration forms, when using screen reader software (JAWS etc) When tabbing from a text field into a drop down select list field, the screen reader reads the selected data, not the field label, the way it does with other f...On front end registration forms, when using screen reader software (JAWS etc) When tabbing from a text field into a drop down select list field, the screen reader reads the selected data, not the field label, the way it does with other field types. This is broken. It should read the field label for drop down lists like it does with other field types. The user knows what is selected when they click it and it's read.
To fix this issue, change the aria-labelledby attribute of the s2id_autogen1 id'd input html element from select2-chosen-1 to s2id_autogen1
Code Example for the credit card form at https://demo.circle-interactive.co.uk/civicrm/event/register?id=1&reset=1:
`<label for="s2id_autogen1" class="select2-offscreen">Country</label>
<input class="select2-focusser select2-offscreen" type="text" aria-haspopup="true" role="button" aria-labelledby="select2-chosen-1" id="s2id_autogen1">`
**aria-labelledby="select2-chosen-1"**
needs to be changed to
`<label for="s2id_autogen1" class="select2-offscreen">Country</label>
<input class="select2-focusser select2-offscreen" type="text" aria-haspopup="true" role="button" aria-labelledby="s2id_autogen1" id="s2id_autogen1">`
**aria-labelledby="s2id_autogen1"**
This change can be extrapolated to state list drop downs (indeed any drop-downs)
For blind users this causes confusion because they don't know what field they're on if they're in a state/province named after the country and it works differently than the rest of the field types.
Changing this in the html source using developer tools of firefox or chrome fixes issue until page is refreshed.
I tried to figure out where this is happening but the javascript spaghetti is very confusing. If anyone can point me to the right file I'll patch it.
thx,
Neil P Davis
Developer
National Federation of the Blindhttps://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.0