Uploaded image for project: 'CiviCRM'
  1. CiviCRM
  2. CRM-1657

CiviMember - Reimplement Extending Memberships to Related Contacts


    • Type: Bug
    • Status: Done/Fixed
    • Priority: Major
    • Resolution: Fixed/Completed
    • Affects Version/s: 1.7
    • Fix Version/s: 1.8, 2.0
    • Component/s: CiviMember
    • Labels:


      The prior approach for handling Membershp Types which are "extended" to related contacts needs to be re-worked so both contact "views" and searches return all expected members. In order to do this consistently and avoid horrendously complex queries - we need to change the code so that it actually creates/updates civicrm_membership records for related contacts.

      1. Create membership: modify code to check if membership_type has a relationship_type_id. If so, check for related contacts (active relationships) based on this relationship type and create memberships for them as well.

      2. Update membership - same as above (check for and modify membership properties for any applicable related contacts

      3. Create relationship: modify code to check if CiviMember componnent is enabled, if the either contact in the new relationship has an active membership whose membership type is extended by that relationship type. If so, create membership for related contact (clone properties of existing membership).

      4. Update relationship: same as 3

      5. We can then revert (back out ) the code that was done for 1645 to show "phantom" related memberships under contact/view membership tab. We won't need this as there will be "real" membership records. Also, no further changes s/b needed for search queries.

      The logic for determining whether Memberships are automatically granted to "related" contacts based on a relationship directionality are as follows:

      1. In general, a membership type extends to related contacts for a specific relationship direction (i.e a_b or b_a) as stored in membership_type.relationship_direction

      2. IF a relationship type has the same value for name_a_b and name_b_a, then the membership type is "extended" for both directions. This rule covers implicitly bi-directional relationship types like Spouse<>Spouse, Sibling<>Sibling

      EXAMPLE: User wants to create a "Household" membership type where the Household contact record has the "owner" membership. Individual contacts who are "members of that household" are granted membership records with owner_id set to the Household. The data representation of this is:

      membership.relationship_type_id = 7
      membership.relationship_direction = b_a

      When this membership type is inserted for a Household contact, we create "child" memberships for all Household Members. This does NOT happen in reverse for this membership type (e.g. if an Individual contact who is a member of Household signs up for this membership, no additional memberships are granted).

        • NOTE: The relationship_type drop-down options on Membership Type form need to be extended to include the name_b_a values (excluding dupes). Currently only a_b name are shown.




            • Assignee:
              kiran.jagtap Kiran Jagtap
              dgg David Greenberg
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: