[CRM-10370] recurring membership via priceset breaks with non-recurring types present Created: 13/Jun/12  Updated: 02/Dec/16  Resolved: 02/Dec/16

Status: Closed
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.1.2
Fix Version/s: Unscheduled

Type: Bug Priority: Major
Reporter: Brian Shaughnessy Assignee: Yashodha Chaku
Resolution: Cannot Reproduce Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding

 Description   

Implementation to handle recurring + non-recurring membership signup
=========================================================
1. On configure contribution page - Memberships tab: check if selected price set provides option for user to select both auto-renew and non-auto-renew memberships. If so, check for valid processor and throw form error if any of selected processors don't support multiple payments in 1 call. Support for Auth.net and PayPal Pro initially.

"The membership price set associated with this online contribution allows a user to select BOTH an auto-renew AND a non-auto-renew membership. This requires submitting multiple processor transactions, and is not supported for one or more of the payment processors enabled under the Fees tab."

2. For online membership signup, if user selects auto-renew + non-auto-renew memberships, submit a separate payment transaction request for each (of corresponding type - subscription or simple payment).

NOTE: This means multiple contribution records are created and line_item rows are linked to the different contribution records (possibly a code change in line item creation).

NOTE: Ideally this can use the same codepath as we use when 'Separate Membership Payment' is checked (is_separate_payment).

— original post describing the problem —
create a membership type with renewing option required
create priceset and create a field that references this membership type
create a second field referencing a membership type that does not have auto-renew enabled
create a contribution page with this price set

with the above settings, the user could potentially select two memberships – one with auto-renew required and one without. when processed, the auto-renew membership is processed as if it were a one-time membership (i.e. the auto-renew function is never implemented).

it appears that the code isn't smart enough to process the auto-renew separately from the one-time payment. it is possible to have the dual payments with most processors, and we do support this in other configurations, so i don't think it's a limitation of the processor.



 Comments   
Comment by David Greenberg [ 14/Jun/12 ]

Initial conversation with Lobo ...

  • On configure contribution page - Memberships tab: check if selected price set provides option for user to select both auto-renew and non-auto-renew memberships. If so, check for valid processor and throw form error if any of selected processors don't support multiple payments in 1 call. Support for Auth.net and possibly PayPal Pro initially.
  • For online membership signup, if user selects auto-renew + non-auto-renew memberships, submit a separate payment transaction request for each (of corresponding type - subscription or simple payment).
  • This means multiple contribution records are created and line_item rows are linked to the different contribution records (possibly a code change in line item creation).
Comment by Joe Murray [ 11/Jul/12 ]

Dave, it might be nice to develop general approach to need for multiple payments from single page submission. This also occurs when user requests separate payment for donation and membership.

Comment by Eileen McNaughton [ 02/Dec/16 ]

I'm closing this on the basis that the situation is unlikely to be the same 6 major release versions later (sometimes issues need to 'age out')

Please re-open if appropriate





[CRM-19538] Tax on Memberships is extremely wrong Created: 19/Oct/16  Updated: 01/Dec/16

Status: Open
Project: CiviCRM
Component/s: CiviContribute, CiviMember
Affects Version/s: 4.6.22, 4.7.12
Fix Version/s: None

Type: Bug Priority: Important
Reporter: Agileware Assignee: Yashodha Chaku
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File edit_pending_membership_contribution.png    
Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Paid Issue Queue
Payment Status: Estimate Sent

 Description   

On the heels of CRM-17417 we've had a couple of clients complaining about tax issues relating to CiviCRM memberships recently.

We've tested issues on 4.7.12 as follows - all tests are using a single tax rate of 10%:

  • Using a contribution page to create an "online" membership seems to work okay - a new membership is created with the correct amount and subsequent offline renewals also work.
  • Adding a membership using the "Add Membership" button and a price set results in an initial contribution that has the tax rate applied twice (e.g. $50 excluding tax becomes $60.50, not $55 as it should); subsequent renewals of this membership have the correct amount.
  • Doing the same without a price set appears to work.
  • Adding the membership with a contribution in Pending state results in a Contribution that when edited exhibits multiple incorrect behaviours - on the contribution edit screen the subtotals have double the tax added (as in 20% instead of 10%), however the contribution total still shows the correct amount - attached edit_pending_membership_contribution.png demonstrates. Saving the contribution results in the total having the tax cumulatively re-applied to the post-tax amount (total is 121% of the tax exclusive amount).

There are some additional cases still being tested, will add more info as it becomes available.



 Comments   
Comment by Seamus Lee [ 19/Oct/16 ]

Just going to tag Joe Murray into this as Joe and his team have been doing work on similar stuff here. Marc Brazeau Also Marc here as Marc has recently been looking into the Add membership and price set stuff.

Comment by Joe Murray [ 19/Oct/16 ]

Jamie Novick does Compucorp want to take a stab at this?

Comment by Yashodha Chaku [ 18/Nov/16 ]

Rough estimate would be 3 - 5 hours.

Comment by Agileware [ 01/Dec/16 ]

Agileware tracking ref 23973

Comment by Yashodha Chaku [ 01/Dec/16 ]

Agileware Do you want core team to start work on this?





[CRM-19009] Offline membership on the fly contact creation doesn't enable 'send confirmation receipt' checkbox. Created: 25/Jun/16  Updated: 01/Dec/16

Status: Open
Project: CiviCRM
Component/s: CiviMember, Core CiviCRM
Affects Version/s: 4.7.8
Fix Version/s: Unscheduled

Type: Bug Priority: Minor
Reporter: Pratik Joshi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding

 Description   

Offline membership on the fly contact creation doesn't enable 'send confirmation receipt' checkbox.

1) Visit the offline membership form
2) For field 'contact' create a contact by 'new individual' form
3) proceed further and check on 'record membership payment'
4) you will not be able to see 'send confirmation receipt' checkbox.

Checked on http://d46.demo.civicrm.org/



 Comments   
Comment by KarinG [ 26/Jun/16 ]

Hi - what about on d47?

Comment by KarinG [ 01/Jul/16 ]

I just confirmed that this is indeed also the case on current dmaster - if you're able to put a PR together for this - then we will try to push that into 4.7.10

Comment by Yashodha Chaku [ 01/Dec/16 ]

Pratik Joshi As a lower-priority unfunded issue, this can be moved forward by either:

  1. Contributing code to fix this in the form of a pull-request.
  2. Funding the core team to work on this via the paid-issue-queue.




[CRM-19469] EWay transaction receipt not sent when member signs up using front-end form but works in the CiviCRM back-end Created: 07/Oct/16  Updated: 01/Dec/16

Status: Open
Project: CiviCRM
Component/s: CiviContribute, CiviMember
Affects Version/s: 4.7.10
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Brian Hay Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding

 Description   

Using the EWay payment gateway if a new member signs up using the front-end online form then they receive a CiviCRM transaction receipt but not the EWay transaction receipt that is supposed to come through as well. If a credit card membership is added to an existing contact in CiviCRM's back-end (and "Send Confirmation and Receipt?" is checked) then both the CiviCRM and EWay transaction receipts are emailed to the new member.

On checking with EWay they report that in the former, problematic case, a billing email address is not being received by them, although a billing email address is clearly there in the contact record.

So there seems to be a difference in what billing data is passed to the EWay payment gateway API between the front-end and back-end of CiviCRM. On a side note, the CiviCRM email transaction receipts are also worded and formatted differently and contain different information, between back and front end.



 Comments   
Comment by Eileen McNaughton [ 01/Dec/16 ]

Is this the eWay you are using? https://github.com/ChrisChinchilla/CiviCRM-eWay-recurring-payment-processor - if so you should log the ticket against the extension





[CRM-19243] Free membership results in two activities and email receipts Created: 18/Aug/16  Updated: 01/Dec/16

Status: In Quality Assurance
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.7.9, 4.7.11
Fix Version/s: 4.7.15

Type: Bug Priority: Minor
Reporter: Anthony Lindsay Assignee: Tunbola Ogunwande
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Attachments: PNG File CiviCRM_Sandbox_on_Drupal.png    
Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Contributed Code

 Description   

Steps to recreate:

  1. create a new membership type
  2. give it a fee of zero
  3. create a membership contribution page
  4. turn off all payment settings
  5. turn on membership settings
  6. allow only the free membership
  7. make membership a requirement for the form
  8. set up a receipt email

Then on completing the contribution form you will receive the receipt email twice and two contribution activities will be recorded on the contact.



 Comments   
Comment by KarinG [ 27/Aug/16 ]

Thanks for reproducing this! It's not a data-critical or security issue - so these issues typically end up waiting for a partner to jump in and fix. You can accelerate this if you have any funding or perhaps access to a developer?

Comment by Tunbola Ogunwande [ 30/Aug/16 ]

I have been able to replicate this.
Will work on this and make a PR soon.
Does this have to get assigned to me? I'm new here.

Comment by KarinG [ 30/Aug/16 ]

I will set you up! Thank you!

Comment by Tunbola Ogunwande [ 02/Sep/16 ]

Submitted a PR for this
https://github.com/civicrm/civicrm-core/pull/8976





[CRM-19298] Membership fee amount doubled in receipt when 'separate membership payment' is configured Created: 01/Sep/16  Updated: 01/Dec/16

Status: Open
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.7.10
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Stoob Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: PatchSubmitted
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File double.png     PNG File separate_.png    
Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Core Team Funds

 Description   

1. Create a contribution page and select the following configurations:
a. Contribution Amounts section enabled
b. Allow other amounts
c. Separate Membership Payment

2. use the 'live page' to sign up for membership and make an additional contribution

3. note that two email receipts are generated (attached)

4. one is the 'additional contribution' and this receipt is correct

5. the other is the 'membership receipt' and the membership fee amount is doubled, and listed twice on the receipt.

I think that the

{if ! $is_separate_payment}

may not be working within the template, because the 'contribution amount' label IS being shown on a separate membership payment.



 Comments   
Comment by Jamie McClelland [ 25/Oct/16 ]

I just experienced the same problem. Are the PR's attached to this issue suppose to fix them? Something seems to have gone wrong with the PR's - seems like a lot of changes!

Comment by Stoob [ 25/Oct/16 ]

I'm not familiar with the patch, but it does indeed look like something has gone wrong. I don't believe the bug has been fixed. Maybe we can try to determine where the original fix was in the patch and make a new patch?

Comment by Jamie McClelland [ 26/Oct/16 ]

The person who opened the PR closed it the same day, so I suspect it was a mistake.

Comment by Jamie McClelland [ 21/Nov/16 ]

I've gone down a rabbit hole and am no closer to patching the bug...

But I did find that in Core_BAO_Message_Template::sendTemplate(), there is a call to create a smarty instance using `$smarty = CRM_Core_Smarty::singleton();` (line 510).

Then, the existing variables are not cleared. So there may be some variable leakage going on.

Comment by Eileen McNaughton [ 22/Nov/16 ]

Can you please test this against the 4.7.14 rc & see if it has changed

Comment by Eileen McNaughton [ 22/Nov/16 ]

Also - you might be able to expand on testIPNPaymentMembershipRecurSuccessNoLeakage() to cover this?

Comment by Jamie McClelland [ 22/Nov/16 ]

Thanks Eileen - I have been reviewing setupMembershipRecurringPaymentProcessorTransaction() - but am struggling with how to simulate a contribution page payment in which the user makes a membership contribution and adds an additional contribution to it. Any tips?

Comment by Eileen McNaughton [ 22/Nov/16 ]

this test does it
api_v3_ContributionPageTest
testSubmitMembershipBlockIsSeparatePaymentPaymentProcessorNow

Comment by Jamie McClelland [ 23/Nov/16 ]

Thanks Eileen - I'm embarrassed to need so much hand holding for unit tests!

Unfortunately, I could not replicate the problem with the unit test (even though I can replicate it via the UI on the same install).

The unit test, however, was not properly checking for the error I am experiencing. So, I modified the unit test so that if the error I'm experiencing does ever happen, it should trigger the test (https://github.com/civicrm/civicrm-core/pull/9438). It's my first real work with unit tests so feedback welcome.

Comment by Stoob [ 23/Nov/16 ]

Thank you for your continued work on this. What can I do to help?

Comment by Eileen McNaughton [ 01/Dec/16 ]

Stoob can you please retest on the rc - but not until it has regenerated. Once this is merged https://github.com/civicrm/civicrm-core/pull/9474 then in the next rc build it will be available from http://dist.civicrm.org/by-date/latest/4.7.14-rc/

The rebuilds take place every 24 hours so depending on timing it could be soon or over 24 hours if I just miss one build with the merge

Note that this latest fix changes the msg_template. The absence of the word 'Additional Contribution' from the online membership message template will be a clue that it has updated successfully.





[CRM-19694] Membership receipt shows data from wrong membership record Created: 28/Nov/16  Updated: 01/Dec/16

Status: Open
Project: CiviCRM
Component/s: CiviContribute, CiviMember
Affects Version/s: 4.7.13
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Robert J. Lang Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: civicontribute, contribution, membership
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File afterRenewal.png     PNG File beforeRenewal.png     PNG File Screen Shot 2016-11-30 at 5.28.01 PM.png    
Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding
Verified?: No

 Description   

When a member renews their membership online, they receive an email receipt with details. That receipt contains the wrong membership data (Type, Start Date).

After investigating several examples, we've established that the erroneous data comes from a membership record whose membership ID is equal to the contribution ID of the renewal (which is associated with a different membership ID, the correct one).

This probably only manifests if the current serial ID of contributions is smaller than the current serial ID of memberships, so that there is an existing membership to pull bogus data from when a new contribution is created.

This looks similar to CRM-19094, which also was a case of doing something to a membership incorrectly by interpreting the contribution ID as a membership ID. That one was overwriting; this merely seems to be putting improper data in the receipts, but the membership records are correct within the system.



 Comments   
Comment by Monish Deb [ 30/Nov/16 ]

Robert J. Lang I was unable to replicate the issue. These are steps are used to replicate the same:

1. As per your comment I increased the auto increment count of membership id so the serial number for next membership id will be greater than its corresponding contribution id. And then done a membership and renewed it again via online contribution. This is the data for that particular membership-contribution

2. But there is no change in Membership's Type and Start date. And here's the screenshot of mail content of online membership receipt before and after renewal.
Before Renewal -

After Renewal -

Comment by Monish Deb [ 30/Nov/16 ]

Did I missed anything ?

Comment by Robert J. Lang [ 30/Nov/16 ]

That looks like the same scenario. We have definitely seen this multiple times on our live site (we learn about it when renewers complain that their receipt doesn't match their settings). I'll try some dev-site renewals to see if I can find a reproducible scenario.

Comment by Eileen McNaughton [ 01/Dec/16 ]

Robert - I would expect this to be fixed in 4.7.14 - can you test the rc & see if it fixes the problem http://dist.civicrm.org/by-date/latest/4.7.14-rc/





Generated at Tue Dec 06 14:08:08 UTC 2016 using JIRA 6.2#6252-sha1:aa343257d4ce030d9cb8c531be520be9fac1c996.