Details
Trivial
Description
In 4.6 users are blocked from saving a page with the following config
- contribution + membership as separate payments
- one or more membership is of a recurring type.
- form is set to is_recur
This was blocked in https://issues.civicrm.org/jira/browse/CRM-16165
on the basis it was too complex to support this scenario at this stage.
The code in CRM_Contribute_Form_ContributionPage_Amount appears to enforce this. But I found that when I started changing membership types (setting General to autorenew & then deconfiguring it from the page) it still failed. On FURTHER investigation it appears that the form check was evaluating the data in civicrm_membership_block.membership_types - but changing the configured membership options DIDN'T change the value in this field (which happened to be a:3:
{i:1;s:1:"2";i:2;s:1:"0";i:4;N;})
From what I can tell the field civicrm_membership_block.membership_types is used inconsistently & although there is code in the MembershipBlock form to keep it updated it is being unreliably updated. By contrast the relevantquick-config prices set is being accurately updated and I think we should work towards removing the membership_types field from the membership_block table. Note that there is a membership price set linked to each contribution page for which membership is defined. This is marked as quick config where the user isn't aware of using price sets, but it still seems to superceded the membership_types field in the membership_block
"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 Amounts tab."
In order to not duplicate the code I altered that function to use the newly shared code, but I have some doubts that the check is working as it should (before or after) so will keep that out of the inital PR