CiviCRM Community Forums (archive)

Keen to see a response to this too, as it just seems to have hit one of our clients, who unbeknown to me, had changed a membership type to Lifetime and are not reporting problems getting people to renew for another membership type

Chiming in to say we have a similar problem, with 4.3.8.

The client has a lifelong membership set up, with a yearly membership as well. Users are trying to update their yearly membership but are receiving an error saying they have a lifelong membership.

I've advised them to try the workaround, but this obviously is not ideal. I took a look through Jira, but there wasn't anything pertinent there.

In the case of our client, the lifetime membership is not the primary membership. It's not related to a different organisation. They just happen to have a lifetime membership which gives them X priveleges, or features, or what have you.

The rolling, year-by-year membership is the one that the user pays for and where the client gets their income from.

If end users in your organisation can have two memberships that run concurrently, then you will need to create  a "dummy" organisation in CiviCRM and link one of the memberships to that dummy organisation.

That doesn't seem like a solution. Setting up the lifetime membership to be listed under another organisation isn't a solution, it's a workaround, and not an ideal one.

Aside from the idea that you can only have one membership per organisation (which doesn't make sense), I don't understand why the user can't have two different memberships if one of them is lifelong, and of a different type anyway?

I guess my big block is that you can only have one membership per organisation: that doesn't make any form of sense to me. (Think of bank accounts, for example: one organisation, two types of bank accounts (savings/current). Imagine the chaos that would ensue if you could only have one account with one bank.)

Unfortuantely, Circle Interactive already dedicates a great deal of time, money and resources to Civi and we can't afford to take on more work to fix something that probably should never have been "broken" in the first place.

Perhaps we can discuss how this should work instead - obviously not having this up-sell feature is no good, but having it implemented in the way it's currently implemented is also no good. I'd suggest the option to "transfer" a membership or similar, as a very basic starting point, rather than only allowing a single membership per organisation - but that's a very basic idea thought up while I'm distracted by working on, you guessed it, a Civi problem for another client. :-)

Sophie - The behavior limiting memberships to 'one per organization' has been in place since v3.4 (Feb/Mar 2011), and as Joanne indicated is directly related to the implementation of the membership upsell functionality.

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

The convention of creating multiple organization contact records to handle different classes or sets of memberships can potentially be explained and implemented in a way that makes sense for many use cases (including 'national' vs. 'regional' memberships, creating a 'Lifetime Club for XYZ Org' organization for your client, etc.).

That said, if based on your experience working w/ ciients' requirements, you feel that changes are needed in the existing behavior - I'm happy to discuss ideas for other ways to 'group' memberships into upsell "sets" (which is what the current membership organization linkage does). It may be possible to implement alternative behavior via an extension using a custom membership field or Maybe have Dave J ping me to think this through?

Sophie, I have raised this before as the membership organisation is not helpful in a number of contexts. The branch / region is one where we have difficulties - because you have the situation of needing to have n* the number of regions / branches you have - e.g. an Individual / Family / Waged / Unwaged / Lifetime * 30 branches = 150 membership types. Obviously it's not possible to have too many types on a membership page.

Generally there are 2 types of functionality here
1) upsell sets (which is how the currently implementation functions to my mind)
2) Membership organisations. We deal with membership organisation functionality by adding custom contact reference fields to the memberships to the organisation.

I would probably recommend replacing the contact_id field in membership types with an fk to an upsell set in a table for the first purpose. However, you can achieve much the same thing by imagining that is what it is.

On the second purposed -  I would dearly love to have the membership_contact_id field retained as a field on the civicrm_membership record itself - with the membership type holding a list of organisations it can be used with -  but that's a fairly big change & we can muddle around it with custom fields.