Answers.Body: <p>Just sharing that we have developed and released a CiviCRM extension which solves this problem, see <a href="https://github.com/agileware/au.com.agileware.membershiprelationshiptypeeditor" rel="noreferrer">https://github.com/agileware/au.com.agileware.membershiprelationshiptypeeditor</a></p>
  
  <p>Membership Relationship Type Editor for CiviCRM - edit existing Relationship Types and re-calculate inherited memberships</p>
  
  <p>We hope this is useful to people using CiviCRM.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-06-26T07:46:44.970Z
Answers.LastActivityDate: 2019-06-26T07:46:44.970Z
Answers.UserDisplayName: Justin Freeman - Agileware
Answers.Body: <p>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 <code>civicrm_membership_type</code> table by adding the relevant <code>relationship_type_id</code> and <code>relationship_direct</code> values, and then they would probably need to run a script to update any records that were received before this change. </p>
  
  <p>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).</p>
  
  <p>Hope this helps! </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-05T17:28:32.020Z
Answers.LastActivityDate: 2016-09-05T17:28:32.020Z
Answers.UserDisplayName: Tamar Meir - Cividesk
Body: <p>We have household memberships set up for the household members to inherit from the household.</p>
  
  <p>We also limit the number of memberships per household (currently set to 4).</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Has anyone figured out a way to get this done in a reasonably painless way.</p>
  
  <p>Thanks.</p>
  
Tags: <civimember><relationships><auto-renew>
Title: Need to change membership inheritance
ThreadText: # Need to change membership inheritance
  
  (Asked by: username_0 on 2016-08-21)
  
  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.
  
  **Tags:** civimember, relationships, auto-renew
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2019-06-26. Score: 6
  
  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 by username_2 on 2016-09-05. Score: 1
  
  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!
  
  
  ---
  
  