User Interface issueshttps://lab.civicrm.org/dev/user-interface/-/issues2024-03-07T13:40:03Zhttps://lab.civicrm.org/dev/user-interface/-/issues/69Fix Additional Payment div tag issue in Accordion2024-03-07T13:40:03ZshaneonabikeFix Additional Payment div tag issue in AccordionBased on this discussion [here on pull 29448](https://github.com/civicrm/civicrm-core/pull/29448) we need to modify the divs to ensure that the Check is placed inside the Payment Details (rather than outside).
This problem existed in pr...Based on this discussion [here on pull 29448](https://github.com/civicrm/civicrm-core/pull/29448) we need to modify the divs to ensure that the Check is placed inside the Payment Details (rather than outside).
This problem existed in previous versions before. The issue lies in ```templates/CRM/Contribute/Form/AdditionalPayment.tpl``` and can be seen below.
![paymentdetails](/uploads/aea5250221b5177befc50ba34d82df5a/paymentdetails.png)
@nicol comments:
> This closing div closes the crm-accordion-body too soon so the check field is outside the border. This </div> should be removed, and the one below (line 106) brought back.
cc @nicol @noah @herbdoolhttps://lab.civicrm.org/dev/user-interface/-/issues/55Clarify "Pay Later", "Execute real-time transactions"2023-09-26T12:15:02ZbgmClarify "Pay Later", "Execute real-time transactions"From [a thread](https://chat.civicrm.org/civicrm/pl/xz1pm9p31jr93ehespfnq643or) started by @guyiac
- [ ] Manage Contribution Pages: "execute real-time transactions", unchecking this really is only about free memberships, not about in-k...From [a thread](https://chat.civicrm.org/civicrm/pl/xz1pm9p31jr93ehespfnq643or) started by @guyiac
- [ ] Manage Contribution Pages: "execute real-time transactions", unchecking this really is only about free memberships, not about in-kind donations, which is a vague concept that CiviCRM never really explains. There are many scenarios where we want to use a PriceSet but the total amount will be 0$ and we still want a contribution
- [ ] Pay Later: we should clarify that this is also a suitable option when we expect the total amount to be 0$, in which case, the payment will be status=complete
- [ ] Pay Later: the instructions should be optional. Maybe it's clear enough, maybe you don't need them, maybe you want to specify it by some other means
Some of the above also applies to Manage Events, although things like "Execute real-time transactions" is called "Paid Event yes/no".https://lab.civicrm.org/dev/user-interface/-/issues/45Introduce a way to link event participants from the associated booking.2023-06-20T22:57:12ZBradley TaylorIntroduce a way to link event participants from the associated booking.When an event booking is made, the booking is stored across two primary entities:
- One or more participants
- One contribution
When you view an event participant, the list of associated payments is listed at the bottom of that screen:...When an event booking is made, the booking is stored across two primary entities:
- One or more participants
- One contribution
When you view an event participant, the list of associated payments is listed at the bottom of that screen:
![Screenshot_2022-02-04_at_08.46.02](/uploads/e8b76fabe84694810861ace5ecfef8b9/Screenshot_2022-02-04_at_08.46.02.png)
However, the reverse is not true. There is no way to easily get to the participants, when viewing a contriubtion:
![Screenshot_2022-02-04_at_08.46.41](/uploads/a1e19956ed2bda850fea737ca2eca33e/Screenshot_2022-02-04_at_08.46.41.png)
This can make it harder for administrators to see what a contribution has been used to purchase, and harder to see what additional participants the primary booker booked.
I've not looked into the feasability of either approach, but I can see a couple of obvious ways of fitting this into the UI.
**Option 1.** Link each event line item in the line items table to the relevant participant:
![Screenshot_2022-02-04_at_08.48.17](/uploads/cba5c2fb9239c82ecedaefe02adaa31d/Screenshot_2022-02-04_at_08.48.17.png)
(I'm not sure how this option would work with the line item editor extension)
**Option 2.** Introduce a new table of participants:
![Screenshot_2022-02-04_at_08.53.53](/uploads/c3565698dff7fae04900f47226526643/Screenshot_2022-02-04_at_08.53.53.png)
Similar thinking could be employed to link to the associated membership to a membership payment, but I thought I'd get the conversation going in relation to event bookings first.https://lab.civicrm.org/dev/user-interface/-/issues/13Offline receipt sending fields inconsistently handled2023-11-23T07:19:06ZAndie HuntOffline receipt sending fields inconsistently handledThe backend contribution, event registration, and membership forms each offer the ability to email a receipt to the contact. However, this parallel behavior is handled independently for each form and is done inconsistently. This has ca...The backend contribution, event registration, and membership forms each offer the ability to email a receipt to the contact. However, this parallel behavior is handled independently for each form and is done inconsistently. This has caused a handful of issues:
1. The admin can specify receipt text for memberships and event registrations but not for contributions. @alicefrumin wrote a fix for this in [PR 15605](https://github.com/civicrm/civicrm-core/pull/15605), but @bgm thought it required a Gitlab issue to discuss and @eileen was uncomfortable with any improvements to receipts until some code is cleaned up.
2. There is a regression in 5.21 where the backend new contribution form in "standalone" context (coming in cold, rather than from a contact) never allows you to send a receipt from the form. This appears to have been introduced by [PR 15757](https://github.com/civicrm/civicrm-core/pull/15757) which, ironically enough, was an attempt to make the new contribution form work consistently with member, participant, and grant forms.
I think it will be challenging to resolve all of the ways the forms are similar but inconsistent, but the receipts are a clear problem and perhaps somewhere to start.