Details
-
Type:
Bug
-
Status: Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: 4.6.8
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:None
-
Funding Source:Needs Funding
Description
LOGGING THIS BUT I NEED TO DO MORE TESTING AS GETTING INCONSISTENT RESULTS
In order to configure a membership price set to work as a recurring with Authorize.net you need to
1) configure the membership type in it (let's stick with one) to be optional renew
2) set the contribution page to use a price set on the membership tab
3) set the contribution page to be recurring
If you fail to do the 3rd of these then the contribution page will say it is renewing - but not actually create a recurring contribution. (certainly this is the case with Authorize.net)
I think at one point I figured out a combination of clicks that made this possible in the UI - but now I don't seem to be able to ....
Attachments
Activity
yes - possibly - I don't feel like the fix against that issue is the right fix - just the for-now fix. I can accept using a meaningful name for the default price set - but I'm not at all sold on the fields within it having meaning.
Just to re-litigate briefly - IEHO ....
The concepts of quick-config pricesets & is_monetary for events & contribution pages should be confined to the event & contribution configuration pages.
In the post-process the is_monetary-ness should be calculated not rely on the form value & the quick-config pricesets should behave like other price sets. There are a couple of gaps on the price-sets - some are in the front end UI but at the back end the most notable one is that for the quick config price sets you can pass the financial_type_id. I believe the ideal would be to create a default price set per financial type & then assign the one with the right type. With that done I think most of the blockers to treating all price-sets the same post-process could go.
Anyway - I'm going to close this issue unless I get more useful info to take it further.
This seems to be fixing the problem - https://github.com/fuzionnz/civicrm-core/commit/436e7e6db6513459abdeb0d74c06397732e8e33c
But I'm not consistently reproducing so I'm going to sit on this one for a little while.
The patch makes sense to me because we are saying that form membership renewals the form does NOT need to be set to is_recur (that seems to have been the upshot of the last round of re-work) yet that value is being checked for....
Logically the fact that only that one function checks that & fails to action at that point re-enforces that logic - ie. The Confirm & Thank you pages advise the recur will be created BUT the actual recur is NOT. This has worse consequences with Authorize.net than others as Authorize,.net ALSO doesn't create in Authorize.net the recur (whereas others just check $params['is_recur']