Need to change membership inheritance

Question

We have household memberships set up for the household members to inherit from the household.

We also limit the number of memberships per household (currently set to 4).

We did this because on import, any attempt at having the entire household inherit from one member resulted in multiple memberships (always 4). Not nice.

Now, after almost a year of use, we have an issue with credit card renewals if the member wants to auto renew. Despite the fact that the renewal email came from the household, the credit card company put the renewal on the household member whose credit card was used. The household and spouse did not inherit the membership.

I can't change the inheritance rules given that they can only be changed when the membership type is not in use. We have thousands of members and 8 membership types.

I can think of a couple of possible ways to accomplish this, none nice. Ranging from create a whole duplicate set of membership types and transitioning them manually when renewals come in (ugh, ugh) to exporting the entire membership table, changing all membership types to have a max of "0"(unlimited) members and allowing inheritance from any member of the household, to attempting to delete one membership level at a time and re-import those.

Has anyone figured out a way to get this done in a reasonably painless way.

Thanks.

Answer 1

Just sharing that we have developed and released a CiviCRM extension which solves this problem, see https://github.com/agileware/au.com.agileware.membershiprelationshiptypeeditor

Membership Relationship Type Editor for CiviCRM - edit existing Relationship Types and re-calculate inherited memberships

We hope this is useful to people using CiviCRM.

Answer 2

The way you pose of updating via the UI sounds like the best plan unless you have access to a programmer who can mess around in the database for you - if you do, they can update the civicrm_membership_type table by adding the relevant relationship_type_id and relationship_direct values, and then they would probably need to run a script to update any records that were received before this change.

Although a bit after the fact, it's not too late to change your process from recording any financial related information on the household record to the an individual contact record precisely for this reason - when people pay on line, they typically log in as themselves, not their household, or, even if not logged in, payment information is entered for an individual, not a household, so this will prove to be a more consistent method with the added help of permissioned relationships (e.g. so that spouses/members of a household can see what financial obligations need to be paid for regardless of how they are logged in).

Hope this helps!