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/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/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/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/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/4Admin Membership type is displayed on Public contribution page.2022-04-22T16:17:05ZjitendraAdmin Membership type is displayed on Public contribution page.When visibility of membership type is updated to `Admin`, it is still displayed on front-end contribution pages. Steps to replicate -
- Create a membership type.
- Add it to a contribution page.
- Set visibility of the type to `Admin`.
...When visibility of membership type is updated to `Admin`, it is still displayed on front-end contribution pages. Steps to replicate -
- Create a membership type.
- Add it to a contribution page.
- Set visibility of the type to `Admin`.
- Navigate to contribution page - the membership type is still displayed on the page.jitendrajitendrahttps://lab.civicrm.org/dev/membership/-/issues/37Creating a relationship fails when a related membership has a contact referen...2022-04-22T16:17:02ZjaapjansmaCreating a relationship fails when a related membership has a contact reference custom field.**How to reproduce?**
1. Create a new membership type. Set **Relationship type** to Employer of
2. Create a custom field set for this membership type
3. Add a custom field of type Contact Reference
4. Create a new organization
5. Add th...**How to reproduce?**
1. Create a new membership type. Set **Relationship type** to Employer of
2. Create a custom field set for this membership type
3. Add a custom field of type Contact Reference
4. Create a new organization
5. Add the membership and fill in a value at the custom field
6. Now add a **Employer of** relationship between this organization and an Individual, press save
**Expected results**
Relationship gets saved and a related membership is created with the correct value for the custom field
**Actual results**
No relationship is created, no error is shown, the civicrm logo stays on the screen turning around.
Also when refreshing the page an error popups with something: **custom_xx is not a valid integer**
**Extra information**
When debuging this issue I disovered that a `Membership.get` api is used. And those values are passed to a `Membership.create` api call. The paramaters for the custom field have the format of `custom_xx = 'Joe'` and `custom_xx_id = 202`5.39.0jaapjansmajaapjansmahttps://lab.civicrm.org/dev/membership/-/issues/25CiviMember new priceset syntax error2022-04-22T16:17:00Zchris.hCiviMember new priceset syntax errorCiviMember New Priceset page (/admin/price&reset=1&action=add) shows a error (DB Error:snytax error)
Site Info
- CiviCRM 5.24.4
- Drupal 7
- PHP 7.2
- MySQL 5.7.29
- Ubuntu 18.04 LTSCiviMember New Priceset page (/admin/price&reset=1&action=add) shows a error (DB Error:snytax error)
Site Info
- CiviCRM 5.24.4
- Drupal 7
- PHP 7.2
- MySQL 5.7.29
- Ubuntu 18.04 LTShttps://lab.civicrm.org/dev/membership/-/issues/36Contribution pages with memberships don't validate correctly when using "quic...2022-04-22T16:16:48ZJonGoldContribution pages with memberships don't validate correctly when using "quick config" price fieldsIn `CRM_Contribute_Form_Contribution_Main::formRule`, there are multiple references to `$self->_useForMember`. `$self->_useForMember` is only `TRUE` if the price set is a "quick config" price set (and is explicitly used as such in the t...In `CRM_Contribute_Form_Contribution_Main::formRule`, there are multiple references to `$self->_useForMember`. `$self->_useForMember` is only `TRUE` if the price set is a "quick config" price set (and is explicitly used as such in the template). However, during `formRule` validation, it's used as a proxy for "this contribution page uses memberships". @mattwire correctly identified the problem on the confirmation class in [PR 15094](https://github.com/civicrm/civicrm-core/pull/15094).
As a result, several membership-specific validations are bypassed.
I attempted to move his methods to the shared `ContributionBase` class and make them protected, but I ran into deeper validation issues. I can't justify further work on this, but wanted to document for future folks who bang their heads against this.https://lab.civicrm.org/dev/membership/-/issues/31Unable to save a membership with a text price field2022-04-22T16:16:47ZDaveDUnable to save a membership with a text price fieldSame problem in 5.28 and master and can reproduce on dmaster.demo.civicrm.org. Or maybe I'm missing something.
1. Create a price set used for memberships.
1. Set financial type to member dues.
1. Add one text field (the default input fi...Same problem in 5.28 and master and can reproduce on dmaster.demo.civicrm.org. Or maybe I'm missing something.
1. Create a price set used for memberships.
1. Set financial type to member dues.
1. Add one text field (the default input field type).
1. Amount doesn't matter - put in some number.
1. Leave other fields at defaults.
1. Create a new membership.
1. Choose the price set.
1. Put in quantity 1.
1. Can leave the rest at defaults.
1. Click Save.
1. ERROR: Select at least one membership option.
It works with a radio field.https://lab.civicrm.org/dev/membership/-/issues/7A Contact with a Pending membership cannot be merged with another Contact due...2022-04-22T16:16:45Zjustinfreeman (Agileware)A Contact with a Pending membership cannot be merged with another Contact due to missing membership End DateA Contact with a Pending membership cannot be merged with another Contact due to missing membership End Date.
The membership End Date is not set on a pending membership.
The sequence of events is:
1. Contact signs up for new membership
...A Contact with a Pending membership cannot be merged with another Contact due to missing membership End Date.
The membership End Date is not set on a pending membership.
The sequence of events is:
1. Contact signs up for new membership
1. Contact already exists in CiviCRM (as a non-member) - or is similar contact
1. CiviCRM Admin tries to merge the two Contacts
1. The generic: DB Error: unknown error is then raised
Copy of error from CiviCRM logs.
```
Dec 06 12:32:20 [info] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_info] => UPDATE civicrm_membership SET end_date = '' WHERE id=281 [nativecode=1292 ** Incorrect date value: '' for column 'end_date' at row 1]
[type] => DB_Error
[user_info] => UPDATE civicrm_membership SET end_date = '' WHERE id=281 [nativecode=1292 ** Incorrect date value: '' for column 'end_date' at row 1]
[to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::handle prefix="" info="UPDATE civicrm_membership SET end_date = '' WHERE id=281 [nativecode=12
92 ** Incorrect date value: '' for column 'end_date' at row 1]"]
)
```
Agileware Ref: CIVICRM-1122https://lab.civicrm.org/dev/membership/-/issues/22Membership by Relationship not created when Current Employer field is updated2022-04-22T16:16:31ZalanpuccinelliMembership by Relationship not created when Current Employer field is updatedIt used to be that when a Current Employer was added to a profile it would automatically build the Relationship AND any Related membership. It now only seems to do the Relationship and you have to edit and re-save the profile and then th...It used to be that when a Current Employer was added to a profile it would automatically build the Relationship AND any Related membership. It now only seems to do the Relationship and you have to edit and re-save the profile and then the Membership will add.https://lab.civicrm.org/dev/membership/-/issues/23Update multiple membership doesn't set is_override2022-04-22T16:16:25ZDetlev SieberUpdate multiple membership doesn't set is_overrideMembership status rules can be set as "Administrator Only". By doing this, status won't be changed by the process_membership scheduled job anymore, but can only be changed with the is_override option by an administrator. This makes sense...Membership status rules can be set as "Administrator Only". By doing this, status won't be changed by the process_membership scheduled job anymore, but can only be changed with the is_override option by an administrator. This makes sense e.g. for a custom status as "expelled" or "excluded". When I want to change the membership status to "excluded", I have to use the is_override option, and the field is_override in civicrm_membership is set to "1".
However, when I update several memberships at once with the action "Update multiple memberships" (via profile) to "excluded", the status is changed correctly. But is_override isn't changed, so that with the next run of the scheduled job "process_membership", the status will be updated again according to the status rules - which is not what we want!
Instead, when changing a membership status which is marked "Administrator Only", the field "is_override" should be set automatically - the same way it would be done when I change 1 membership manually.