Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-04-22T16:17:27Zhttps://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.0https://lab.civicrm.org/dev/core/-/issues/3329Inherited 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/core/-/issues/3328Membership updates not recorded in contact log2022-04-22T16:17:17ZedvanleeuwenMembership 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/95e4d88c1b16c40fa685032cb4b97b75/activity.png)![log](/uploads/878cd7f93d4967ae70047de240f502d7/log.png)I have noticed that not all changes in the membership records are registered in the contact log. See attachments.![activity](/uploads/95e4d88c1b16c40fa685032cb4b97b75/activity.png)![log](/uploads/878cd7f93d4967ae70047de240f502d7/log.png)https://lab.civicrm.org/dev/core/-/issues/3327Duplicate Membership Shows for "Completed" Memberships2022-04-22T16:17:16Zlee.goodingDuplicate Membership Shows for "Completed" MembershipsThis notification shows for memberships that have been marked as completed, which does not make sense for our setup. We do not want people to use the links in that notification as we want to keep a history of when memberships start/end, ...This notification shows for memberships that have been marked as completed, which does not make sense for our setup. We do not want people to use the links in that notification as we want to keep a history of when memberships start/end, gaps between them, etc.
Would it not make more sense to have "completed" or closed memberships not show as a duplicate?https://lab.civicrm.org/dev/core/-/issues/3326Related membership gets deleted upon updating owner membership via API2024-01-03T05:03:25ZwouterhRelated 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/core/-/issues/3325Using separate donation with free membership result into Pending (incomplete ...2023-11-10T01:45:09ZMonish 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/0cbd58fb74d7bc9467613571f70bb74a/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/core/-/issues/3324Unable to change membership2022-04-22T16:17:12ZedvanleeuwenUnable to change membershipAfter upgrading from 5.36.1 to 5.37.0 I am unable to save a changed membership. When I press Save the update is not carried out and the logo keeps spinning indicating it is still busy.
Drupal Watchdog displays:
> TypeError: Return value...After upgrading from 5.36.1 to 5.37.0 I am unable to save a changed membership. When I press Save the update is not carried out and the logo keeps spinning indicating it is still busy.
Drupal Watchdog displays:
> TypeError: Return value of CRM_Financial_BAO_Order::getFinancialTypeID() must be of the type int, null returned in CRM_Financial_BAO_Order->getFinancialTypeID() (regel 286 van /home/xxx/domains/xxx/public_html/sites/all/modules/civicrm/CRM/Financial/BAO/Order.php).
> Notice: Undefined index: financial_type_id in CRM_Member_Form->setPriceSetParameters() (regel 488 van /home/xxx/domains/xxx/public_html/sites/all/modules/civicrm/CRM/Member/Form.php).
Please help.https://lab.civicrm.org/dev/core/-/issues/3323Membership payments - editing pending payments causes an issue2024-01-02T05:03:27ZgibsonoliverMembership 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/core/-/issues/3322[regression] Recurring contributions no longer properly update memberships (o...2022-04-22T16:17:07ZJonGold[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/core/-/issues/3321[Deprecation] Synchronous XMLHttpRequest on the main thread is2024-01-02T05:03:26Zdanultimate[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/dc00af24c9214a5035a7c2b1cd56e445/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/dc00af24c9214a5035a7c2b1cd56e445/Screenshot_2021-08-27_at_10.47.49.png)
I'm using:
WordPress: 5.8
CiviCRM: 3.39.0https://lab.civicrm.org/dev/core/-/issues/3320Admin Membership type is displayed on Public contribution page.2022-04-22T16:17:02ZjitendraAdmin 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/core/-/issues/3319Creating a relationship fails when a related membership has a contact referen...2022-04-22T16:17:01ZjaapjansmaCreating 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/core/-/issues/3318CiviMember new priceset syntax error2023-12-31T05:03:29Zchris.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/core/-/issues/3317Renewal changes membership start date2022-04-22T16:16:58ZedvanleeuwenRenewal changes membership start dateWhen I renew a membership, the start date is now set to the first date of the membership period. According to the documentation it should not change:
> If the renewal is processed when the membership status is one that has a Yes in the m...When I renew a membership, the start date is now set to the first date of the membership period. According to the documentation it should not change:
> If the renewal is processed when the membership status is one that has a Yes in the member column on Administer > CiviMember > Membership Status Rules then the Start date does not change and the end date is extended by the duration of the renewal.
![image](/uploads/d600b126d469a36aff6d9b1a7545c01c/image.png)https://lab.civicrm.org/dev/core/-/issues/3315Extend api action 'calc' of 'membership_status' with custom date2023-12-31T05:03:29ZwdecraeneExtend api action 'calc' of 'membership_status' with custom dateAt this moment `civicrm_api3_membership_status_calc` only accepts the parameter `membership_id`. The function `CRM_Member_BAO_MembershipStatus::getMembershipStatusByDate` used for calculation gets 'today' as hardcoded param.
Patch attac...At this moment `civicrm_api3_membership_status_calc` only accepts the parameter `membership_id`. The function `CRM_Member_BAO_MembershipStatus::getMembershipStatusByDate` used for calculation gets 'today' as hardcoded param.
Patch attached extends this call with an optional status_date.
[membership_status_calc_optional_status_date.patch](/uploads/09d82a96caec87fc4e2388fb85d421c4/membership_status_calc_optional_status_date.patch)https://lab.civicrm.org/dev/core/-/issues/3314Contribution pages with memberships don't validate correctly when using "quic...2024-02-27T01:10:05ZJonGoldContribution 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/core/-/issues/3313Unable to save a membership with a text price field2023-12-19T22:18:09ZDaveDUnable 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/core/-/issues/3312A 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/core/-/issues/3311Proposal - store metadata on membership renewal on line item2023-06-18T00:43:47ZeileenProposal - store metadata on membership renewal on line item~~UPDATE - discussion on this is converging on adding a new json field 'metdata' to the line item table, permitting data related to that line item to be stored at point of order, and used when confirming. (UPDATE - this is not really the...~~UPDATE - discussion on this is converging on adding a new json field 'metdata' to the line item table, permitting data related to that line item to be stored at point of order, and used when confirming. (UPDATE - this is not really the convergence now - proposal updated below)~~
We have a few issues open ( https://lab.civicrm.org/dev/membership/-/issues/28 , https://lab.civicrm.org/dev/core/-/issues/1402 , https://lab.civicrm.org/dev/financial/-/issues/53 ) that are to my mind blocked by us not having a data model that holds the user's intent when renewing. The focus of this gl is the data model and exposing it via the back office renewal form & doing what is needed in the apis.
**The problem**
When renewing an expired membership the back office user has a fairly blunt way of influencing the calculated dates - they can set the 'renewal date'. However, if the payment is not made in the same form submission that intent is not captured anywhere and cannot be respected when completing the transaction. Likewise the receipt text and number of renewal terms are not captured.
**The proposal data model**
1) add membership_num_terms to civicrm_line_item table.
2) add 'payment_completion_metadata' to the ~~civicrm_line_item~~ civicrm_contribution table for data that is only used in the order->payment flow. Limit what can be stored here to tested values used in that flow - likely to be the message details and effective date the renewal form uses but doesn't sotre.
~~1. New field added to civicrm_line_item called 'metadata' which stores information required to complete the membership renewal - e.g. the field might store ``json_encode(['start_date' => '2010-01-01', 'end_date' => '2020-01-01', 'membership_status_id' => 'Current', 'membership_num_terms' => 2']~~
~~- note this is the new proposal - but I'm wondering what happens if it's renewed in the meantime & then paid~~
~~- New status 'Pending renewal' used when there is a need to record the dates (is_current_member = 0, is_reserved = 1, is_admin = 1 too I think)~~
~~- When a contribution linked to a membership in 'Pending renewal' is completed the status is updated but the dates are not changed~~
~~- If a membership has 'Pending renewal' status and status_override_end_date is set then any processing of that membership after that date would result in it being reverted to previous dates and status - this information should be available in the membership_log table.~~
**Proposed form exposure**
No proposed form changes - this is just storing data already submitted in the renewal form.
~~- the logic could be used outside of existing core forms but within core I think this is something we are exposing to the back-office user doing a renewal - they already have considerable ability to edit dates. So I think this is a form layer thing not some site-wide setting.
- when renewing an expired membership the renewal form would present the user with what will happen to the start date, end date etc if payment is received on that day and offer a checkbox to specify dates - if that is checked then date fields would be exposed an on save the Pending Renewal status would be used with the selected dates.
- potentially the user can also enter the date the 'offer' is available until - ie status_override_end_date~~
**Edge cases**
1. Multiple terms
We would add an extra field membership_num_terms to the line items column
~~https://lab.civicrm.org/dev/membership/-/issues/28 throws up the edge case that more than one renewal term might be selected. Both @jptillman and I assumed that the right way to represent that would be setting qty = n and then picking that when confirming. @andrewhunt didn't think that was the right assumption https://github.com/civicrm/civicrm-core/pull/18618. If we come down on NOT setting qty then we ALSO need a way to record intent for non-expired renewals - this could be an extra membership_num_terms column on the line_item table. (I'm still inclined to my original assumption but more points of view needed).~~
2. About to expire rather than actually expired
Out of scope for now - just do what the form currently does
~~I think we would still manage this in the form ie - "the membership is due to to expire in 4 days, if payment is received after that then .... ' and present the same options as for an actually expired membership~~https://lab.civicrm.org/dev/core/-/issues/3310Manually setting premium causes price mismatch2022-04-22T16:16:34ZsudomanManually setting premium causes price mismatchOn CiviCRM 5.24.3, when editing a contribution to add a premium, the minimum required prices for premiums at the middle and bottom of the drop down list are incorrect, and belong with other premiums. The last two have missing premium pri...On CiviCRM 5.24.3, when editing a contribution to add a premium, the minimum required prices for premiums at the middle and bottom of the drop down list are incorrect, and belong with other premiums. The last two have missing premium price entries.
This matters, because CiviCRM limits which premiums can be applied to a transaction in the admin interface, based on the minimum premium price.
I experimented with removing the '+' symbol from two premiums, but that did not resolve the issue.
Thanks! : )