Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-03-07T07:27:22Zhttps://lab.civicrm.org/dev/core/-/issues/4162Up/down arrow on pager on a contact's Events tab doesn't do the right thing.2023-03-07T07:27:22ZDaveDUp/down arrow on pager on a contact's Events tab doesn't do the right thing.1. Find a contact that has attended 51+ events. Note you can use the api Participant.create to quickly generate some records against the same event+contact since otherwise this is a lot of clicking.
* Note even if you change the defau...1. Find a contact that has attended 51+ events. Note you can use the api Participant.create to quickly generate some records against the same event+contact since otherwise this is a lot of clicking.
* Note even if you change the default pager size at search settings it seems hardcoded to 50.
1. Visit the contact's events tab.
1. Click the up arrow on the pager page control.
1. It takes you to a new register participant form instead of the next page.
The next/last links work ok.
What's interesting is that the url in the network tab seems correct, and if you visit it standalone it does seem to run the event search form correctly. So I suspect something about the context is getting lost in the session. The relevant code might be in CRM_Event_Page_Tab.https://lab.civicrm.org/dev/core/-/issues/4167Transferred to Link in View Event Registration for {participant} Goes to a Pr...2023-03-09T09:20:26ZLKuttnerTransferred to Link in View Event Registration for {participant} Goes to a Previous EventSteps to Reproduce:
- View an event registration that has been transferred to another participant.
- In the Status line, Click the name of the participant that the registration has been transferred to.
- Example: _Status | Transferred (...Steps to Reproduce:
- View an event registration that has been transferred to another participant.
- In the Status line, Click the name of the participant that the registration has been transferred to.
- Example: _Status | Transferred (Transferred to Megan Nedzinski)_
- The link takes you to the registration for the first event that the person was ever registered for.
- The link does not take you to the latest registration that was just transferred to that contact.
- This only happens in the View Event Registration for {participant} page.
- In the Edit Event Registration for {participant} page, clicking the equivalent link does take you to the correct event.
This is using CiviCRM 5.55.1 on Drupal 7. I just noticed this and don't know how long this behavior has been in effect.https://lab.civicrm.org/dev/core/-/issues/4179Event online registration validation error under narrow conditions related to...2023-05-01T22:13:11ZAllenShawEvent online registration validation error under narrow conditions related to multiple participant, $0 fee, and contact reference field permissions: "Your payment information looks incomplete. Please go back to the main registration page, to complete ..."Under a very specific set of circumstances, users are unable to complete online event registration because of the validation error:
```
Please correct the following errors in the form fields below:
Your payment information looks incompl...Under a very specific set of circumstances, users are unable to complete online event registration because of the validation error:
```
Please correct the following errors in the form fields below:
Your payment information looks incomplete. Please go back to the main registration page, to complete payment information.
```
**Setup:**
To reproduce this you will need:
1. An event with the following characteristics:
* Configured for online registration, with multiple participants, and with pricing that allows for a $0 amount on the first participant.
* Includes a profile which contains a required contact reference field.
2. A user role with permissions to register for this event, but **without** the "access contact reference fields" permission.
**Repro steps:**
Once you have that set up you can reproduce as follows:
1. As a user with the given role, open the online registration form for this event.
2. Indicate that you are registering for two participants.
3. On the registration form for either of these two participants, you will notice that the contact reference field is not displayed, as expected in light of the user's permissions.
4. For the first participant, ensure that you select price options totaling $0.
5. Proceed to register the second participant, and for this participant ensure that you select a fee amount of greater than $0.
6. Submit the registration form for the second participant.
**Expected** behavior: The event registration is submitted without error (confirmation page or thank-you page is displayed, as appropriate per event configuration)
**Actual incorrect** behavior: Submission of the final participant form results in the above-stated validation error.
**Strict requirements for repro:**
It's worth noting that you can avoid this error by making any one or more of the following changes to the above steps or set up:
- as admin:
- Change permission so that this user can access contact reference fields.
- Do not make the contact reference field required in the profile.
- as user:
- For the first participant, select fees totaling greater than $0.
- For the second participant, select fees totalling $0.
**How the code allows this wackiness to happen:**
- [This line in CRM_Core_Form::validateMandatoryFields](https://github.com/civicrm/civicrm-core/blob/503cdb20e74866ffc68311c7c2be3cf9577a23bf/CRM/Core/Form.php#L2332) adds a validation error to the form if the required contact reference field has no value, without regard for whether the user had permissioned access to the field.
- [This line in CRM_Event_Form_Registration_AdditionalParticipant::validatePaymentValues](https://github.com/civicrm/civicrm-core/blob/master/CRM/Event/Form/Registration/AdditionalParticipant.php#L522) avoids calling `CRM_Core_Form::validateMandatoryFields()` if the first participant had a fee of more than $0.
(Joinery internal ticket reference: F#1041)https://lab.civicrm.org/dev/core/-/issues/4223To edit price sets CiviContribute access needed2023-04-12T07:25:37ZMariaVTo edit price sets CiviContribute access neededOverview
----------------------------------------
A user has limited permissions without access to CiviContribute but has access to CiviEvent and needs to set up price sets. It is possible to view price sets but they can not be edited or...Overview
----------------------------------------
A user has limited permissions without access to CiviContribute but has access to CiviEvent and needs to set up price sets. It is possible to view price sets but they can not be edited or created because of the financial type.
Reproduction steps
----------------------------------------
1. Create price set for Events (with a user without CiviContribute access)
2. Create price field (radio buttons)
3. Add options to this price field
4. Fill all needed information
5. Save
6. Error "financial type is mandatory"
Current behaviour
----------------------------------------
When I open a price set option it shows me this:
![image](/uploads/f5b1e1b6648bb6beb30cf36b3ab2fe7a/image.png)
(Zuwendungsart = financial type)
With administrator this:
![image](/uploads/b6fc64b239dad54bbf4ba68c72434241/image.png)
If I give "CiviContribute access" it works.
Expected behaviour
----------------------------------------
When CiviEvent access is given, users are allowed to create price sets.
Environment information
----------------------------------------
* __CiviCRM:__ _5.58.1
* __CMS:__ _Drupal 7https://lab.civicrm.org/dev/core/-/issues/4285Changing participant status should not add an Event Registration activity2023-05-24T06:53:21ZlarsssandergreenChanging participant status should not add an Event Registration activityIf you change a participant status, for example from Registered to Attended, an activity of type Event Registration is added with subject Event Name - Role - Status. It isn't an event registration, so the activity type should probably be...If you change a participant status, for example from Registered to Attended, an activity of type Event Registration is added with subject Event Name - Role - Status. It isn't an event registration, so the activity type should probably be Change Registration, but I'm not sure we want an activity recorded at all. Is this useful or does it just make the Activities tab less useful by filling it up with unimportant details?
For comparison, we don't record an activity for a change in contribution status, but we do record an activity for a change in membership status. This seems reasonable and the change in participant status seems more like a change in contribution status.
If someone cancels through the self service / Transfer or Cancel mechanism, a separate cancellation activity is recorded (so you end up with two activities for the cancellation).
My proposal is to not record an activity on participant status change, except through the self service mechanism.
If people feel like some of those activities are useful, maybe we could only record activities for changes to or to and from cancelled and transferred status. These should be Change Registration type activities and the separate activity from the self service mechanism would have to be removed so there is no duplication.https://lab.civicrm.org/dev/core/-/issues/4288Price set option limit = 0 should mean no spaces, rather than no limit2023-05-15T08:16:42ZlarsssandergreenPrice set option limit = 0 should mean no spaces, rather than no limitIf you set a price set option limit to 0, this is the same as not specifying a limit. I would expect that a limit of 0 would mean there are no spaces. Setting the limit to 0 is different than disabling the price set option, as disabling ...If you set a price set option limit to 0, this is the same as not specifying a limit. I would expect that a limit of 0 would mean there are no spaces. Setting the limit to 0 is different than disabling the price set option, as disabling makes it so the option does not appear on public forms, while I expect setting the limit to 0 would just make it sold out, but still appear. I can't think of a good reason you would want 0 to be the same as no limit, but maybe others can?
Will submit PR unless there are objections. Otherwise, will add help text.https://lab.civicrm.org/dev/core/-/issues/4334Remove Event Info link from Manage Event (and same from Manage Contribution P...2023-06-21T14:55:10ZlarsssandergreenRemove Event Info link from Manage Event (and same from Manage Contribution Page)![image](/uploads/dd822bae24450b2001a604f392198a89/image.png)
I'm not sure this is needed, since it just replicates the link available in the Event Links above, except less completely, as it doesn't include Online Registration, so users...![image](/uploads/dd822bae24450b2001a604f392198a89/image.png)
I'm not sure this is needed, since it just replicates the link available in the Event Links above, except less completely, as it doesn't include Online Registration, so users tend to think this is the only option (some organizations do not use Event Info, preferring to link straight to Registration).
There is a similar thing at the bottom of the first Manage Contribution Page tab that could also be removed, in my opinion. These look kind of weird and aren't really necessary, so I think they can go without losing anything, but am looking for further opinions on this.https://lab.civicrm.org/dev/core/-/issues/4336Payment on Event Confirmation Page: Does not work when pay later is disabled2023-06-09T18:39:49ZlarsssandergreenPayment on Event Confirmation Page: Does not work when pay later is disabledGreat to have this functionality!
_This has been updated after the fixes in PR 26491._
_There are two cases: 1) with pay later or 2) without pay later._
**If pay later is enabled**, it seems to work as intended, but the pay later inst...Great to have this functionality!
_This has been updated after the fixes in PR 26491._
_There are two cases: 1) with pay later or 2) without pay later._
**If pay later is enabled**, it seems to work as intended, but the pay later instructions are displayed on the payment/confirmation page (they should never be as the user hasn't selected a payment method yet) and on the Thank You page even if they selected another payment method (see screenshots below).
Updated: After submitting, the contribution is created, but it is set to pending (pay later) and no payment is present.
With pay later enabled, it looks like $is_pay_later is always true.
On payment/confirmation:
![image](/uploads/1c406bf9b01bcaa4a430f3d720b5bf7f/image.png)
On Thank You after selecting a payment method that isn't pay later:
![image](/uploads/e2630c45369dbf975ad340c83339b7ec/image.png)
**Without pay later:**
On the payment/confirmation page, something isn't loading right because these billings fields should be filled in and there shouldn't be a card type select:
<img src="/uploads/546c468287908dc976a3e47a73192aed/image.png" width=400>
On submit, we get an error:
` [error] Payment processor exception: Error Unexpected Server Error, please see your logs `
```
[info] $iATS SOAP Response = stdClass Object
(
[ProcessCreditCardResult] => stdClass Object
(
[any] => FailureObject reference not set to an instance of an object.
)
)
```
Fixed:
~~On the first page, with pay later disabled, we get divs that shouldn't be there:~~
<img src="/uploads/cb6e5ac305cc947cb404206fecc5899d/image.png" width=400>https://lab.civicrm.org/dev/core/-/issues/4368Changing repeating events crashes when there are events to be deleted/removed...2023-06-20T13:29:25ZRichChanging repeating events crashes when there are events to be deleted/removed from seriesI _think_ I've pinned this one down.
When you change the end-date for repeating events, it makes a list of the original repeats and will either delete them (if no participants) or remove them from the series.
The code here just plain l...I _think_ I've pinned this one down.
When you change the end-date for repeating events, it makes a list of the original repeats and will either delete them (if no participants) or remove them from the series.
The code here just plain looks wrong to me:
https://lab.civicrm.org/dev/core/-/blob/1edfed415fe687e7c7847df41497352b5fa96368/CRM/Core/Form/RecurringEntity.php#L408
It's doing a call like `call_user_func([$classname, $argument1])` which should surely be `call_user_func([$classname, $methodname], $argument1)`
In the execution, the helper class (`$classname` above) is `CRM_Event_DAO_Event", I have no idea what method should be called, and the `$argument1` is an array of IDs.
Commenting out that line seems to be ok, but I've no idea what it was supposed to do. This problem has been here for at least 8 years(!).https://lab.civicrm.org/dev/core/-/issues/4379Preview support for event online template2023-06-20T13:20:13ZeileenPreview support for event online templateWe have preview support for the event offline template - but it doesn't cover additional participants - focussing for now on the line items I'm documenting what to expect
1) We will assign the same variables as other financial templates...We have preview support for the event offline template - but it doesn't cover additional participants - focussing for now on the line items I'm documenting what to expect
1) We will assign the same variables as other financial templates (taxRateBreakdown, lineItems)
2) I think we should also assign a participant specific version of the above & then toggle whether to show all or not based on whether the participant is primary.
I'm gonna add screen shots to what happens now during an online flow because I know there are existing inconsistencies and that is considered correct
Also refer https://github.com/civicrm/civicrm-core/pull/23098 for thoughts about 'right behaviour' and
https://lab.civicrm.org/dev/core/-/issues/224https://lab.civicrm.org/dev/drupal/-/issues/188drupal 9: Event registration with drupal user creation crashes if using first...2023-06-28T07:09:49ZDaveDdrupal 9: Event registration with drupal user creation crashes if using first+last+email dedupe ruleThis is pulled out from https://lab.civicrm.org/dev/drupal/-/issues/186 since it's not recent and while touching a similar code area it's not exactly the same.
Part of the problem here is it only sends on the email to createUser, but as...This is pulled out from https://lab.civicrm.org/dev/drupal/-/issues/186 since it's not recent and while touching a similar code area it's not exactly the same.
Part of the problem here is it only sends on the email to createUser, but as in the other ticket it already has the contact id so it shouldn't need to do dedupe rules, it's just how to get that contact id to get passed on to synchronizeUFMatch: https://github.com/civicrm/civicrm-core/blob/c0a3d0e01a7d8df34786a1510d8a4661dffee82b/CRM/Event/Form/Registration.php#L807. Using $_POST is not great, but it needs to be something that gets passed on from the _drupal_ insert hook. And it would be nice to re-use whatever mechanism for the contact user add task too.https://lab.civicrm.org/dev/core/-/issues/4460Feature request: Force recurring-only2023-08-11T06:35:18ZMariaVFeature request: Force recurring-onlyI would like to propose a feature for contribution pages.
There is already an [extension (ca.civicrm.contributionrecur)](https://github.com/adixon/ca.civicrm.contributionrecur/) with this feature (and a lot more) but unfortunately it do...I would like to propose a feature for contribution pages.
There is already an [extension (ca.civicrm.contributionrecur)](https://github.com/adixon/ca.civicrm.contributionrecur/) with this feature (and a lot more) but unfortunately it does not work properly anymore.
It is possible to force recurring payments only - which is very useful for i.e. membership pages.
When this option is selected, it is not possible to uncheck the checkbox:
![image](/uploads/d3898e4c576b669018029e7b4da3cb08/image.png)https://lab.civicrm.org/dev/core/-/issues/4477Pay later instructions for offline event registration2023-08-07T01:50:54ZlarsssandergreenPay later instructions for offline event registrationIf you register a contact for an event on the back end, you can select Pending (Pay later) as the participant status and Pending as the contribution status. However, despite what you might expect the pay later instructions for the event ...If you register a contact for an event on the back end, you can select Pending (Pay later) as the participant status and Pending as the contribution status. However, despite what you might expect the pay later instructions for the event will not be sent in the offline event registration email, as `$is_pay_later` does not exist for offline registrations.
Presumably because it is copy-pasted from the online template, the offline event registration template does contain two conditionals for `$is_pay_later` (and so we get PHP warnings).
Option one, we remove `$is_pay_later` from the offline registration template. Simplification! No more warnings.
Option two, if participant status is Pending (pay later) and contribution status is Pending and the pay later instructions text exists for the event, we add the pay later instructions to the email. This is nice because it does what the user probably expects and it gives the registrant useful information to complete the payment. The downside is we are further perpetuating the arguably bad pay later concept, though we don't directly use is_pay_later. There is also added complexity for something that is probably not that common.https://lab.civicrm.org/dev/core/-/issues/4485Replace Event Total by Total Amount on confirm/thankyou pages2023-08-11T23:03:31ZyashodhaReplace Event Total by Total Amount on confirm/thankyou pagesReplace _Event Total_ by _Total Amount_ on confirm/thankyou pagesReplace _Event Total_ by _Total Amount_ on confirm/thankyou pages5.66.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4496Event template fix-ups2023-08-17T14:18:50ZeileenEvent template fix-upsGenerally the goal is to make event templates not dependent on the form layer (using tokens & the MessageTemplate harness)
I'm creating this tracking issue to load up some screen shots for comparisonsGenerally the goal is to make event templates not dependent on the form layer (using tokens & the MessageTemplate harness)
I'm creating this tracking issue to load up some screen shots for comparisonshttps://lab.civicrm.org/dev/core/-/issues/4512Profile notify on submit for event registration additional participants only ...2023-08-18T21:15:34ZlarsssandergreenProfile notify on submit for event registration additional participants only works if profile is used for primary participantThis one is a little obscure, but thought I might as well note it.
If you set up an event registration using a profile that sends a notification email on submit and you use that profile for the primary participant and the additional par...This one is a little obscure, but thought I might as well note it.
If you set up an event registration using a profile that sends a notification email on submit and you use that profile for the primary participant and the additional participants, everything works as intended. But if the additional participant profile that has the notification is only used for the additional participant and not the primary participant, then no notification will be sent.
This is because we only build the profile fields and send the notification if [notify is TRUE for customPre or customPost here.](https://github.com/civicrm/civicrm-core/blob/e6b439e4eb032b269fc823a7782cc2d8bb9d8304/CRM/Event/BAO/Event.php#L1077). The notification being sent for the additional participant in the case where the notification profile is used for the primary participant is sort of an unintended side effect and it would be better to handle each profile on the registration form separately.https://lab.civicrm.org/dev/core/-/issues/4517Show a message to let event registrants know that additional participants wil...2023-08-24T14:00:38ZlarsssandergreenShow a message to let event registrants know that additional participants will receive an email confirming their registrationWhen you register additional participants for an event and enter an email for those additional participants, an email confirmation is sent to the additional participants' emails. We should include text on the additional participants scre...When you register additional participants for an event and enter an email for those additional participants, an email confirmation is sent to the additional participants' emails. We should include text on the additional participants screen indicating that this confirmation email will be sent when there is an email field on the page, something like:
"An email confirming registration will be sent to the email address provided below."https://lab.civicrm.org/dev/core/-/issues/4518Indicate in additional participant confirmation email when their status is pe...2023-08-24T14:01:24ZlarsssandergreenIndicate in additional participant confirmation email when their status is pending (pay later)When an additional participant receives a confirmation email and their status is pending (pay later), there is nothing to indicate their status in the email, so it looks like they are fully registered. We should include something like:
...When an additional participant receives a confirmation email and their status is pending (pay later), there is nothing to indicate their status in the email, so it looks like they are fully registered. We should include something like:
"Your registration is pending payment."https://lab.civicrm.org/dev/core/-/issues/4520Simplify and improve offline event receipt template contribution section details2023-09-23T22:55:28ZlarsssandergreenSimplify and improve offline event receipt template contribution section detailsAn offline event receipt includes the following (in this case, for a pending (pay later) registration):
![image](/uploads/67eefa5dc465c6ee31b71d7523f2c20c/image.png)
Here's a non-pending one:
![image](/uploads/954f9780ed01de7e46519f6b...An offline event receipt includes the following (in this case, for a pending (pay later) registration):
![image](/uploads/67eefa5dc465c6ee31b71d7523f2c20c/image.png)
Here's a non-pending one:
![image](/uploads/954f9780ed01de7e46519f6b36f2dc2b/image.png)
1. I don't think we need to include Registration Date. I don't know when this would be useful information for the recipient. It is almost always going to be the date of the email and even if it isn't (which I think is only possible if you manually change the date while inputting the registration), what purpose does it serve for the recipient? Note that we have Transaction Date just below this and they are going to be the same almost all the time. If it is important to someone that we include both we could do so if they are different, but I don't really see why we need to include Registration Date in an email receipt.
1. Paid By: This should not be included if no payment was recorded, as it is misleading in that case.
1. Total Amount: This should be included and we should show a balance if no payment has been made and the status is pending (pay later) - but not if the status is otherwise, because then we can assume that we aren't charging the person. In this case, we shouldn't include a total at all.
1. Pay later text. This should be included if we register the person as pending (pay later) and this text exists. It looks like there is some attempt to include this in the template, but it doesn't seem to work - I think is_pay_later may not be set for offline registrations.
2. Financial Type: Do we need to include this? In general, I think it doesn't add anything, but I suppose it could be useful to differentiate donations from non-donations. Seems like that could also be misleading though, as only part of the contribution may be tax deductible. I'd lean on the side of removing this.https://lab.civicrm.org/dev/core/-/issues/4526Unselecting price set discount set for back office event registration disappe...2023-08-23T02:51:57ZlarsssandergreenUnselecting price set discount set for back office event registration disappears fee block1. Add a discount set to a quick config price set for an event
2. Add new event registration from back office
3. Unselect the default discount set (which you would do if you wanted to charge the person full price)
The fee block disappea...1. Add a discount set to a quick config price set for an event
2. Add new event registration from back office
3. Unselect the default discount set (which you would do if you wanted to charge the person full price)
The fee block disappears, you cannot select any price options. The discount set is automatically re-selected, but the price options do not re-appear.