Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-04-22T16:22:22Zhttps://lab.civicrm.org/dev/core/-/issues/3382Data from custom fields is not stored in event but in event template2022-04-22T16:22:22ZoseidelData from custom fields is not stored in event but in event templateWhen creating a new event using an event template which includes custom fields, the data entered in the custom fields won't be stored in the event itself when clicking the 'Continue'-button, but are stored in the event template. After cl...When creating a new event using an event template which includes custom fields, the data entered in the custom fields won't be stored in the event itself when clicking the 'Continue'-button, but are stored in the event template. After clicking 'Continue' and then going back to the 'Info and Settings'-tab all data entered in the custom fields is gone. However, the data can be found in the used event template now. By going into edit mode the data is set in the template's custom fields and will be prefilled in the next event generated using this template.
This issue might be conneted to this one: [Core Issue 766](https://lab.civicrm.org/dev/core/-/issues/766)
See also a related post on [stackexchange](https://civicrm.stackexchange.com/questions/20709/new-event-from-template-does-not-copy-custom-fields)
Notice that custom field are 'only' lost in this cases, while it gets stored in the template in this one.
Steps to reproduce:
1. Set up fresh Joomla instance (V. 3.9.26 at the time of writing)
2. Install latest CiviCRM for Joomla (V. 5.37.2 at the time of writing)
3. Create a new set of custom fields (I've been using text, date and select inputs in my tests)
4. Create a new event template and fill out all necessary inputs (I've also entered something in the title, summary and description).
5. Create a new event using the newly created template. Enter something in all necessary fields as well as in the custom fields.
6. Click 'Continue'
7. Return to 'Info and Settings' - the data entered in the custom fields is gone :/
8. Open the template in edit mode. The custom data we previously entered in the event is here now
This issue can be reproduced in CiviCRM 5.37.0 and 5.37.2, but not in 5.36.1 used in the [Joomla Demo](https://cividemo.com/).
I've been using the following environments to test: AMPPS 3.9 and XAMPP (compile date 4-6-21) with PHP 7.3.
As I'm only using CiviCRM inside Joomla I haven't testet whether this issue also appears in other CMS- or the standalone-version.
A possible workaround for the problem is to skip entering something in the custom fields in Step 5 but doing so in Step 7. The contents of custom fields are saved correctly now. However, another strange behaviour occurs now: If there is any content of the custom fields already set in the template (e.g. if a field is set as required), this data is missing in the event using the template. Even in fields marked as required - the content set in the template is just gone.5.39.0https://lab.civicrm.org/dev/core/-/issues/3381Event Registration Confirm/Thank You pages show incorrect currency2024-02-08T23:37:57ZbwheelerEvent Registration Confirm/Thank You pages show incorrect currencyThe event registration confirmation/thank you pages display the incorrect currency. Steps to reproduce:
* Create a new event with a non-default currency (in my case EUR)
* Add a price set to fees and allow registration
The main event p...The event registration confirmation/thank you pages display the incorrect currency. Steps to reproduce:
* Create a new event with a non-default currency (in my case EUR)
* Add a price set to fees and allow registration
The main event page, confirmation and thank you pages will all show the incorrect currency.
We fixed this for a client by doing the following:
````
diff --git a/sites/all/modules/contrib/civicrm/CRM/Event/Form/Registration.php b/sites/all/modules/contrib/civicrm/CRM/Event/Form/Registration.php
index 74526af6a..947cc051e 100644
--- a/sites/all/modules/contrib/civicrm/CRM/Event/Form/Registration.php
+++ b/sites/all/modules/contrib/civicrm/CRM/Event/Form/Registration.php
@@ -452,6 +452,8 @@ class CRM_Event_Form_Registration extends CRM_Core_Form {
}
}
+ $this->assign('currency', $params['currencyID']);
+
$this->assign('address', CRM_Utils_Address::getFormattedBillingAddressFieldsFromParameters($params, $this->_bltID));
// The concept of contributeMode is deprecated.
````
The problem is that `templates/CRM/Price/Form/LineItem.tpl` uses the `$currency` variable, but `Event/Form/Registration.php` sets `$currencyID` and not `$currency`
However, it still doesn't work for on-the-fly (non-price-set) prices.
This bug may be related to the following:
* https://lab.civicrm.org/dev/core/-/issues/2930
* https://lab.civicrm.org/dev/core/-/issues/4115.71.0https://lab.civicrm.org/dev/core/-/issues/3379Can't meaningfully disable self-service transfer/cancellation once enabled2022-04-22T16:22:15ZJonGoldCan't meaningfully disable self-service transfer/cancellation once enabledTo replicate:
* Create an event. Enable self-service transfer/cancellation.
* Register a participant, receive the email to the self-service update page.
* Disable self-service transfer/cancellation.
* Click the self-service link. Note t...To replicate:
* Create an event. Enable self-service transfer/cancellation.
* Register a participant, receive the email to the self-service update page.
* Disable self-service transfer/cancellation.
* Click the self-service link. Note that you can still load the self-service page even though self-service has been disabled.
This is an easy fix, but given the many self-service issues, I think a refactor is in order first, so I'll submit that before proceeding.5.29.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3377Why are unique labels for price fields required?2022-04-22T16:22:10ZStoobWhy are unique labels for price fields required?This is a question not a proposal or bug report. Should a unique label for price fields be enforced (seen attached)?
Here are two use cases:
* event registration where the price of attendance changes over time (early bird) but the e...This is a question not a proposal or bug report. Should a unique label for price fields be enforced (seen attached)?
Here are two use cases:
* event registration where the price of attendance changes over time (early bird) but the event itself or the nature of the registration doesn't change
* membership registration 'special' where prior to a certain date memberships are on sale
It seems in these cases a unique label is not necessary.
![why](/uploads/5b0f604ac6fba41973e16fcfd865932b/why.png)5.47.0AllenShawAllenShawhttps://lab.civicrm.org/dev/core/-/issues/3370Event confirmation emails should go to the email submitted, not primary email2022-04-22T16:21:59ZJonGoldEvent confirmation emails should go to the email submitted, not primary email### Scenario
A site visitor submits an event registration with email "myemail@example.com". This user is matched to an existing record, whether through unsupervised dedupe or they're logged in. Their primary email "oldemail@example.com...### Scenario
A site visitor submits an event registration with email "myemail@example.com". This user is matched to an existing record, whether through unsupervised dedupe or they're logged in. Their primary email "oldemail@example.com" receives the confirmation message.
This scenario is fairly rare because it's likely that the profile records the new email is the same location type as the old email, replacing it. However, I would argue that the expected behavior of any site visitor registering for an event is that the confirmation reaches them at the email provided. This is especially true if the old email is no longer in use.5.43.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3368"Confirm from waitlist" doesn't consider whether participant roles are counted.2022-04-22T16:21:55ZJonGold"Confirm from waitlist" doesn't consider whether participant roles are counted.To test this:
* Set your Participant Role of "Host" as not Counted. Keep "Attendee" as Counted.
* Create an event with a max enrollment of 1.
* Register a host.
* Observe that everywhere you can look in the UI, the non-counted participan...To test this:
* Set your Participant Role of "Host" as not Counted. Keep "Attendee" as Counted.
* Create an event with a max enrollment of 1.
* Register a host.
* Observe that everywhere you can look in the UI, the non-counted participant isn't counted; registration is still open.
* Register an attendee.
* Add an attendee to the waitlist.
* Cancel (or delete) the registered attendee's participant record.
* At this point, everything STILL works correctly.
The issue only arises when the person gets the "Confirm you want to come off the waitlist" email and clicks the link, bringing them to `<site>/civicrm/event/confirm`. This page says that registration is closed - because it's counting the Host against the max enrollment count.
After working through this, I realized this is very similar to event#7 - the function `CRM_Event_BAO_Participant::pendingToConfirmSpaces()` is a dog. It duplicates code found elsewhere, but poorly.
I replaced the one reference to this function with a call to `CRM_Event_BAO_Participant::eventFull()`, which I tweaked slightly to accommodate this use case. This means that:
* We removed a 50-line function by adding 5 lines to another function;
* We replaced an untested function with a tested one.5.23.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3366Price option reaches max amount causes critical error.2022-04-22T16:21:52ZBruce ThompsonPrice option reaches max amount causes critical error.If a price field is setup with price options that have a max amount when that max amount of registrations is met the site throw a critical error in WordPress. First noticed this in CiviCRM v 5.35.1. I updated a site to 5.36 with the same...If a price field is setup with price options that have a max amount when that max amount of registrations is met the site throw a critical error in WordPress. First noticed this in CiviCRM v 5.35.1. I updated a site to 5.36 with the same result and then tested on https://wpmaster.demo.civicrm.org/ which is currently running 5.38.alpha1 and I received similar results xcept I didn't get the WP critical error message just a http 500 notice. Here is the error message sent via WordPress after the critical error page. There is nothing in the CiviCRM logs.
> An error of type E_ERROR was caused in line 209 of the file /home/account_name/public_html/wp-content/plugins/civicrm/civicrm/CRM/Price/BAO/PriceField.php. Error message: Uncaught Error: Call to a member function freeze() on string in /home/account_name/public_html/wp-content/plugins/civicrm/civicrm/CRM/Price/BAO/PriceField.php:209
Stack trace:
#0 /home/account_name/public_html/wp-content/plugins/civicrm/civicrm/CRM/Price/BAO/PriceField.php(439): CRM_Price_BAO_PriceField::freezeIfEnabled('
Happy to provide additional information.5.36.1https://lab.civicrm.org/dev/core/-/issues/3365"Self-service eligibility" has incorrect behavior when "hours to cancel" is zero2022-04-22T16:21:50ZJonGold"Self-service eligibility" has incorrect behavior when "hours to cancel" is zero#### Steps to replicate:
* Create an event with self-service cancel/transfer enabled, with the default "up to 0 hours before the event".
* Register a contact, get the cancellation link in your email.
* Set the event's begin/end date in t...#### Steps to replicate:
* Create an event with self-service cancel/transfer enabled, with the default "up to 0 hours before the event".
* Register a contact, get the cancellation link in your email.
* Set the event's begin/end date in the past.
* Attempt to cancel.
##### Expected result
The event shouldn't allow you to cancel because it's in the past.
##### Actual result
Cancellation is permitted.
This is just an `isset()` vs. `!empty()` issue. I made some grammatical fixes while I was in there though.5.33.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3360deprecated function error2022-04-22T16:21:37ZJoeMurraydeprecated function errorOn dmaster go to Manage Events, then click on the leftmost icon on top right (blue in the included image).
![Screenshot_20210219-171528_Chrome](/uploads/f6ff11c7f923ca071f8fce241bec2bf2/Screenshot_20210219-171528_Chrome.png)
Error tha...On dmaster go to Manage Events, then click on the leftmost icon on top right (blue in the included image).
![Screenshot_20210219-171528_Chrome](/uploads/f6ff11c7f923ca071f8fce241bec2bf2/Screenshot_20210219-171528_Chrome.png)
Error that shows is:
Deprecated function: Non-static method CRM_Event_ICalendar::run() should not be called statically in CRM_Core_Invoke::runItem() (line 278 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php).5.36.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3359Partial payments fail on events in a modal dialog box2022-04-22T16:21:35ZJonGoldPartial payments fail on events in a modal dialog box### Steps to replicate on a demo site
* Go to a contact's Events tab.
* Click **Add Event Registration**.
* Register someone for a paid event (e.g. "Rainforest Cup Youth Soccer Tournament"), but record only a partial payment (e.g. $300 i...### Steps to replicate on a demo site
* Go to a contact's Events tab.
* Click **Add Event Registration**.
* Register someone for a paid event (e.g. "Rainforest Cup Youth Soccer Tournament"), but record only a partial payment (e.g. $300 instead of $800).
* Submit the form.
### Expected Results
* Event status is completed and "Partially Paid".
### Actual results
* The following error appears (with its missing word): "Payment amount is less than the amount owed. Expected participant status is 'Partially paid'. Are you sure you want to set the participant status to ? Click OK to continue, Cancel to change your entries"
### Notes
The correct behavior IS displayed when the "register event" form isn't in a modal dialog above the contact's Events tab. E.g. registering someone from **Events menu ยป Register Event Participant** - or even right-clicking the **Add Event Registration** to open it in a new tab doesn't trigger the error.
It looks like the issue is a collision of two DOM elements both named `#status_id`. There's some JavaScript intended to set the status to "Partially Paid" that fails because it's trying to change the wrong element.5.36.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3354Participant name overwritten with Billing Name2022-04-22T16:21:27ZADG CreativeParticipant name overwritten with Billing NameNoticed after update to Civi 5.20.2
On front-end Event Registration form, when the billing First/Last name is different than the event participant name, upon submitting the form, the Participant First/Last name is overwritten with the Bi...Noticed after update to Civi 5.20.2
On front-end Event Registration form, when the billing First/Last name is different than the event participant name, upon submitting the form, the Participant First/Last name is overwritten with the Billing First Last Name.
This causes the event registration to be attached to the Billing contact instead of the Participant contact.
![EventReg](/uploads/b052394df67c272cf04ae072d4d4d438/EventReg.jpg)
![EventConfirm](/uploads/081f712c33fba71e88b11a1153205d4b/EventConfirm.jpg)
![FindParticipants](/uploads/b3d3ae3ad5db1f2dc006ea0963e98f18/FindParticipants.jpg)5.21.0https://lab.civicrm.org/dev/core/-/issues/3351Remove scriptFee & scriptArray params2022-04-22T16:21:18Zmattwiremjw@mjwconsult.co.ukRemove scriptFee & scriptArray paramsThese parameters are not used and should be removed from CiviCRM codeThese parameters are not used and should be removed from CiviCRM code5.20.0https://lab.civicrm.org/dev/core/-/issues/3350Event registration form has inconsistent labelling2022-04-22T16:21:16ZJonGoldEvent registration form has inconsistent labellingFollowing on from core#1613 - [PR 16651](https://github.com/civicrm/civicrm-core/pull/16651) updated the button text but nor corresponding instructions.
Hat tip to Bryan for discovering this and [posting on Stack Exchange](https://civic...Following on from core#1613 - [PR 16651](https://github.com/civicrm/civicrm-core/pull/16651) updated the button text but nor corresponding instructions.
Hat tip to Bryan for discovering this and [posting on Stack Exchange](https://civicrm.stackexchange.com/questions/35964/misleading-instructions-in-civievent-registration-template-for-multiple-particip).
https://github.com/civicrm/civicrm-core/pull/176955.29.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3349Creating an event clears the cache2022-04-22T16:21:15ZjaapjansmaCreating an event clears the cacheWhen creating a new event or updating an existing the system will clear all caches in the background.
The line causing this is in the CRM_Event_BAO_Event::add
```php
public static function add(&$params) {
CRM_Utils_System::flush...When creating a new event or updating an existing the system will clear all caches in the background.
The line causing this is in the CRM_Event_BAO_Event::add
```php
public static function add(&$params) {
CRM_Utils_System::flushCache();
```
see: https://github.com/civicrm/civicrm-core/blame/master/CRM/Event/BAO/Event.php#L86
My question is why the caches need to be cleared when adding or updating an event? And if there is no reason is it safe to remove this line?
5.18.0https://lab.civicrm.org/dev/core/-/issues/3344Recurring membership term is incorrect when using price sets2024-02-06T05:47:22ZJonGoldRecurring membership term is incorrect when using price setsWhen using membership price sets, the recurring contribution created doesn't match the term of the membership selected, it matches the term of the first membership in the price set. The issue is mentioned in passing on the [gocardless](...When using membership price sets, the recurring contribution created doesn't match the term of the membership selected, it matches the term of the first membership in the price set. The issue is mentioned in passing on the [gocardless](https://lab.civicrm.org/extensions/gocardless/-/issues/112) issue queue but doesn't have its own issue.
### Steps to replicate
* Create two memberships, one with a term of 1 year, one with a term of 1 month. Make auto-renew required.
* Create a membership price set with radio buttons, allowing the user to choose between the two memberships.
* Create a contribution page for the price set.
* Register for the second membership (term of 1 month).
* View the recurring contribution record.
### Expected result
Recurring contribution record is 1 month.
### Actual result
Recurring contribution record is 1 year.
I am away from home this week and don't have a working XDebug config, but I'll take a shot at this next week.5.69.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3339Wrong frequency when purchasing a membership2024-01-05T03:42:45ZsudomanWrong frequency when purchasing a membershipWe patched a bug in CiviCRM core that has been around for a while now. When buying an annual membership, sometimes donors are charged the annual price, but on a monthly basis. (We offer both annual and monthly memberships on the same mem...We patched a bug in CiviCRM core that has been around for a while now. When buying an annual membership, sometimes donors are charged the annual price, but on a monthly basis. (We offer both annual and monthly memberships on the same membership page). This patch is a hack that works for us, but may have some hard coded values for our instance.
One way to check if your server has this problem is to use a payment processor like PayPal, which lets you see the recurring contrib details before you actually pay. This issue comes up somewhat randomly, so you might have to try a few times.
Thanks! : )
```
diff --git a/CRM/Contribute/Form/ContributionBase.php b/CRM/Contribute/Form/ContributionBase.php
index 41fcb7da3e..075d29ab20 100644
--- a/CRM/Contribute/Form/ContributionBase.php
+++ b/CRM/Contribute/Form/ContributionBase.php
@@ -1371,7 +1371,14 @@ class CRM_Contribute_Form_ContributionBase extends CRM_Core_Form {
$this->_params['is_recur'] = $this->_values['is_recur'] = 1;
// check if price set is not quick config
if (!empty($this->_params['priceSetId']) && !CRM_Core_DAO::getFieldValue('CRM_Price_DAO_PriceSet', $this->_params['priceSetId'], 'is_quick_config')) {
- list($this->_params['frequency_interval'], $this->_params['frequency_unit']) = CRM_Price_BAO_PriceSet::getRecurDetails($this->_params['priceSetId']);
+
+ // Extract the ids for all of the line items that have been chosen.
+ $priceFieldValueIds = array_keys($this->_lineItem[$this->_params['priceSetId']])[0];
+ if (empty($priceFieldValueIds))
+ $priceFieldValueIds = array_keys($this->_params['price_126'])[0];
+ list($this->_params['frequency_interval'], $this->_params['frequency_unit']) = CRM_Price_BAO_PriceSet::getRecurDetails($this->_params['priceSetId'], $priceFieldValueIds);
}
else {
// FIXME: set interval and unit based on selected membership type
diff --git a/CRM/Price/BAO/PriceSet.php b/CRM/Price/BAO/PriceSet.php
index 91118ecd97..0277bdbaed 100644
--- a/CRM/Price/BAO/PriceSet.php
+++ b/CRM/Price/BAO/PriceSet.php
@@ -1332,13 +1332,14 @@ GROUP BY mt.member_of_contact_id ";
* @return array
* associate array of frequency interval and unit
*/
- public static function getRecurDetails($priceSetId) {
+ public static function getRecurDetails($priceSetId, $priceFieldValueIds) {
$query = 'SELECT mt.duration_interval, mt.duration_unit
FROM civicrm_price_field_value pfv
INNER JOIN civicrm_membership_type mt ON pfv.membership_type_id = mt.id
INNER JOIN civicrm_price_field pf ON pfv.price_field_id = pf.id
- WHERE pf.price_set_id = %1 LIMIT 1';
+ WHERE pf.price_set_id = %1 AND pfv.id = '
+ . $priceFieldValueIds . ' LIMIT 1';
$params = [1 => [$priceSetId, 'Integer']];
$dao = CRM_Core_DAO::executeQuery($query, $params);
```5.69.0https://lab.civicrm.org/dev/core/-/issues/3336Membership status does not get updated during membership import when status o...2022-04-22T16:17:36ZandrewcormickdockeryMembership status does not get updated during membership import when status override is setMembership statuses are not updated during import to a non-rule based status even when status override is set.
To reproduce:
1. Use Memberships/Import Memberships to import a CSV file (example below)
2. Choose Contact Type individual, ...Membership statuses are not updated during import to a non-rule based status even when status override is set.
To reproduce:
1. Use Memberships/Import Memberships to import a CSV file (example below)
2. Choose Contact Type individual, Update existing memberships
3. When choosing a field mapping, make sure to match on Membership ID, Membership Type and Membership Start Date
4. Import file should contain columns for Membership Status and Membership Status Override (in the example below, I chose a non-rule based status "Deceased" plus Membership Status Override of 1)
5. Start import. Import indicates success on the screen.
6. Check records. Note that Membership Status Override is set correctly, however the Membership Status remains at the rule-based status and is not changed to the indicated non-rule status.
Example CSV:
```
Membership ID,Member Since,Membership Start Date,Membership Type,Membership Status,Status Override,First Name,Last Name
1,2016-09-11,2016-09-11,General,Deceased,1,Iris,Lee
3,2016-09-09,2016-09-09,General,Deceased,1,Lincoln,Zope
7,2016-09-05,2016-09-05,General,Deceased,1,Ray,Jones
9,2016-09-03,2016-09-03,General,Deceased,1,Nicole,Ivanov
```
We have noticed this regression in the following Civi versions 5.28.3, 5.29.1 and 5.31.beta1. It was working as expected in Civi version 5.24.3.5.31.0https://lab.civicrm.org/dev/core/-/issues/3335Proposal on Membership Renewal form re 'fixMembershipBeforeRenew'2022-04-22T16:17:33ZeileenProposal on Membership Renewal form re 'fixMembershipBeforeRenew'When a membership is renewed via the backoffice form one step in the process is to call
CRM_Member_BAO_Membership::fixMembershipStatusBeforeRenew
This does a couple of things
1) it checks what the correct status is as of the current d...When a membership is renewed via the backoffice form one step in the process is to call
CRM_Member_BAO_Membership::fixMembershipStatusBeforeRenew
This does a couple of things
1) it checks what the correct status is as of the current date
2) if it is not 'correct' it
- changes the status
- adds a membership log
- adds an activity
- updates a parameter which tells the calling function if the membership is now current.
My belief is that this last parameter is useful to the calling function and the other steps are byproducts of shared code that may not be that relevant.
I propose we either
1) say that it is not necessary/ helpful to change the status & add the various entries in this flow OR
2) if it is useful (probably because the scheduled job didn't run) then we do it in the preProcess function rather than the post process
@andrewhunt @justinfreeman @mattwire @KarinG any opinions on ^^
(note there are some related issues that might come up - please try to add separate issues if you want to raise points outside this specific proposal)5.31.0https://lab.civicrm.org/dev/core/-/issues/3334Option to update expired memberships as part of the job.process_membership2022-04-22T16:17:32ZMichael McAndrewOption to update expired memberships as part of the job.process_membershipIt looks like *expired* memberships are excluded from job.process_membership for performance reasons.
There are (edge) cases where this is problematic. For example, lets say that I increased the grace membership period from 3 to 6 month...It looks like *expired* memberships are excluded from job.process_membership for performance reasons.
There are (edge) cases where this is problematic. For example, lets say that I increased the grace membership period from 3 to 6 months. People whose membership ended 4 months ago will not have their membership status updated from expired to grace.
The other three membership statuses that are excluded from membership updates are 'Deceased', 'Pending' and 'Cancelled'.
Not sure if there is a use case for also re-calculating these but interested in people's thoughts.
Proposed solution: add an option to process normally excluded membership statuses (maybe just expired) from job.process_membership.5.29.0https://lab.civicrm.org/dev/core/-/issues/3331Back-office membership renewals don't display an on-screen notification2022-04-22T16:17:27ZJonGoldBack-office membership renewals don't display an on-screen notificationAs part of CRM-16454, the membership renewal email code was moved from `CRM_Member_Form_MembershipRenewal::submit()` to `CRM_Member_Form_MembershipRenewal::postProcess()`. However, this code no longer generates a status message because ...As part of CRM-16454, the membership renewal email code was moved from `CRM_Member_Form_MembershipRenewal::submit()` to `CRM_Member_Form_MembershipRenewal::postProcess()`. However, this code no longer generates a status message because of early returns.
Since the return values are ignored, it seems safe to ignore the early returns, which results in a status message comparable to a new membership.5.14.0