Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-12-19T21:18:09Zhttps://lab.civicrm.org/dev/core/-/issues/3493Afform: Failed to find key by ID or tag (SIGN)2022-12-19T21:18:09ZandyburnsAfform: Failed to find key by ID or tag (SIGN)I created a simple afform submitting a name and it just spins and shows this console error. On Civi 5.50.0, WP 5.8.4 and multisite. I had this issue on 5.46.3 as well. It does submit the contact even though it appears not to.
![image](/...I created a simple afform submitting a name and it just spins and shows this console error. On Civi 5.50.0, WP 5.8.4 and multisite. I had this issue on 5.46.3 as well. It does submit the contact even though it appears not to.
![image](/uploads/98a9537c12d29cda91345959e268d8a0/image.png)
Sometimes only the angular error:
![image](/uploads/4e77c2cbad1b88909dc62e7b4e3d4500/image.png)
No error reported to civi logs.https://lab.civicrm.org/dev/core/-/issues/3490Upgrader - Apply extension updates after core updates2023-02-08T19:08:30ZtottenUpgrader - Apply extension updates after core updatesOverview
----------------------------------------
Functionality in `civicrm-core` is increasingly organized with internal extensions (`civicrm-core:ext/*`). The main upgrade workflow should incorporate the upgrade-steps for extensions.
...Overview
----------------------------------------
Functionality in `civicrm-core` is increasingly organized with internal extensions (`civicrm-core:ext/*`). The main upgrade workflow should incorporate the upgrade-steps for extensions.
Example use-case
----------------------------------------
1. Extract tarball with a new version of `civicrm-core`, including updated `ext/*`
1. Run the main upgrader (`civicrm/upgrade?reset=1`, `cv core:upgrade`, `drush civicrm-upgrade-db`, or `wp civicrm upgrade-db`)
Current behaviour
----------------------------------------
It updates the schema for things like `civicrm_contact` (eg `CRM/Upgrade/*`) but not things like `civicrm_search_segment` (eg `ext/search_kit/CRM/Search/Upgrader.php`).
As a sysadmin, you must run the upgrades separately.
Most are not habituated to running these together. This leads to confusing user-stories like https://civicrm.stackexchange.com/questions/42094/civimail-issue-db-error-no-such-table-when-sending-mailing (where the first upgrade seemed to work - but you get random errors because the second upgrade hasn't run).
Proposed behaviour
----------------------------------------
Run both.
The core-upgrade should delegate/incorporate the ext-upgrade, and it should preserve essential elements of the ext-upgrade contract. Specifically: ext-upgrades can use features/services/APIs from core. This implies that (1) ext-upgrades run after core-upgrades and (2) when it gets to ext-upgrades, it should follow a normal/open dispatch-policy.
Comments
----------------------------------------
Filing issue after some Mattermost discussion with rudanpal, @colemanw, @bgm, @totten: https://chat.civicrm.org/civicrm/pl/b76y4gy517yxdet331ueqrxgrw
I posted a draft at https://github.com/civicrm/civicrm-core/compare/5.50...totten:run-ext-upgrades?expand=1
As mentioned in PHP comments+Mattermost, there's an issue with the current draft -- when it gets to ext-upgrade tasks, it would (unexpectedly) continue to apply the limited dispatch-policy used for core-upgrades (`upgrade.main` vs `upgrade.finish`). Some ways to address that:
* __Runner state__: While the upgrader goes through phases (*ex: 1-core upgrade, 2-ext upgrade, 3-new exts*), keep a stored value naming the phase. this stored value determines the active dispatch-policy
* ex: `Civi::settings()->set('upgrade_phase', '...')`
* __Task wrapping/task tagging__: When taking ext-upgrade tasks and putting them into the core-upgrade queue, put some wrapper or tag on each one to indicate the phase/policy that it relies on
* wrapper example: `CRM_Upgrade_Form::wrappedTask(string $dispatchPolicy, array $realCallback)
* tag example: `$queue->createItem($task, ['dispatchPolicy' => string])`https://lab.civicrm.org/dev/core/-/issues/3478Afform - email delivery2023-06-29T15:47:01Zaydunsaidan.saunders@squiffle.ukAfform - email deliveryOverview
----------------------------------------
Add an action to enable scheduled Email Delivery of SearchKit results.
Reports provides settings to enable scheduled Email Delivery of reports. The lack of an option to do the same dete...Overview
----------------------------------------
Add an action to enable scheduled Email Delivery of SearchKit results.
Reports provides settings to enable scheduled Email Delivery of reports. The lack of an option to do the same deters some people from using SearchKit - see https://civicrm.stackexchange.com/q/41966/225
Comments
----------------------------------------
Not a high priority item but noting for parity with Reports functionality.https://lab.civicrm.org/dev/joomla/-/issues/405 broken/dated links in post-install success screen for Joomla2022-10-11T22:50:40Znicol5 broken/dated links in post-install success screen for JoomlaOn successfully installing CiviCRM on Joomla (I'm assuming not on the other CMSs), there's a welcome screen with four links to the old wiki/confluence (ie 'http://wiki.civicrm.org/confluence/display/CRMDOC/Installation+and+Upgrades') whi...On successfully installing CiviCRM on Joomla (I'm assuming not on the other CMSs), there's a welcome screen with four links to the old wiki/confluence (ie 'http://wiki.civicrm.org/confluence/display/CRMDOC/Installation+and+Upgrades') which would better point to new (https) docs pages. The register a site link is also broken.
I'm happy to make a PR for this but not sure where the file is located, I checked in https://github.com/civicrm/civicrm-core/tree/master/install & https://github.com/civicrm/civicrm-joomla but couldn't see it. Maybe it's not an actual smarty template but something that's passed to Joomla's UI as it looks natively styled in J3 and J4?
![image](/uploads/8b0a011ff0531bcfc719e6b4eb5e30b0/image.png)
New links needed for:
- 'Installation Guide' - I guess to this: https://docs.civicrm.org/user/en/latest/initial-set-up/installation-and-basic-set-up/
- Create front-end forms and searchable directories using Profiles - https://docs.civicrm.org/user/en/latest/organising-your-data/profiles/
- Create online contribution pages - https://docs.civicrm.org/user/en/latest/contributions/online-contributions/
- Create events with online event registration - https://docs.civicrm.org/user/en/latest/events/what-is-civievent/
- Register a site - https://civicrm.org/register-a-sitenicolnicolhttps://lab.civicrm.org/dev/core/-/issues/3470Search Kit: Mailing labels don't work2022-12-19T15:47:10ZJonGoldSearch Kit: Mailing labels don't workMailing labels don't work with Search Kit.
**Steps to Replicate**
* Do a search for contacts in search kit (with a small number of contacts to avoid hitting #3222).
* Select 1 or more contacts, select **Mailing Labels** from **Actions**...Mailing labels don't work with Search Kit.
**Steps to Replicate**
* Do a search for contacts in search kit (with a small number of contacts to avoid hitting #3222).
* Select 1 or more contacts, select **Mailing Labels** from **Actions**.
* Select a label and press **Make Mailing Labels**.
**Expected Result**
Mailing labels.
**Actual Result**
Spins indefinitely.
This doesn't happen when making PDFs, or if you grab the last HTTP request from the devtools Network tab and open it in a new window.
It happens because TCPDF isn't expecting to be in a "snippet" context at this point - it's just spitting out raw HTML response headers direct to the browser (`CRM_Contact_Form_Task_Label::createLabel()` calls `$pdf->Output()`). "Make documents" uses the more modern `CRM_Utils_PDF_Utils::html2pdf(), which uses DOMPDF or wkHTMLtoPDF, and knows how to handle this. Unfortunately, TCPDF has the mailing label functionality, so we're stuck with it.
**How to proceed**
I could probably make a fix that involves saving the file to disk first - but I think a better fix is to modify the Search Kit "Actions" JS to open the labels in a new window, but I can't find where that happens.https://lab.civicrm.org/dev/core/-/issues/3462Event location search2024-01-31T10:18:23Zaydunsaidan.saunders@squiffle.ukEvent location searchOverview
----------------------------------------
Following on from #2103 - when configuring an event and reusing a location, Civi shows a message like 'This location is used by 2 other events' but does not indicate which events.
It w...Overview
----------------------------------------
Following on from #2103 - when configuring an event and reusing a location, Civi shows a message like 'This location is used by 2 other events' but does not indicate which events.
It would be useful to show a list of those locations, or include a link to search for them.
Note that SearchKit displays now handle LocBlocks (see #2676)https://lab.civicrm.org/dev/core/-/issues/3453Afform - relationships fill from other entity2022-12-07T01:43:54ZsamuelsovAfform - relationships fill from other entityFollow-up from https://github.com/civicrm/civicrm-core/pull/23296#issuecomment-1119014194
Let say we want to do a form that allow an employer to update :
- the main contact of the organization
- all the employees
Thanks to https://lab....Follow-up from https://github.com/civicrm/civicrm-core/pull/23296#issuecomment-1119014194
Let say we want to do a form that allow an employer to update :
- the main contact of the organization
- all the employees
Thanks to https://lab.civicrm.org/dev/core/-/issues/3117 it's now possible to do a form that will allow to create in one step :
- the organization
- the main contact as Individual 1 with a relationship between the organization and Individual 1
- the employees as Individual 2 with a relationship between the organization and Invividual 2 (which is multiple)
However, there is no way to have an edit mode for such a form. It's possible to add the organization id as an argument but we also need a way to pre-populate the main contacts / list of employees as an option based on the relationships definition.colemanwcolemanwhttps://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/backdrop/-/issues/9Shoreditch styling2023-01-18T16:43:38ZlarynShoreditch stylingWould it be appropriate to add some CSS and/or functionality that cleans up the Shoreditch display out of the box for Backdrop? (Is Shoreditch still slated to become the default theme at some point?)
For example:
- https://github.com/...Would it be appropriate to add some CSS and/or functionality that cleans up the Shoreditch display out of the box for Backdrop? (Is Shoreditch still slated to become the default theme at some point?)
For example:
- https://github.com/civicrm/org.civicrm.shoreditch/issues/539
- I've also noticed the Backdrop-specific CSS clobbers a little too hard and overrides in Shoreditch as well:
https://github.com/civicrm/civicrm-backdrop/blob/1.x-master/civicrm_backdrop.css#L5-L10
(We may be able to tweak those to hit a sweet spot where it overrides Backdrop styles as desired, but not Shoreditch tab styles).https://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/3399Self-service cancellation and transfer can't be separated2023-04-25T19:33:41ZJonGoldSelf-service cancellation and transfer can't be separatedCurrently, you can enable self-service "cancel and transfer". This means you can't enable self-service cancellation for events where registration is non-transferable.
NB: This whole self-service event code would make a much better exte...Currently, you can enable self-service "cancel and transfer". This means you can't enable self-service cancellation for events where registration is non-transferable.
NB: This whole self-service event code would make a much better extension than core code.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3387Captcha not working when registering multiple participants online from same p...2022-09-30T12:56:35ZMartinCaptcha not working when registering multiple participants online from same profile (Jira CRM-21824)I'm having this issue (on civi 5.14.1) and found it on Jira but not here... So I'm restarting it. :)
Original: https://issues.civicrm.org/jira/browse/CRM-21824
Copied description:
* When creating an event and allowing contacts to regi...I'm having this issue (on civi 5.14.1) and found it on Jira but not here... So I'm restarting it. :)
Original: https://issues.civicrm.org/jira/browse/CRM-21824
Copied description:
* When creating an event and allowing contacts to register multiple participants online.
* And where the profile for the registration has captcha enabled
* And where the additional participants are registered using the same profile as the initial contact.
* Online registration is failing with a message that the captcha hasn't been completed.
In earlier versions if multiple participants where booked via this method. The first participant record was shown the captcha and this held for subsequent booked participants. This bug was noticed after a client moved from 4.6 to 4.7 versions. Answer at the moment is to not allow multiple participants, or to create a new profile without captcha for recording additional participants.https://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/3314Contribution pages with memberships don't validate correctly when using "quic...2024-02-27T01:10:05ZJonGoldContribution pages with memberships don't validate correctly when using "quick config" price fieldsIn `CRM_Contribute_Form_Contribution_Main::formRule`, there are multiple references to `$self->_useForMember`. `$self->_useForMember` is only `TRUE` if the price set is a "quick config" price set (and is explicitly used as such in the t...In `CRM_Contribute_Form_Contribution_Main::formRule`, there are multiple references to `$self->_useForMember`. `$self->_useForMember` is only `TRUE` if the price set is a "quick config" price set (and is explicitly used as such in the template). However, during `formRule` validation, it's used as a proxy for "this contribution page uses memberships". @mattwire correctly identified the problem on the confirmation class in [PR 15094](https://github.com/civicrm/civicrm-core/pull/15094).
As a result, several membership-specific validations are bypassed.
I attempted to move his methods to the shared `ContributionBase` class and make them protected, but I ran into deeper validation issues. I can't justify further work on this, but wanted to document for future folks who bang their heads against this.https://lab.civicrm.org/dev/core/-/issues/3313Unable to save a membership with a text price field2023-12-19T22:18:09ZDaveDUnable to save a membership with a text price fieldSame problem in 5.28 and master and can reproduce on dmaster.demo.civicrm.org. Or maybe I'm missing something.
1. Create a price set used for memberships.
1. Set financial type to member dues.
1. Add one text field (the default input fi...Same problem in 5.28 and master and can reproduce on dmaster.demo.civicrm.org. Or maybe I'm missing something.
1. Create a price set used for memberships.
1. Set financial type to member dues.
1. Add one text field (the default input field type).
1. Amount doesn't matter - put in some number.
1. Leave other fields at defaults.
1. Create a new membership.
1. Choose the price set.
1. Put in quantity 1.
1. Can leave the rest at defaults.
1. Click Save.
1. ERROR: Select at least one membership option.
It works with a radio field.https://lab.civicrm.org/dev/core/-/issues/3311Proposal - store metadata on membership renewal on line item2023-06-18T00:43:47ZeileenProposal - store metadata on membership renewal on line item~~UPDATE - discussion on this is converging on adding a new json field 'metdata' to the line item table, permitting data related to that line item to be stored at point of order, and used when confirming. (UPDATE - this is not really the...~~UPDATE - discussion on this is converging on adding a new json field 'metdata' to the line item table, permitting data related to that line item to be stored at point of order, and used when confirming. (UPDATE - this is not really the convergence now - proposal updated below)~~
We have a few issues open ( https://lab.civicrm.org/dev/membership/-/issues/28 , https://lab.civicrm.org/dev/core/-/issues/1402 , https://lab.civicrm.org/dev/financial/-/issues/53 ) that are to my mind blocked by us not having a data model that holds the user's intent when renewing. The focus of this gl is the data model and exposing it via the back office renewal form & doing what is needed in the apis.
**The problem**
When renewing an expired membership the back office user has a fairly blunt way of influencing the calculated dates - they can set the 'renewal date'. However, if the payment is not made in the same form submission that intent is not captured anywhere and cannot be respected when completing the transaction. Likewise the receipt text and number of renewal terms are not captured.
**The proposal data model**
1) add membership_num_terms to civicrm_line_item table.
2) add 'payment_completion_metadata' to the ~~civicrm_line_item~~ civicrm_contribution table for data that is only used in the order->payment flow. Limit what can be stored here to tested values used in that flow - likely to be the message details and effective date the renewal form uses but doesn't sotre.
~~1. New field added to civicrm_line_item called 'metadata' which stores information required to complete the membership renewal - e.g. the field might store ``json_encode(['start_date' => '2010-01-01', 'end_date' => '2020-01-01', 'membership_status_id' => 'Current', 'membership_num_terms' => 2']~~
~~- note this is the new proposal - but I'm wondering what happens if it's renewed in the meantime & then paid~~
~~- New status 'Pending renewal' used when there is a need to record the dates (is_current_member = 0, is_reserved = 1, is_admin = 1 too I think)~~
~~- When a contribution linked to a membership in 'Pending renewal' is completed the status is updated but the dates are not changed~~
~~- If a membership has 'Pending renewal' status and status_override_end_date is set then any processing of that membership after that date would result in it being reverted to previous dates and status - this information should be available in the membership_log table.~~
**Proposed form exposure**
No proposed form changes - this is just storing data already submitted in the renewal form.
~~- the logic could be used outside of existing core forms but within core I think this is something we are exposing to the back-office user doing a renewal - they already have considerable ability to edit dates. So I think this is a form layer thing not some site-wide setting.
- when renewing an expired membership the renewal form would present the user with what will happen to the start date, end date etc if payment is received on that day and offer a checkbox to specify dates - if that is checked then date fields would be exposed an on save the Pending Renewal status would be used with the selected dates.
- potentially the user can also enter the date the 'offer' is available until - ie status_override_end_date~~
**Edge cases**
1. Multiple terms
We would add an extra field membership_num_terms to the line items column
~~https://lab.civicrm.org/dev/membership/-/issues/28 throws up the edge case that more than one renewal term might be selected. Both @jptillman and I assumed that the right way to represent that would be setting qty = n and then picking that when confirming. @andrewhunt didn't think that was the right assumption https://github.com/civicrm/civicrm-core/pull/18618. If we come down on NOT setting qty then we ALSO need a way to record intent for non-expired renewals - this could be an extra membership_num_terms column on the line_item table. (I'm still inclined to my original assumption but more points of view needed).~~
2. About to expire rather than actually expired
Out of scope for now - just do what the form currently does
~~I think we would still manage this in the form ie - "the membership is due to to expire in 4 days, if payment is received after that then .... ' and present the same options as for an actually expired membership~~https://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/core/-/issues/3301Contrast ratios2024-02-28T11:51:33ZJoeMurrayContrast ratiosWCAG 2.0 specifies various minimum contrast ratios between foreground and background for different sizes of fonts, and for bolded and non-bolded fonts [https://www.w3.org/TR/WCAG20-TECHS/G18.html](https://www.w3.org/TR/WCAG20-TECHS/G18.h...WCAG 2.0 specifies various minimum contrast ratios between foreground and background for different sizes of fonts, and for bolded and non-bolded fonts [https://www.w3.org/TR/WCAG20-TECHS/G18.html](https://www.w3.org/TR/WCAG20-TECHS/G18.html).
> ...Priority 2 (AA), and Priority 3 (AAA). Whether or not you need to reach an AAA conformance depends on your target audience. Read more about this [on the w3 site](http://www.w3.org/TR/2005/WD-WCAG20-20051123/intro.html#conformance). For large text (over 18 points) the contrast ratio for AA is 3:1 and for AAA 5:1. For small text it's 5:1 for AA and 7:1 for AAA. ([http://www.colorsontheweb.com/Color-Tools/Color-Contrast-Analyzer](http://www.colorsontheweb.com/Color-Tools/Color-Contrast-Analyzer))
More exact ratios and translations of font sizes to px directly from the WCAG first mentioned for bold and non-bold text are:
* **BOLD and < 14pt (18.5px):** 7:1 contrast ratio
* Not bold and < 18pt (24px): 7:1 contrast ratio
*
* **BOLD and >= 14pt (18.5px):** 4.5:1 contrast ratio
* Not bold and >= 18pt (24px): 4.5:1 contrast ratio
Using the contrast analyzer provided on the page above, the current Shoreditch contrast ratios are not sufficient in some contexts.
For example, on pages like New Contact and New Activity we get the following ratios:
Blue font #2786c2 on tan #efefe5 in 13px: 3.44:1 (below 5:1)
Dimmed grey #999999 on offwhite #fff in 13px: 2.85:1 (below 5:1)
![2018-12-04_09-16-41](/uploads/efe32b9def1089f434b0cf1c11ef1b6e/2018-12-04_09-16-41.png)
![2018-12-04_09-33-52](/uploads/171119a46775a677bd44664497507def/2018-12-04_09-33-52.png)
![2018-12-04_09-51-12](/uploads/1a9006ebddb3d210f2b326d41d29f8cc/2018-12-04_09-51-12.png)
We should meet a 5:1 ratio for all text < 18pt.