Membership - archive issueshttps://lab.civicrm.org/dev/membership/-/issues2022-04-22T16:18:00Zhttps://lab.civicrm.org/dev/membership/-/issues/41Recurring membership term is incorrect when using price sets2022-04-22T16:18:00ZJonGoldRecurring 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.JonGoldJonGoldhttps://lab.civicrm.org/dev/membership/-/issues/14Canceled pending memberships are considered "lifetime" memberships2022-04-22T16:17:59ZJonGoldCanceled pending memberships are considered "lifetime" memberships`CRM_Member_BAO_Membership::getAllContactMembership()` with `$onlyLifeTime` set to `TRUE` searches for all of a contact's memberships, and will return a non-empty array if a membership exists that a) has no end date, b) status is not `Pe...`CRM_Member_BAO_Membership::getAllContactMembership()` with `$onlyLifeTime` set to `TRUE` searches for all of a contact's memberships, and will return a non-empty array if a membership exists that a) has no end date, b) status is not `Pending`.
Today, I came across a scenario where a pending membership was canceled. Since status was `Canceled` and not `Pending` it was returned as a "lifetime" membership and prevented the user from signing up online for a new membership.
This is a bit of an edge case - but I wonder if there's a better definition of a lifetime membership? If I exclude `Canceled` memberships that would exclude lifetime canceled memberships (another edge case). Is there anything I can do short of querying the `civicrm_membership_log` to see if the membership was ever anything but pending or canceled?JonGoldJonGoldhttps://lab.civicrm.org/dev/membership/-/issues/24Memberships of disabled membership types do not appear on the membership tab ...2022-04-22T16:17:57ZalicefruminMemberships of disabled membership types do not appear on the membership tab BUT do throw duplicate Membership WarningIf a contact has a Membership of the Membership Type "Student"
and the membership type "Student" gets disabled
On the contacts membership tab you will see no memberships but when you try and create a new membership for this contact a "D...If a contact has a Membership of the Membership Type "Student"
and the membership type "Student" gets disabled
On the contacts membership tab you will see no memberships but when you try and create a new membership for this contact a "Duplicate Membership" warning will appear.
To some extent this makes sense because if one were to re enable the disabled student membership type and a user had created a new membership that could be problematic. However from a UI perspective it seems like it would be useful for disabled memberships to be listed.https://lab.civicrm.org/dev/membership/-/issues/11Prevent Duplicate memberships2022-04-22T16:17:55ZprdufresnePrevent Duplicate membershipsThere needs to be a mechanism to prevent duplicate memberships for the same user. There are legitimate circumstances for there to be multiple memberships, but there needs to be a way to prevent it as well.
I propose two options:
1. A ...There needs to be a mechanism to prevent duplicate memberships for the same user. There are legitimate circumstances for there to be multiple memberships, but there needs to be a way to prevent it as well.
I propose two options:
1. A checkbox in the Contribution Page settings Memberships tab to "Prevent duplicate memberships"
2. A checkbox in the Membership Types page that "Allows duplicate membership of this type"
In either case, the verification logic should be specific to that membership type.https://lab.civicrm.org/dev/membership/-/issues/3Additional Memberships added via Contribution Pages overwrite existing member...2022-04-22T16:17:52ZalanpuccinelliAdditional Memberships added via Contribution Pages overwrite existing membershipsVerified on current demo install of ver 5.0
To Reproduce:
1. Create an inherited membership for an individual by assigning the membership to a related organization.
2. Create a Pending membership via a contribution page and select "Pay ...Verified on current demo install of ver 5.0
To Reproduce:
1. Create an inherited membership for an individual by assigning the membership to a related organization.
2. Create a Pending membership via a contribution page and select "Pay Later/by check"
3. Notice that Pending membership is not created for contribution page membership
4. Receive payment for the pending membership contribution. (Membership should switch to active at this point)
5. Because there is no pending membership it appears that the system will overwrite the existing inherited membership and extend the end date by whatever the new membership period is.https://lab.civicrm.org/dev/membership/-/issues/33Wrong frequency when purchasing a membership2022-04-22T16:17:46ZsudomanWrong 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);
```https://lab.civicrm.org/dev/membership/-/issues/2Add 'membership start date' as an option when creating Scheduled Reminder bas...2022-04-22T16:17:44ZjitendraAdd 'membership start date' as an option when creating Scheduled Reminder based on MembershipThis is what we get as options
![image](/uploads/35f682fa9321f7903faffdc18a7d051c/image.png)
This ticket aims to add membership start date to the option list.
@eileen @totten I don't see any logical reason for not including it before....This is what we get as options
![image](/uploads/35f682fa9321f7903faffdc18a7d051c/image.png)
This ticket aims to add membership start date to the option list.
@eileen @totten I don't see any logical reason for not including it before. Have I missed something? Do you see any downsides on adding start date as an option?jitendrajitendrahttps://lab.civicrm.org/dev/membership/-/issues/34Unable to change membership after upgrading to 5.342022-04-22T16:17:41ZedvanleeuwenUnable to change membership after upgrading to 5.34I am not able to change a membership after upgrading from 5.33.2 to 5.34.0.
Steps to reproduce:
1. Edit a membership
1. Change e.g. the end date
1. Save the membership.
A popup message appears saying the membership change has been carr...I am not able to change a membership after upgrading from 5.33.2 to 5.34.0.
Steps to reproduce:
1. Edit a membership
1. Change e.g. the end date
1. Save the membership.
A popup message appears saying the membership change has been carried out with the date given. However, the change is not recorded.
This happens with every change.
![image](/uploads/2af0a0516084b0d341a101ccf65cbf01/image.png)
Workaround: Use the Renew option and change the number of renewal periods.https://lab.civicrm.org/dev/membership/-/issues/30Membership status does not get updated during membership import when status o...2022-04-22T16:17:37ZandrewcormickdockeryMembership 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/membership/-/issues/27Proposal on Membership Renewal form re 'fixMembershipBeforeRenew'2022-04-22T16:17:35ZeileenProposal 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/membership/-/issues/18Option 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/membership/-/issues/10"Start date must be the same or later than Member since" triggered when dates...2022-04-22T16:17:29Zcalbasi"Start date must be the same or later than Member since" triggered when dates are the sameI get this issue on my drupal/civicrm 5.10.3 instance. And I test it, and I've found it there too: https://civicrm.demo.civihosting.com
Using the same date for "start date" and "member since" fields should NOT trigger this error.
My w...I get this issue on my drupal/civicrm 5.10.3 instance. And I test it, and I've found it there too: https://civicrm.demo.civihosting.com
Using the same date for "start date" and "member since" fields should NOT trigger this error.
My workaround was change one of 2 dates, but this issue is a bug and an usability issue.5.11https://lab.civicrm.org/dev/membership/-/issues/9Back-office membership renewals don't display an on-screen notification2022-04-22T16:17:28ZJonGoldBack-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.0https://lab.civicrm.org/dev/membership/-/issues/8Inherited memberships not created correctly when contact count changes.2022-04-22T16:17:19Zsamknelson@gmail.comInherited memberships not created correctly when contact count changes.(Migrating this issue from https://issues.civicrm.org/jira/browse/CRM-21463, since it's been idle there for over a year.)
Suppose you have an organization membership. Suppose the organization has 4 related contacts, each of whom inheri...(Migrating this issue from https://issues.civicrm.org/jira/browse/CRM-21463, since it's been idle there for over a year.)
Suppose you have an organization membership. Suppose the organization has 4 related contacts, each of whom inherits the membership.
Suppose you then add a related contact.
Suppose you then renew the membership.
The newly related contact does not receive the inherited membership. In fact, each time you save / update the membership, an apparently random set of 4 related contacts receives the inherited membership.
============
This turns out to be a bug in Member/BAO/Membership.php. At line 1445, we see
if ($relMembership->find(TRUE)) {
$params['id'] = $relMemIds['membership'] = $relMembership->id;
}
However, params['id'] is never initialized, so if some related memberships are not found, they are assigned the ID from the last iteration through the loop – meaning the previous contact loses their membership.
The solution is to add $params['id'] = NULL right before. (It would probably be better to set $params = NULL at the beginning of the loop, but I haven't tested that.)
I haven't submitted a patch, but it should be straightforward.5.31.0https://lab.civicrm.org/dev/membership/-/issues/6Membership updates not recorded in contact log2022-04-22T16:17:18ZedvanleeuwenMembership updates not recorded in contact logI have noticed that not all changes in the membership records are registered in the contact log. See attachments.![activity](/uploads/f8ae3e291766da4bfe081eaf7dc0d19c/activity.png)![log](/uploads/19ea6d15ce3ad6d60618d5de130dd3e7/log.png)I have noticed that not all changes in the membership records are registered in the contact log. See attachments.![activity](/uploads/f8ae3e291766da4bfe081eaf7dc0d19c/activity.png)![log](/uploads/19ea6d15ce3ad6d60618d5de130dd3e7/log.png)https://lab.civicrm.org/dev/membership/-/issues/19Related membership gets deleted upon updating owner membership via API2022-04-22T16:17:15ZwouterhRelated membership gets deleted upon updating owner membership via APII would like to give several people a membership, linked to 1 payment
- person A: membership (+ contribution)
- person B: membership (related to membership person A)
```
$contact_a = 2;
$contact_b = 3;
$contribution = civicrm_api3('Co...I would like to give several people a membership, linked to 1 payment
- person A: membership (+ contribution)
- person B: membership (related to membership person A)
```
$contact_a = 2;
$contact_b = 3;
$contribution = civicrm_api3('Contribution', 'create', [
'financial_type_id' => 2,
'contact_id' => (int) $contact_a,
'contribution_status_id' => 2,
'total_amount' => 50,
'is_pay_later' => 1,
]);
$main_membership = civicrm_api3('Membership', 'create', [
'contact_id' => (int) $contact_a,
'membership_type_id' => 1,
'status_id' => 5,
'skipStatusCal' => 1,
]);
$part_membership = civicrm_api3('Membership', 'create', [
'contact_id' => (int) $contact_b,
'owner_membership_id' => $main_membership['id'],
'membership_type_id' => 1,
'status_id' => 5,
'skipStatusCal' => 1,
]);
$memb_payment = civicrm_api3('MembershipPayment', 'create', [
'membership_id' => (int) $main_membership['id'],
'contribution_id' => (int) $contribution['id'],
]);
```
This seems correct, person A gets a membership & contribution, person B gets a membership related to the membership of person A.
As soon as I process the membership payment via the API the contribution is complete and the membership for person A becomes active, BUT the membership for person B is deleted !?
```
$complete = civicrm_api3('Contribution', 'completetransaction', [
'id' => 9,
'is_email_receipt' => 0
]);
```
I have simplified the operation to only the membership registrations:
```
$contact_a = 2;
$contact_b = 3;
$main_membership = civicrm_api3('Membership', 'create', [
'contact_id' => (int) $contact_a,
'membership_type_id' => 1,
'status_id' => 5,
'skipStatusCal' => 1,
]);
$part_membership = civicrm_api3('Membership', 'create', [
'contact_id' => (int) $contact_b,
'owner_membership_id' => $main_membership['id'],
'membership_type_id' => 1,
'status_id' => 5,
'skipStatusCal' => 1,
]);
```
And if I then set the membership of person A to "New" the membership of person B is deleted !?
```
$new = civicrm_api3('Membership', 'create', [
'id' => 39,
'status_id' => "New",
]);
```
The problem therefore lies somewhere with the update of the membership of person A.
Does anyone have an idea?https://lab.civicrm.org/dev/membership/-/issues/38Using separate donation with free membership result into Pending (incomplete ...2022-04-22T16:17:14ZMonish DebUsing separate donation with free membership result into Pending (incomplete transaction) 0$ contributionSteps to replicate:
1. Create a 0$ fixed membership type
2. Configure a new/existing online contribution page, with separate donation and choose 0$ membership type under `Membership Fee`
3. Do a online contribution with $1 separate dona...Steps to replicate:
1. Create a 0$ fixed membership type
2. Configure a new/existing online contribution page, with separate donation and choose 0$ membership type under `Membership Fee`
3. Do a online contribution with $1 separate donation with 0$ membership
Bug:
Two donation are created, one with Completed 1$ contribution and other `Pending (Incomplete Transaction)` 0$ contribution linked with Pending free membership:
![Screenshot_2021-06-22_at_2.06.49_PM](/uploads/e96ec04fe4c895ebb90deab81cc4471b/Screenshot_2021-06-22_at_2.06.49_PM.png)
Expected result:
Complete 0$ membership's donation associated with `new` free membership
cc @eileen @JoeMurrayMonish DebMonish Debhttps://lab.civicrm.org/dev/membership/-/issues/40Membership payments - editing pending payments causes an issue2022-04-22T16:17:12ZgibsonoliverMembership payments - editing pending payments causes an issueIf you add to an existing membership a pending payment (renewal payment). Then edit the amount of that pending payment manually and Save then the membership is renewed with the end date altered. Even though the membership payment is stil...If you add to an existing membership a pending payment (renewal payment). Then edit the amount of that pending payment manually and Save then the membership is renewed with the end date altered. Even though the membership payment is still pending.
Tried and recreated on 2 different systems.https://lab.civicrm.org/dev/membership/-/issues/13[regression] Recurring contributions no longer properly update memberships (o...2022-04-22T16:17:11ZJonGold[regression] Recurring contributions no longer properly update memberships (on PayPal Pro, maybe others)This is a subtle problem, so apologies for a long explanation!
In [this commit](https://github.com/civicrm/civicrm-core/commit/5ed1203902d7bbade9341a8df800c88d33044736), we refactor how we find memberships tied to the contribution.
At ...This is a subtle problem, so apologies for a long explanation!
In [this commit](https://github.com/civicrm/civicrm-core/commit/5ed1203902d7bbade9341a8df800c88d33044736), we refactor how we find memberships tied to the contribution.
At first glance, the refactor seems to make sense: In the old code, we load related membership objects, which populates `$contribution->_relatedObjects['membership']`. Then we iterate through `$contribution->_relatedObjects['membership']`. In the new code, we refactor loading related memberships into its own function, then iterate through the value returned.
However, in at least some cases, `$contribution->_relatedObjects['membership']` *is already populated* with membership objects. The old code picks these up; the new code ignores them.
The refactor assumes that there's a MembershipPayment record with a `contribution_id` that matches the **current** contribution. However, in the case of a recurring membership, the corresponding MembershipPayment record has the `contribution_id` of the **initial** contribution. `CRM_Core_Payment_PayPalProIPN` calls `CRM_Contribute_BAO_Contribution::loadObjects()` *twice* - once for the original contribution in the series, once for the current contribution. So the contents of `$contribution->_relatedObjects['membership']` differ from the results of loading only the *current* contribution's related memberships.
The result is that related memberships are no longer updated in an auto-renew scenario.
Steps to replicate would be tough, but would go something like this:
* Create an auto-renewing membership (using PayPal Pro, though I imagine other processors do something similar).
* When the second contribution comes in, observe that the membership end date is not updated.https://lab.civicrm.org/dev/membership/-/issues/39[Deprecation] Synchronous XMLHttpRequest on the main thread is2022-04-22T16:17:06Zdanultimate[Deprecation] Synchronous XMLHttpRequest on the main thread isGetting this error while trying to update a membership record.
is this related to a similar issue with the stripe extension?
![Screenshot_2021-08-27_at_10.47.49](/uploads/cf68ea17ee6861d7bc604fc14f6a8075/Screenshot_2021-08-27_at_10.47....Getting this error while trying to update a membership record.
is this related to a similar issue with the stripe extension?
![Screenshot_2021-08-27_at_10.47.49](/uploads/cf68ea17ee6861d7bc604fc14f6a8075/Screenshot_2021-08-27_at_10.47.49.png)
I'm using:
WordPress: 5.8
CiviCRM: 3.39.0