Allowing selection of multiple membership types on contribution form

[GregoryHeller]

Currently a user can only "purchase" one membership type at a time.  There may be cases (i've got one) for allowing a  user to purchase 2 membership types (from 2 specific categories, requiring one from each, or requiring one from one and making the other optional).

Essentially "choose one membership from column a, and one from column b" or "choose one membership from column a, and optionally an additional from column b).  And of course there are different types (levels) of memberships in the column a, and multiple in column b
.
There does not seem to be any way to do this in the current version (ccrm 1.9). Without essentially requiring two completely separate transactions which fickle and impatient users (what users aren't  ) will probably not stick around for.

My hacked together solution is to essentially take care of one membership through a "contribution" and the other through a "membership".  And then write some code to add the first membership as a membership record (to the contact).


More on the example for those who are dying to know what this use case is:
National organization that requires a national membership.
The organization has local chapters, and membership in a local chapter is optional, but cannot be purchased without a national membership.

I could see a case for the opposite: requiring a local membership and making a national options.

[Dave Greenberg]

Hi Greg - Interesting use case, and probably fairly common.

The data model for storing the Membership Signup "blocks" that are injected in the contribution pages would support having multiple "blocks" (each block is an entry in civicrm_membership_block - which is keyed to a given contribution page). So implementing a "real" solution to this would involve working with the form rendering logic (which currently picks only the first membership_block it finds), and then the processing logic (which is only "expecting" one membership type value etc.).

It would be cool if you can work with someone on your team to develop a patch to handle this case for a future release :-)

[speleo]

The dual membership issue is one that has prevented me from running CiviContribute for membership updates. My user case is very similar in that members must renew their Club membership and also pay for an optional National membership fee.

Gregory, your user case sounds pretty much identical and I would be very interested to see this implemented.

When I was looking into this I put together a discussion document which is on the forum here
http://forum.civicrm.org/index.php/topic,932.msg3891.html#msg3891
and on the wiki here
http://wiki.civicrm.org/confluence/display/CRM/CiviContribute+++CiviMember+membership+renewal+payment+process+requirements

[lcdweb]

The price_set functionality for events, introduced in 1.8 (still a little buggy), could probably be used as the model for this functionality. It gives you the ability to create multiple "blocks" of registration sets, and to define which are required.

In fact, with some creativity, you might be able to hack that tool to make it work for your immediate membership needs.

The biggest bug with the price_set function is that it only works on frontend pages. If you have to register someone for an event in the backend, the price_set options don't appear correctly. Send me a private message if you need that fix.

[speleo]

Thanks lcdweb,

Understand what you are saying about pricesets. Extending that functionality to memberships is one way forward. Another complication with updating memberships online is to only offer the memberships that are relevant to an individual contact. For example you don't want to offer a discount membership or life membership if the contact is not eligible for it. 

It's not too hard to only offer their current membership (from memory you can hack that to the template).

I'm not a heavy hitting coder so it's kind of difficult to walk the walk on this one.

[lcdweb]

Agreed. Hopefully over time the community and core team will be able to build more business logic into the membership and event tools. I'm a Joomla user, so before that happens, we probably need to get the ACL issues up to speed (expected in 2.0 I believe).

For what it's worth, I have always handled lifetime memberships as exclusively an admin function -- never exposed on the frontend. I view it as a special category that needs to be assigned, not applied for by the user. And since it's lifetime -- never expires -- it's not an admin heavy task. You do it once and never worry about it again.

For discount memberships, couldn't you use the contribution premium tools to offer those? Actually, I guess your issue is identifying WHO is eligible to receive them, not just the ability to do them.

-Brian

[speleo]

Handling lifetime memberships as an admin function is an option but the membership type still exists. Definitely need logic in terms of what memberships are offered to who. Gets tricky with relationships (joint members) I suspect.

I too am a Joomla user who has been waiting for a proper ACL for far far too long now. If I found a decent tool to assist in a migration to drupal I'd move today (after testing of course!).

[douggreen]

@Dave, are you suggesting that we simply improve the rendering of this form

http://example.com/civicrm/contribute/transact?reset=1&id=3

to accept multiple id's, such as:

http://example.com/civicrm/contribute/transact?reset=1&id=2+3

CRM/Contribute/Form has a lot of separate forms, and I'm not quite sure where to start.  Can you give me a hint?

[Donald Lobo]

you will have to modify the code in

CRM/Contribute/Form/Contribution/Main.php, function buildMembershipBlock

and the relevant postProcess logic associated with processing a membership. The code gets a bit hairy, so i suspect this is not a trivial fix

lobo

[Dave Greenberg]

(Moving this discussion back to the forum so others can participate etc.)

> You can also INCLUDE a contribution amounts section AND THEN specifiy
> "Separate Membership Payment" in the Membership Settings form for that
> contrib page. This   results in 2 transactions - one charge for the
> Membership fee, and one for any additional contribution.

1) you cannot have a $0 membership option, if a user were to select that
option, they would get an error for the reason specified in my last
email.  Additionally, i think, if you select this option then selecting
a membership cannot be optional.

2) there is no option to charge a membership fee on TOP of a donation.
Either you use the form ONLY for membership and that is what gets
charged, or you use it for contributions and membership fees are
deducted from it.  At the very least this isn't particularly clear, how
do i suggest some help text changes?

Additionally, it would seem logical to FORCE an increase to the minimum
contribution level required for the selected membership rather than
returning an error.

[Dave Greenberg]

Regarding $0 contributions / membership fees - I believe we made a fix in 1.9 to check whether a transaction was $0 - and if so to just bypass the transaction processor call. If this isn't working for you - please recreate your case in test-drive mode on the 1.9 demo and post an issue for 2.0.

Regarding the way in which the "Separate Membership Payment" configuration is working - I did a quick test on 1.9 and I think the current validation logic is incorrect. If I select a Membership with a $100 fee and then also enter an additional Contribution of $15 - the current code returns a validation error (requires that the contribution be >= $100). However, if I enter a contribution of $115 and continue - it will generate 2 payments - $100 for the membership and $115 for the contribution for a total of $215. I've filed a bug fix for 2.0 for this here:

http://issues.civicrm.org/jira/browse/CRM-2503