Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-19T20:19:43Zhttps://lab.civicrm.org/dev/core/-/issues/3769Change the default font family to sans-serif in print.css2024-03-19T20:19:43ZwmortadaChange the default font family to sans-serif in print.cssThe font family is set as `DejaVu Sans` but the fallback is `serif` in `print.css`. Surely this should be `sans-serif`?
See https://github.com/civicrm/civicrm-core/blob/master/css/print.css#L23
```
#crm-container {
overflow: visible ...The font family is set as `DejaVu Sans` but the fallback is `serif` in `print.css`. Surely this should be `sans-serif`?
See https://github.com/civicrm/civicrm-core/blob/master/css/print.css#L23
```
#crm-container {
overflow: visible !important;
font-family: DejaVu Sans, serif;
margin: 0px 10px 0px 10px;
}
```https://lab.civicrm.org/dev/financial/-/issues/202Unable to update recurring amount when using Sales Tax2022-08-03T15:19:05ZKarinGUnable to update recurring amount when using Sales TaxHitting Edit on the template contribution (with or without line item editor extension - June 2022 version) -> saving it [multiple times] -> does not update the amount in the recurring series -> note the mismatches of amounts:
![image](/...Hitting Edit on the template contribution (with or without line item editor extension - June 2022 version) -> saving it [multiple times] -> does not update the amount in the recurring series -> note the mismatches of amounts:
![image](/uploads/8280ff94ddb4e66ba1368e64c1d4b72a/image.png)https://lab.civicrm.org/dev/core/-/issues/3762SearchKit roadmap2023-11-10T12:30:29ZwmortadaSearchKit roadmapThis roadmap is based on a [Google Doc](https://docs.google.com/document/d/1PfgV48_Fc6rup5PexPpxOvnd5nV9NOjN8dieglxHAyM/edit#) created as part of the regular Form Builder / SearchKit meetings.
It could do with some tidying up and more d...This roadmap is based on a [Google Doc](https://docs.google.com/document/d/1PfgV48_Fc6rup5PexPpxOvnd5nV9NOjN8dieglxHAyM/edit#) created as part of the regular Form Builder / SearchKit meetings.
It could do with some tidying up and more details on some items.
See also dev/core#3761
## Improvements
- [ ] [Action permissions](https://docs.google.com/document/d/1SM_kdMVmxgV0jarYphXHuysERRdEt-w1bhKzZTwVaKA/edit#heading=h.g2m0sr8ujije)
- [ ] Data visualisations - develop support for advanced visualisations for SearchKit data display
- [ ] Emailing results of SearchKits
- [ ] Embed on remote site - check inlay (https://lab.civicrm.org/extensions/inlay)
- [ ] [Recreate core screens as Search Displays](https://lab.civicrm.org/dev/core/-/issues/3912)https://lab.civicrm.org/dev/core/-/issues/3761Form Builder roadmap2023-11-10T12:30:28ZwmortadaForm Builder roadmapThis roadmap is based on a [Google Doc](https://docs.google.com/document/d/1PfgV48_Fc6rup5PexPpxOvnd5nV9NOjN8dieglxHAyM/edit#) created as part of the regular Form Builder / SearchKit meetings.
It could do with some tidying up and more d...This roadmap is based on a [Google Doc](https://docs.google.com/document/d/1PfgV48_Fc6rup5PexPpxOvnd5nV9NOjN8dieglxHAyM/edit#) created as part of the regular Form Builder / SearchKit meetings.
It could do with some tidying up and more details on some items.
See also dev/core#3912 for tracking conversion of Admin screens and dev/core#3762 for SearchKit items
## Support more entities
- [x] CiviCase
- [x] Participants https://github.com/civicrm/civicrm-core/pull/24420
- [ ] Surveys/Petitions
- [x] Grants
- [ ] Contributions
- [ ] Group opt ins
- [ ] Generalized entity support (generic create/edit forms for any entity type, including custom civix-generated entities)
## Support more workflows
- [x] Ability to add tokens to form submission redirect URL https://github.com/civicrm/civicrm-core/pull/24016
- [x] Add to navigation menu https://github.com/civicrm/civicrm-core/pull/24013
- [x] CAPTCHA support https://lab.civicrm.org/dev/core/-/issues/3173
- [ ] Multi-step forms
- [ ] Conditional fields https://github.com/civicrm/civicrm-core/pull/24699
- [ ] Form-only fields that can be used in conditionals. Eg. _"for example I want to ask 'Do you want to add another child?' and have yes or no, the yes then opens another individual contact to be created on the form, but i don't want to have this question as a custom field as it will never be looked at."_
- [ ] Display values after submission
- [ ] Support remote display and submission (https://civicrm.org/make-it-happen/formbuilder-remote-forms)
## Other improvements
- [x] Improve validation
- [.] Client side validation https://github.com/civicrm/civicrm-core/pull/23604
- This is only partially implemented and does not work for select2 and multiple checkboxes (at least) - see https://github.com/civicrm/civicrm-core/pull/25535 and https://github.com/civicrm/civicrm-core/pull/25536 for details.
- [x] Server side validation https://lab.civicrm.org/dev/core/-/issues/3760
- [ ] Payment processors
- [ ] Price sets
- [ ] “Pagebuilder”
- [x] Support entity ref with pre-population
- [ ] Embed on remote site - check inlay (https://lab.civicrm.org/extensions/inlay)
- [x] Display-only fields (https://lab.civicrm.org/dev/core/-/issues/3779)
- [x] ‘Add New’ button ([Added to SearchKit](https://github.com/civicrm/civicrm-core/pull/24512/commits/8d0bafa435d7b2eed771cd2dd2c180e566063592))
- [ ] Add a config link shown to admins
- [ ] More/better APIs/examples for hooking into forms (from extensions)
- [ ] post-submit tokens
- [ ] contact widget in drupal webform
- limit an entity-ref
- pull up data for contact from entity-ref (get their name/address)
- [x] entity-ref: is it api4 or api3? https://github.com/civicrm/civicrm-core/pull/24832
- [ ] More in-place “Edit” links (for admins)
- [ ] WordPress Gutenberg block
- see [Afform - support embedding forms via WP](https://github.com/civicrm/civicrm-core/pull/19687/files#diff-5af5dcb53864f5076881abda3a70b38143ee4b7be5b1c1fce453bf4721db74f2R533-R549) for inspiration
- [ ] Tag support
- [x] Deduplication https://github.com/civicrm/civicrm-core/pull/24552
- [ ] Support url-params and other config options for Values in Submmission forms https://lab.civicrm.org/dev/core/-/issues/3910
- [ ] Hidden fields https://github.com/civicrm/civicrm-core/pull/24161
- [x] Copy a search display in the UI
- [x] Add a 'Copy' button for repeating elements - like the existing 'Add' button but copying the values entered in the source. Was "Bulk create defaults" dev/core#3986 https://github.com/civicrm/civicrm-core/pull/26071
- [ ] Date filtering options dev/core#3985
- [ ] Add tab display see https://github.com/civicrm/civicrm-core/pull/24981
- [ ] Add way to link to local URL's in helptext see https://github.com/civicrm/civicrm-core/pull/24981
- [ ] Decide how to handle popup help text currently in `.hlp` files - new element on form? eg see https://github.com/civicrm/civicrm-core/pull/24981
- [ ] Add way to handle popup warnings before action see https://github.com/civicrm/civicrm-core/pull/24981
- [ ] Allow 'Add New' button to open full-page, not just pop-up - eg https://github.com/civicrm/civicrm-core/pull/24937
- [ ] Add general purpose button? eg 'Manage Personal Campaign Pages' button - see https://github.com/civicrm/civicrm-core/pull/24937
- [ ] Improve SK UX - see dev/user-interface#49
- [ ] Allow generic / "preset" formatting instead of hardcoding colours etc. per form. Eg specify preset "Generic search form" to make it look like every other search form.
- [ ] Conditional field formatting based on other field values.
- [ ] Create a way to add someone to a group from a Submission form
- [ ] In SK, be able to use custom fields in joins. (Eg with Related Contacts, want to include if custom field matches criteria. NB you can use custom fields in Where clauses but that turns 'with (optional)' into 'with (required)' dev/core#3972
- [ ] Smart totals for monetary amounts: a listing of contributions £1, £2, $3 should show a total of £3, $3 not '6'. Many contribution reports need this. More generically, allow aggregates over more multiple fields but summing contribution amounts is possibly the main use case. dev/core#4207
## Reimplement in a framework other than AngularJS
AngularJS was released in 2010 with Google discontinuing support at the end of 2021. It is the primary javascript technology used in SearchKit and especially FormBuilder.
- [x] Research options including health and market share momentum of project/community, impact on developer experience, etc. Options might include React, Angular, etc.
- [X] discuss with community at Manchester Sprint
- [X] Develop scope and estimates for migrating to React as part of a large grant proposal
- [ ] develop prioritized epics for migration starting with some proof of concept LExIM extensions
- [ ] through MIHs and developer commitments plan how to resource a phased migration to the selected new technology optionhttps://lab.civicrm.org/dev/core/-/issues/3760Add server side validation for afform2023-03-08T17:56:47ZKurund JalmiAdd server side validation for afformCurrently, there is some work done on the frontend to add client side validation and it would be good to add the same at the API end.Currently, there is some work done on the frontend to add client side validation and it would be good to add the same at the API end.Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/financial/-/issues/201Stop adding 'In Progress' and 'Overdue' statuses to civicrm_contribution.cont...2022-09-15T21:47:08ZeileenStop adding 'In Progress' and 'Overdue' statuses to civicrm_contribution.contribution_status_id option groupThis has been around as a back burner project for a while but didn't have it's own gitlab ... tada
A long long time ago contribution, contribution recur, payments, pledges and pledge payments shared the same option group for their statu...This has been around as a back burner project for a while but didn't have it's own gitlab ... tada
A long long time ago contribution, contribution recur, payments, pledges and pledge payments shared the same option group for their status & some nasty magic massaged values in and out. Overdue and In progress 'leaked' from these other entities onto the contribution in a long-ago regression but was never intended as a contribution status option value in core.
The plan is to stop adding those statuses on NEW installs. (We might add a message on non-new installs that have them but we don't really want to remove them).
Unfortunately this has been a slow-burner as the tests found code places referencing the wrong option group list in many cases - I've slowly been whittling these down & as of writing three tests are failing
https://github.com/civicrm/civicrm-core/pull/23074
Note that this was notified in a long-ago dev-digest and steps have been taken in the Sepa extension (the only one identified as using these statuses) to ensure they are presenthttps://lab.civicrm.org/dev/core/-/issues/3752Membership terms present in price set not get used in the offline form signup.2024-03-15T02:23:37ZsunilMembership terms present in price set not get used in the offline form signup.Overview
----------------------------------------
Number of Terms present in priceset not get used while signing up using offline form.
Reproduction steps
----------------------------------------
1. Crete Price and field of Select opti...Overview
----------------------------------------
Number of Terms present in priceset not get used while signing up using offline form.
Reproduction steps
----------------------------------------
1. Crete Price and field of Select option.
1. Use Membership type `Student` which is 1 year duration.
1. Use the same membership type with different terms.
1. Now, go to the contact and sign up for membership using priceset.
1. Use Membership with 2 or 3 year terms.
1. Result : it extends by only 1 year.
Current behaviour
----------------------------------------
Irrespective of different terms of membership, membership only extends by only one year.
Expected behaviour
----------------------------------------
Membership should extend as per terms set in the price set field option.https://lab.civicrm.org/dev/financial/-/issues/200Contribution status’s are ambiguous (WIP)2022-09-10T05:42:18ZJamie Novick - CompucoContribution status’s are ambiguous (WIP)**Background:**
Contribution status’s are ambiguous in CiviCRM and can lead to confusion over the current state of an invoice or contribution and whether there are amounts owed or owing to the contributor. This leads to a wealth of prob...**Background:**
Contribution status’s are ambiguous in CiviCRM and can lead to confusion over the current state of an invoice or contribution and whether there are amounts owed or owing to the contributor. This leads to a wealth of problems about what the intention of the user really is in a number of scenarios when they change the contribution status.
Examples:
| Example | Narrative | Video |
| ------ | ------ | ------ |
| Example 1a: Overpayment / pending refund | A contribution which is created for $100 donation, but pending. We then record an overpayment of $120. Hypothetically the contribution is overpaid by $20 and should be pending refund. This is not shown in CiviCRM. There is nothing showing the user that there is an overpayment of $20.| ![1-Overpayment](/uploads/74eca492a8d044aa17033dd681922c4a/1-Overpayment.webm)
| Example 1b: Change contribution status to refunded | We can further demonstrate this by taking the same contribution and then changing the status of the contribution to refunded. This raises the question of what this means? Does this reflect the users intention to: Cancel the original debt of $100 (i.e. to credit note the original amounts owed and clear the balance Or reflect the fact a refund was made for the payment of $120, but that they are still owed the original $100 Or both? CiviCRM has refunded the original value of the invoice, i.e. $100, even though the payment of $120 was received. As such we still owe $20 but this is not shown in CiviCRM.|![2-Change_status_to_refunded](/uploads/bf9eae010687771d440b4baa0d528d1e/2-Change_status_to_refunded.webm)
| Example 2: A typo entered in the wrong contribution amount | Add a contribution for $100 and set as completed. Realised that actually the contribution was $120. System will automatically add the additional $20 payment. Note: If this was a change in the line items of an invoice, it would not be safe to assume we received the additional payment. The aim of the user might be to state the obligation to pay was $120. Also it probably wasn’t 2 separate payments and hence we should reverse out the first payment (-100) and then make a second payment for the full amount (+120) | ![Updating_a_contribution_amount_error](/uploads/bda0cc37c9c5911b54bb429367bdffbf/Updating_a_contribution_amount_error.webm)
Much of this stems from the contribution status field being both be the driver of changes to the contribution (i.e. by changing the status to completed or refunded) or changed itself (i.e. the result of changes to the position of the contribution) by recording payments or refunds.
As such this is a proposal to simplify this workflow so that the the contribution status is only the result of the status of the contribution, and can no longer be used to change the status of the contribution.
We would retain the ability to make changes to the contribution status via the API for backwards compatibility until extensions can adopt the new model.
**Further ramblings (feel free to skip this part if you are not too interested in accounting principles)**
Accounting has simple and sounds principles for dealing with all of this.
“Obligations” are managed by 2 documents: Invoices and Credit notes. An invoice would stipulate what is obligated. This can be reduced by creating a credit note, which would then reduce the obligated amount.
It’s worth noting that for sales tax (for example VAT) purposes invoices should be sequentially numbered and should not be edited once they are generated. Hence usually you would not just simply delete an invoice to reduce the obligated amount, you would create a credit note for some or all of the amount, apply it to the invoice and send that to the customer to show the reduce in their balance owed to you.
As such I think in CiviCRM we need to fully enforce the split of concepts of the “obligation” and the actual payments (or refunded) amounts. Currently we have started on the journey towards that where Contributions (and line items on them) represent the obligations in most cases, and payments (or financial transactions of type payment) are the payments.
The contribution status should be a reflection of the net of that position. Does the customer owe us money (= pending or partially paid*) or is the balance settled (= completed) or do we owe them money (= pending refund)?
</details>
**Proposed changes:**
1. Recalculate the contribution status whenever a contribution is created or updated
We should recalculate the contribution status whenever a contribution is created or updated based on the following rules:
| Ref | Calculation | Status |
| ------ | ------ | ------ |
| 1 | If there are no payments or refunds | Pending (arguably there would be a better label for this but in order to avoid making actual changes to the contribution status options this would seem to be the best fit) |
| 2 | If the sum of the line items (including any tax line items) > (sum of payments received - sum of refunds paid out) | Partially paid |
| 3 | If the sum of the line items (including any tax line items) < (sum of payments received - sum of refunds paid out) | Pending refund |
| 4 | If the sum of the line items (including any tax line items) = (sum of payments received - sum of refunds paid out) | Completed |
2. Changes to the User interface:
| Screen | How it looks currently | How it will work | Changes required |
| ------ | ------ | ------ |------ |
| New contribution screen | ![image](/uploads/568a11ebd7cc0b44edc36077d06f62d8/image.png) | ![Create_new_contribution](/uploads/cb028a89f3c3cc2c3798128efaa4e0d6/Create_new_contribution.png) | We split the "obligation" with the "payment". As such we remove the contribution status field from this screen and instead allow people to decide whether they want to record the "payment" at the same time as recording the "obligation" by checking the "Record payment" checkbox. The contribution status would then be calculated using the logic above. i. |
| View contribution screen (one line item) | ![Screenshot_2022-08-29_at_11.26.55](/uploads/02854f20d41d8ffec5159fa1977627e0/Screenshot_2022-08-29_at_11.26.55.png) | | No Changes |
| View contribution screen (multiple line items) || | |
| Edit contribution screen (one line item) | ![Screenshot_2022-08-29_at_11.30.42](/uploads/6faaed62b313698c1a4346956f48e719/Screenshot_2022-08-29_at_11.30.42.png)| ![Screenshot_2022-08-29_at_11.37.56](/uploads/68293bdc8d48c548606793c6a64d159d/Screenshot_2022-08-29_at_11.37.56.png)| Status field becomes read only and we introduce a button to cancel the contribution. See below for new screen for cancelling a contribution|
| Edit contribution screen (multiple line items) || | |
| New membership screen | ![image](/uploads/568a11ebd7cc0b44edc36077d06f62d8/image.png) | cell | ------ |
| View membership screen (one line item) | | ||
| View membership screen (multiple line items) | | ||
| Edit membership screen (one line item) | | ||
| Edit membership screen (multiple line items) | | ||
| New event participant screen | ![image](/uploads/568a11ebd7cc0b44edc36077d06f62d8/image.png) | ![New_participant](/uploads/7837cf2271b10bb5824d11483221037a/New_participant.png) | Change the checkbox "Record Payment" to "Record Contribution" OR have a toggle to allow the admin to decide whether they are recording a "Paid" or "Free ticket". We only need the financial type and contribution date if we are only recording the contribution (note in https://lab.civicrm.org/dev/core/-/issues/1403 we have agreed to change label of contribution received date to contribution date). The amounts / lines should come from above. |
| View event participant screen (one line item) | | ||
| View event participant screen (multiple line items) | | ||
| Edit event participant screen (one line item) | | ||
| Edit event participant screen (multiple line items) | | ||
- Removehttps://lab.civicrm.org/dev/user-interface/-/issues/48Swap out CiviCRM logos2023-10-07T10:15:12Zjoshjosh@civicrm.orgSwap out CiviCRM logosRequest to replace the current logos displayed in-app and in the "empowered by" display with current CiviCRM logos. Attached files match the current logo dimensions and file names.
![civi99.svg](/uploads/a78c0fe05886784ef83ad0c4ab6c05e0...Request to replace the current logos displayed in-app and in the "empowered by" display with current CiviCRM logos. Attached files match the current logo dimensions and file names.
![civi99.svg](/uploads/a78c0fe05886784ef83ad0c4ab6c05e0/civi99.svg)
![civi99](/uploads/d629d77f01db2750813f08178c264cbb/civi99.png)
![logo_words_small](/uploads/8c5a775cba670ed1854bcf86468e282c/logo_words_small.png)https://lab.civicrm.org/dev/core/-/issues/3740Set default lock level to READ COMMITTED2023-10-20T07:57:25ZJoeMurraySet default lock level to READ COMMITTEDDrupal recently changed the default lock level slightly down from REPEATABLE READ to READ COMMITTED, which has the effect of avoiding some db locks. See https://www.drupal.org/node/3269885 We have seen over recent years some issues with ...Drupal recently changed the default lock level slightly down from REPEATABLE READ to READ COMMITTED, which has the effect of avoiding some db locks. See https://www.drupal.org/node/3269885 We have seen over recent years some issues with deadlocks, primarily on rebuilding group contact cache when there are hierarchies of smart groups. Should CiviCRM be more explicit about what isolation level we expect in order to get more repeatable results, and should we follow Drupal in its move to READ COMMITTED? I tend to think so.
See responses in MM chat from @demeritcowboy
https://chat.civicrm.org/civicrm/pl/gnmhfdxes7rgb8k7ppoaezo45ahttps://lab.civicrm.org/dev/core/-/issues/3738Feature request - APIv4 Get action, provide ability to define aliases for the...2024-03-15T14:56:37Zjustinfreeman (Agileware)Feature request - APIv4 Get action, provide ability to define aliases for the select fields so that external integrations with CiviCRM do not break when the field name changes OR a different field is selectedThis is a Feature request. It would be great if you could define an **alias** for each _select_ **field** when using a **APIv4 Get action**. This alias should then be used as the output in the results for the Get action.
This would enab...This is a Feature request. It would be great if you could define an **alias** for each _select_ **field** when using a **APIv4 Get action**. This alias should then be used as the output in the results for the Get action.
This would enable external CiviCRM integrations to be more robust, by allowing the fields selected in the Get action to be **changed** and but continue to use the **same alias**, thus not changing the structure of the results, the external integration would continue to work.
The other benefit would be that very long CiviCRM field names could be reduced to something shorter or more logical. eg. Instead of "email.email" the alias could just be set to "email". Or instead of "email_greeting_id:label" the alias could just be "email_greeting".
![image](/uploads/2ccae5082e4f50f5fc924d8e6998ffaa/image.png)https://lab.civicrm.org/dev/core/-/issues/3730Search Kit: data exported to spreadsheet as strings where numbers expected2023-08-25T14:47:13ZAndreasandreas.howiller@civiservice.deSearch Kit: data exported to spreadsheet as strings where numbers expectedOverview
----------------------------------------
When exporting spreadsheets from Search Kit in some cases data types seem to be exported incorrectly as strings where they should be numbers.
Reproduction steps
------------------------...Overview
----------------------------------------
When exporting spreadsheets from Search Kit in some cases data types seem to be exported incorrectly as strings where they should be numbers.
Reproduction steps
----------------------------------------
1. Create Search Kit search for **Contributions** on demo.
2. Add columns for **Total Amount** and **Date Received** and click **Search**.
3. Export results via **Action** → **Download Spreadsheet** and choose **.ods** (or **.xlsx**).
4. Open document with office software.
Current behaviour
----------------------------------------
While the Contribution ID column is correctly formatted as a number, Total Amount and Date Received are formatted as **strings**.
Note: Numbers are also left-aligned in Search Kit exports (column A).
Here is what the file looks like in LibreOffice 6.4.7.2:
![grafik](/uploads/ede5de9d9898448c1e0d2676863cfc17/grafik.png)
…and here the corresponding XML in content.xml:
![grafik](/uploads/9487cc0e42f0980eb08e958bea23e7f4/grafik.png)
Expected behaviour
----------------------------------------
Numbers and Date fields are exported in correct data type.
Additional ideas / Comments
----------------------------------------
- it would probably be very useful to have **more Field Transformations** to have some choice for data types, esp. to be able to output money values with our without money signs
- maybe numbers should not be left-aligned anymore (as it is the standard behaviour in spreadsheets)
Environment information
----------------------------------------
* CiviCRM: 5.52.alpha1 and 5.50.3
* PHP: 7.4
* CMS: WordPress 6.0 and Drupal 9.3.14https://lab.civicrm.org/dev/core/-/issues/3714CiviCRM Contribution Page, total amount calculation is sometimes off by one o...2023-07-18T05:40:43Zjustinfreeman (Agileware)CiviCRM Contribution Page, total amount calculation is sometimes off by one or two cents, which causes incorrect amount to be paid or transaction to fail depending on the Payment Processor being usedWhen using a **CiviCRM Contribution Page** the total amount calculation is sometimes off by one or two cents, which causes incorrect amount to be paid or transaction to fail depending on the Payment Processor being used.
In the case of ...When using a **CiviCRM Contribution Page** the total amount calculation is sometimes off by one or two cents, which causes incorrect amount to be paid or transaction to fail depending on the Payment Processor being used.
In the case of Stripe, the _correct amount_ is _pre-authorised_. When the payment is _confirmed_ the _incorrect amount_ is used and because the two amounts do not match, the **transaction fails**. As a result this bug prevents payments from working with Stripe as a payment processor for certain amounts.
# Steps to reproduce
1. Enable tax and invoicing
2. Add e.g. a 10% GST account to Member Dues
3. Create a membership prices set with one field that has three checkbox options:
4. 318.18182 (350 incl tax)
5. 22.72727 (25 incl tax)
6. 24.54545 (27 after tax - note that this would actually work out to 27.01 with the older premature rounding based off-by one issue)
7. Use this price set on a contribution page
8. Submit a test using this contribution page.
9. Note in the summary that the line totals are 350.00, 25.00, and 27.00
## Expected result
Total should be **$402**
## Actual result
Total is **$401.99** - which is one cent less than the expect value, and two cents less than the value you would get with premature rounding.
## Tested environment
Bug has been confirmed using **CiviCRM 5.52.alpha1** on https://wpmaster.demo.civicrm.org/
## Workaround
Adjust the amount to account for the rounding error. In this case, change the amount: 24.54545 to 24.5363636364 which then changes the total to $401.99. This is then matches the total on the Thank You page.
![image](/uploads/ddf3c7cbeaf3cdc4700079f79b01c7d6/image.png)
![image](/uploads/5eb33f84dfa49cad5697570a019c6936/image.png)
# Contribution page with membership options selected - correct total is shown
![image](/uploads/f35b520763e5e9f3545585f27ff42812/image.png)
# Thank you page - incorrect total is shown
![image](/uploads/d6fa209c43cbf2d721d4cf085882b1f8/image.png)
# Set up - Membership Types
![image](/uploads/01450b1f2a777f3c279e694d5ea7e007/image.png)
# Set up - Priceset
![image](/uploads/672f5c3de5b72e7817dc063388f08c38/image.png)
Agileware Ref: CIVICRM-2007https://lab.civicrm.org/dev/core/-/issues/3711Permissions reset on upgrade or configuration change2022-08-25T21:41:06ZAdam WoodPermissions reset on upgrade or configuration changeApplies to CiviCRM running on Joomla.
The permission "See CiviCRM is installed" keeps resetting by itself. This definitely occurs whenever CiviCRM is upgraded (issue observed up to and including 5.50.4) and/or an extension is installed,...Applies to CiviCRM running on Joomla.
The permission "See CiviCRM is installed" keeps resetting by itself. This definitely occurs whenever CiviCRM is upgraded (issue observed up to and including 5.50.4) and/or an extension is installed, enabled/disabled, updated etc, and may occur at other times. I cannot discern the pattern!
This means that CiviCRM disappears from the 'Components' administrator menu unless you are logged in as Super Administrator.
Since CiviGrant was migrated to an extension, the same issue now applies to "access CiviGrant", "edit grants" and "delete in CiviGrant" - I have to keep re-applying these after each upgrade.https://lab.civicrm.org/dev/core/-/issues/3705CiviReport email sending fails if multiple recipient are specified in 'to' field2024-03-05T05:24:43ZKurund JalmiCiviReport email sending fails if multiple recipient are specified in 'to' field### Steps to replicate
1. Create report an instance
2. Configure `Email Delivery Settings`; add multiple emails in `to` field.
3. Configure this report instance to send emails via Scheduled Job
Emails are never sent
## Error in CiviCR...### Steps to replicate
1. Create report an instance
2. Configure `Email Delivery Settings`; add multiple emails in `to` field.
3. Configure this report instance to send emails via Scheduled Job
Emails are never sent
## Error in CiviCRM logs
```bash
[error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => 10006
[message] => Failed to send data [SMTP: Invalid response code received from SMTP server while sending email. This is often caused by a misconfigura
tion in Outbound Email settings. Please verify the settings at Administer CiviCRM >> Global Settings >> Outbound Email (SMTP). (code: 554, response: Tra
nsaction failed: Domain contains illegal character)]
[mode] => 16
[debug_info] =>
[type] => PEAR_Error
[user_info] =>
[to_string] => [pear_error: message="Failed to send data [SMTP: Invalid response code received from SMTP server while sending email. This is often caused by a misconfiguration in Outbound Email settings. Please verify the settings at Administer CiviCRM >> Global Settings >> Outbound Email (SMTP). (code: 554, response: Transaction failed: Domain contains illegal character)]" code=10006 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info=""]
)
```
This happens because multiple emails gets converted in to invalid emails due to `CRM_Utils_Mail::formatRFC822Email()`https://lab.civicrm.org/dev/core/-/issues/3703Confirmation emails are not sent if it is a recurring payment2022-08-25T17:04:50ZMariaVConfirmation emails are not sent if it is a recurring payment**Current behavior apparently:**
One-time donations: A confirmation email comes right after you fill out the donation form
Recurring donations: A confirmation email comes each time after the payment is processed
This works quite well ...**Current behavior apparently:**
One-time donations: A confirmation email comes right after you fill out the donation form
Recurring donations: A confirmation email comes each time after the payment is processed
This works quite well for online payment processors like PayPal, where the first payment is made within seconds of submitting the donation form.
With "asynchronous payment processors" such as SEPA, however, this approach works quite poorly, because it can take several weeks before the next payment run happens (usually once a month).
Currently this does not work at all.
Moreover, from a fundraiser's point of view, it is a real disadvantage if these confirmations are sent with every payment: People will be reminded every time that they still haven't cancelled their recurring donations.
**In contrast, the behavior most of us would like to see would be:**
One-time and recurring donations: A confirmation email comes right after you fill out the donation form
Further confirmations for recurring donations will only come if this has been set in a configuration setting.
**My suggestion:**
There could be an additional radio button:
One option that will be choosed by default which explains that the mail is only sent for recurring donations when a payment has actually been received (and for one-time donations directly). And for this purpose, there will be another option that says that a confirmation will be sent once directly after the form has been submitted - regardless of whether it is a one-time or recurring donation.
This will ensure that this function will continue to work for everyone who actually wants to use it that way - even if there are probably not many.https://lab.civicrm.org/dev/core/-/issues/3702DOMDocument::loadHTML(): Tag af-field invalid in Entity when loading dashboard2022-10-20T20:07:11ZDaveDDOMDocument::loadHTML(): Tag af-field invalid in Entity when loading dashboardI'm not sure if this is new or not. This might be something coming up for me now with php8. The error comes up in phpquery which is now provided by vendor/rubaboquery which is new, but I'm not sure it's from any differences there. I thin...I'm not sure if this is new or not. This might be something coming up for me now with php8. The error comes up in phpquery which is now provided by vendor/rubaboquery which is new, but I'm not sure it's from any differences there. I think the error is technically legit.
What's happening is during hook_civicrm_angularModules, afform loads all the blocks, such as this one: https://github.com/civicrm/civicrm-core/blob/6fa8c627a2f406329370f2b03d656dbc565ccb9f/ext/afform/core/ang/afblockContactAddress.aff.html
At https://github.com/civicrm/civicrm-core/blob/6fa8c627a2f406329370f2b03d656dbc565ccb9f/ext/afform/core/Civi/Afform/Symbols.php#L38, it creates a DOMDocumentWrapper around it, which is provided by rubaboquery. Note that it considers the block html (as opposed to e.g. xml), so calls DOMDocument->loadHTML. So I believe what's happening is that loadHTML validates it against the html schema, and `<af-field>` is not a real html tag.
See also https://www.php.net/manual/en/domdocument.loadhtml.php#125526, although I'm not saying that is the best solution. I don't know at the moment.5.56.0https://lab.civicrm.org/dev/core/-/issues/3695Search Kit: Commas in event types break IN operator2024-03-06T22:16:53ZJonGoldSearch Kit: Commas in event types break IN operatorWhen you have an event type with a comma in it, you can't search for it using the `WHERE` clause using the `IN` operator.
### Steps to Replicate
* Create a new event type with a comma in the label (which will propagate to the name).
* C...When you have an event type with a comma in it, you can't search for it using the `WHERE` clause using the `IN` operator.
### Steps to Replicate
* Create a new event type with a comma in the label (which will propagate to the name).
* Create an event with the new event type.
* Create a SK search with a `WHERE` event type `is one of` the new event type.
### Expected Result
The new event will appear.
### Actual Result
Event doesn't appear.
See screenshots comparing `=` and `is one of`.
### Comments
SK assumes that `name` fields can't have commas, so it can explode the string on a comma delimiter. This is the API query for the screenshot above (below).
If event types were their own table, I'd suggest making the `name` field be snake-cased. However, this goes against a long-standing (and probably unwise) design decision around `civicrm_option_value` names, which can be used to match on import with external systems. So this may have to get fixed in SK.
```
{
"version": 4,
"select": [
"id",
"title",
"event_type_id:label"
],
"orderBy": {},
"where": [
[
"event_type_id:name",
"IN",
[
"Development",
"Administration"
]
]
],
"groupBy": [],
"join": [],
"having": []
}
```
![Selection_1550](/uploads/03d0a44e852b431289d54eb9b9951d6e/Selection_1550.png)
![Selection_1551](/uploads/afce4bfb38cd7c3e6cd9e979e0f0c463/Selection_1551.png)https://lab.civicrm.org/dev/core/-/issues/3682Feature request - `{domain.logo}`2023-09-25T19:36:31ZeileenFeature request - `{domain.logo}`Tim & I discussed the other day adding the `{domain.logo}` token. As always when this comes up we started with 'it would be very easy to do this minimal version' and by the end of the discussion the scope was un-manageable as unsponsored...Tim & I discussed the other day adding the `{domain.logo}` token. As always when this comes up we started with 'it would be very easy to do this minimal version' and by the end of the discussion the scope was un-manageable as unsponsored work.
However, I think the thing we CAN do is document it....
**The easy way**
`{domain.logo}`
refers to the image (if any) in the image_url field for the domain contact. That's it.
Probably we would need a version with `<img>` tags & one without.
**But then ... sizing & ^^ is too basic/ limited**
So next most complex is to use a setting. Once we start down this path we wind up having to develop a UI, handling sizing and it seems we might as well skip to....
**Mailing Component tokens**
In this version we would add a new component type to `civicrm_mailing_component` and rows of this type would be available as tokens using `{domain.{civicrm_mailing_component.name}}`. Placeholders ones for '{domain.logo}' and '{domain.header}' would be added. The existing UI could be used.
**And still spiralling**
- from there we got into trying to make it possible to nest the above, to use regions, to do the sort of thing the `entity_messages` token attempted to whereby we could store entity-related snippets (the idea was both to be able to insert a contribution specific block and to store entity-specific text to re-use - e.g to re-send an invoice with the original form-base message text)https://lab.civicrm.org/dev/core/-/issues/3514Define interfaces for interacting with newly cleaned up import code2023-04-03T02:29:57ZeileenDefine interfaces for interacting with newly cleaned up import codeThis is a bit of a placeholder but I think it will be necessary for integrations to
- ~~add new user_job_types - currently this is a hard-coded list and the Parser class is hard-coded into it - we probably need to solve this to get the ...This is a bit of a placeholder but I think it will be necessary for integrations to
- ~~add new user_job_types - currently this is a hard-coded list and the Parser class is hard-coded into it - we probably need to solve this to get the csvimporter working~~ these are declared by any class that `implements UserJobInterface`
- alter the metadate - eg inject 'full_name' into the available fields to map to. UPDATE - am wondering if being able to add pseudofields for the api is enough - would work for full_name
- intervene once `getMappedRow` has run
- ideally we would extract out the `lookup` code where matching contacts are found or matching entities and add some interaction there - assuming the hook in `findDuplicates` is not enough. UPDATE - I think intervening at the end of `getMappedRow` will work
- be able to alter the validation of the mapping. I know a form rule could be added by hook but I think a specific hook is cleaner as the hook would also need to alter existing rules