Combining online membership signup with a recurring additional contribution results in incorrect recurring contribution amount and frequency

The following configurations for an online contribution page results in the wrong creation of a recurring contribution with the wrong frequency (and sometimes wrong amount).

———————————
1. Configuration ONE: Modify sample 'Membership Signup' contribution page - Amounts tab - checking "Contribution Amounts section enabled" and "Recurring Contributions". Also "Allow other amounts". Now check "Separate Membership Payment" on the Memberships tab.

• Using the dummy processor, submit a contribution with a membership selected and "I want to contribute this amount every month
  " checked.

• Note that the confirmation page incorrectly shows the membership being autorenewed monthly (because the membership rather than the additional contribution is being set up as the recurring transaction). See Membership_ContributionRecur_BadAutoRenewMsg.46.PNG

• Check the resulting transactions:
  (see Membership_with_RecurContribution_SeparatePayments.PNG)
  • non-recurring contribution created with additional contribution amount, status is Pending. The non-recurring contribution should be for the membership fee amount, and should have Completed status
  • recurring contribution incorrectly created for membership fee amount rather than the additional contribution amount - and should have status Pending (awaiting IPN) not Completed.

———————————
2. Configuration TWO: Now UNcheck "Separate Membership Payment" on the Memberships tab and repeat ....

• Using the dummy processor, submit a contribution with a membership selected and "I want to contribute this amount every month
  " checked.
• Note that the confirmation page incorrectly shows the membership being autorenewed monthly (because the membership rather than the additional contribution is being set up as the recurring transaction). See Membership_ContributionRecur_BadAutoRenewMsg.46.PNG
• Check the resulting transactions:
  • initial contribution created for first membership fee + additional contribution and status set to Completed. I "think" this is correct - but I'm not sure that a real payment processor allows us to request an initial contribution with a DIFFERENT AMOUNT from the recurring subscription (i.e. initial contribution is membership fee (100) + additional (50) - so 150. Recurring is for $50 each month.

• • recurring contribution incorrectly created for membership fee amount rather than the additional contribution amount

———————————
3. Configuration THREE: Now modify the Student membership type to ALLOW auto renew. Then update the contribution page Membership tab to set Auto-renew Optional for the Student membership.

NOTE: I’m not sure the code was ever set up to support 2 recurring contributions being submitted at the same time. If not, then we need to deal w/ this as a formRule in Manage Contribution Page - and not allow admin to select both Recurring contribution on Amounts tab AND one or more Autorenew memberships.

• Using the dummy processor, submit a contribution with a membership selected and "I want to contribute this amount every month
  " checked.
• Note that the ‘main’ contribution page has some fields in the wrong order. The “Please renew my membership automatically should be displayed right below the membership types radio. (see IsRecurANDAutoRenew.46.PNG)
• The confirmation page still incorrectly shows the membership being autorenewed monthly (because the membership rather than the additional contribution is being set up as the recurring transaction). See Membership_ContributionRecur_BadAutoRenewMsg.46.PNG
• Check the resulting transactions:
  • The membership recurring contribution is for the correct amount, but wrong frequency (monthly instead of annually) and has status Completed (should be Pending awaiting IPN).
  • The additional contribution is NOT recurring (but should be)

• • • • • • IMPORTANT: The only combination that we know worked properly in 4.3 and 4.4 is Configuration One. If the code doesn’t easily support Two and Three, then we should block them with form rules for now.

--------- Original Post -------------
I just tested the following
1) set up a contribution page with a membership block using is_separate_membership and the page allowing recur. I used the dummy processor
2) process transaction (in live mode)

Expected result

• I wasn't sure but thought there might be 2 separate recurring transactions initiated

Hoped for result (for this customer) the membership would be once-off and the contribution would be recurring. I had thought that in the case of #1 I might be able to alter the number of recurrences for the membership on the fly.

Actual result

• the membership got a created, completed transaction with a recurring contribution BUT
• the donation contribution remained in a PENDING state.

This actual result seems wrong WRT the donation contribution.

Note that my really preferred solution would probably involve an extra field on civicrm_price_field for is_recur. The definition would be 'if this is a recurring transaction does this part recur' and implictly if some parts are 'is_recur' & some aren't they would be separate transactions in a recurring situation.

We also have a somewhat related requirement to record separate parts of a transaction as separate contributions based. I'm still thinking this through but I see moving the 'is_separate_payment' from the membership_block table to the price_set table as part of consolidating to only use price sets.