CiviCRM Community Forums (archive)

Hi all,

We've made a series of modifications to how Memberships are handled to add additional functionality, and responses to them seem to be positive when describing them at meetups @ events like DrupalCon.  What I'm curious to know is, is Core interested in having us contribute these changes, and if so, what release/timeframe would they go in?  We'd like to contribute, but those looking to manage our devs need to have information about the schedule of the release they'd be contributing to.

The changes are basically that we have contacts buy individual memberships with a fixed length (1 year, but length doesn't matter).  Each new year, they buy a new membership (new record), instead of renewing.  We do this so that we can track various things:
- Each membership can have a payment associated with it (renewing an existing m'ship with an existing payment makes this difficult currently)
- We often have members who lapse certain years.. this allows us to track that a person was, say, a member in 2014 and 2011, but not 2012 and 2013

For the most part, the system allows this, but certain things have to be overridden or updated.  Some examples:
- Join/Renew workflows have to override the base logic of renewing an existing membership record, so that a new one is always created
- Prompts to staff indicating that they should renew an existing membership instead of creating a new one have been removed
- Reports and search logic have to be optimized (few real changes, just more optimizations so that, say, 500,000 records aren't pulled when only 10,000 are needed)
- The job which updates membership statuses at year end needs an update

Looking forward to your feedback!

Yeah, on re-reading, I think I was unclear on a couple of points 

To illustrate the difference, I think the example I need to use is someone with *multiple* lapsed years.  Let's say they were active in 2009, 2010, 2012, and 2014.  That's fairly common among our member base.

With the base Civi functionality, the final record would show 4 payments, a Join Date of 2009, a Start Date of 1/1/2014 and End Date of 12/31/2014.

The problems we had with that are the following:
- It's a bit tricky to figure out which payments are for which years of membership.  A person can manually figure it out for the most part, but it becomes difficult in some cases because people can buy next year's membership this year.. so the date of payment does not necessarily indicate the year of the membership.
- The data only tracks that a person joined in 2009, there was a gap (or multiple somewhere), and they're a 2014 member.  The details of being a 2010 and 2012 member (but not 2011 or 2013) are mostly lost, so when we try to report on trends in previous years' membership we wouldn't have the data to do so.

Our solution results in 4 memberships (from 1/1 to 12/31 on 2009, 2010, 2012, and 2014), each with a payment tied directly to it.. so if, for instance, someone bought the 2012 membership on 12/10/2011, we can easily know that.  We can also report easily on membership trends over the years this way.  It also enables reports/queries like, "Who re-joined as a member this year who was lapsed the two years before that?", which are a bit iffy with the base functionality if there are multiple lapses.

So basically, my thought is that anyone in an organization that allows members to lapse will probably experience the same problems we have, and they might appreciate the changes (and some have expressed that they would).  However, I also understand that without some sort of transitional idea it could be a fairly big change for people who have adapted to the current system and find it to suffice.  I have no idea whether the amount of people in the former camp is comparable to the amount of people in the latter, but I figured you guys might have some idea, or at least know how to find out 

As for the extension, I floated the idea to the devs and they're a bit skeptical that it might work, as they're not sure they can hijack certain processes (such as membership renewal and extension of the end date in the registration workflow) by using extensions.  Do you think it's possible?

As for the report optimizations, I know we've contributed the ones that we think are universal so far and plan to continue.

One way to flush out if others would be interested in this approach would be to put up a blog post describing what you've done and the benefits (ideally including some of the reporting outputs). We'll tweet the post and hopefully we'll get some feedback from others in the community.

Not sure if your devs had checkout out the civicrm_membership_log table which does contain a record for each renewal action.

Separately, my initial guess is that these changes could be implemented as an extension given the large number of hooks available these days. AND if there's was a process that can't be "hijacked" yet - we would be quite open to putting in a core change to facilitate customization of that process.

Dave, thanks for the advice.. I'll put together a blog post describing our changes, and see if we can get a discussion going.

Pete, our memberships are yearly, so luckily we don't have quite the clutter that we'd have with monthly memberships (which I imagine would certainly require some extra UI and logic to make manageable).  We do have over 250,000 records however (about 10,000 members a year, going back >20 years), and once we made some tweaks to certain queries to limit results returned from the DB, it hasn't been a strain on the server.  Not sure whether one could limit the logic by membership type, however.. I know some of the hooks can be restrictive in the information passed, although if what you need isn't it does sound like you can make the case to have it passed.

Robyn, what you described will work great in our solution (in fact, those are two of the reasons we implemented it).  If you'd like to talk about helping us turn our modifications into an extension you can use, just PM me your contact information.

Lola - I think extending the membership_log table to provide more complete info about each membership period makes a lot of sense. Any chance FreeForm would be interested in pushing that forward?

Hi all,

A more detailed blog post has been posted at: https://civicrm.org/blogs/roberttdev/improving-civis-membership-history

Looking forward to discussing with all those who would like to use this, and turning it into an extension.

Dont think so. You might need to take ownership and try to move it along

lobo