Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 1.7
-
Component/s: CiviMember
-
Labels:None
Description
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.
Attachments
Activity
Following issues found (testing w/ rev 8849):
1. Update relationship action erroneously removes other existing related memberships. To recreate:
- Create membership_type w/ relationship_type = Household Member is (rel type id = 7, b_a)
- Pick a household w/ several members (cid = 42 for example) and add membership for the household
- you will now have 4 new memberships (using cid 42) - the household and 3 household members
- Go to Relationships tab for the household, and Edit the "Head of Household" relationship (with cid 23). Change it to "Household Member"
Expected result:
There should now be one more new membership (for cid 23) for a total of 5 (the household + 4 members)
Actual result:
The 3 other Household Member's memberships are deleted. Only the original Household membership and the added membership for cid 23 are present.
NOTE: When I updated the Household's Membership record, it correctly re-inserted membership for the other 3 household members. Also, adding a new relationship w/ type = "Household Member Is" does the right thing.
2. Membership Selector rows: "Owned" memberships are READ-ONLY and should NOT have an Edit link in the row actions. They should have a "View" action however.
- In search results, remove all actions except "View"
- In contact/view Memberships tab - add "View"
3. Possible CiviMember Dashboard (summary query) bug:
My 5 "Household Members" all have Start Date of Jan 1 2007. However, the table cell for this membership type for "2007-New/Renew (YTD)" shows 0. Should be 5. If I do an explicit search for membership of this type w/ start date from Jan 1 2007, I do get the 5 members. ??? (This "case" is also shown on attached screenshot).
Shows selector action problem and summary count problem described in my testing report.
I posted an issue (CRM-1687) but I thought I would make a mention of it here as this seems to be where related issues are being discussed:
When creating a membership type with the 'relationship type' set to "Household member is", membership is granted to any individual who is listed as a "Household member of" but not to the individual listed as "Head of household for" the member household. The head of the household would presumably be the most important individual to have recorded as a member.
I don't believe that a similar extension would be desired in any of the other cases.
fixed
changes committed to 1.7 branch (-r 8880)
Make the issue unverified for 1.8.
Assigning to Yashodha for 1.8 verification.
1. I recreated dgg's issue of changing "head of household" -> "household member" and one membership got dropped
2. if a relationship has expired (i.e. end date is before today), we should also remove membership. This in general is much harder, but we can at least take care of it when we save one speciic relationship and see if its "past"
Manish - When you're fixing lobo's items 1 and 2 above, please run a test w/ UpdateMembershipRecord.php command line script and verify that it handles the following:
- If "direct" membership status needs to be updated, it should also update status on "related" membership records.
- It should NOT send reminder email to membership records where owner_membership_id is NOT NULL (i.e. don't "remind" related members - only direct members)
- For "related" memberships (owner_membership_id NOT NULL), It should check for expired relationship with "owner" - and delete related membership if relationship is expired. NOTE: If this is too complicated, we can push this item to 2.0. If you do that, please create a separate 2.0 issue for it.
Lobo issues:
==========
1. I recreated dgg's issue of changing "head of household" -> "household member" and one membership got dropped
=> Can not reproduce
2. if a relationship has expired (i.e. end date is before today), we should also remove membership. This in general is much harder, but we can at least take care of it when we save one speciic relationship and see if its "past"
=> fixed
DGG issues:
==========
1. If "direct" membership status needs to be updated, it should also update status on "related" membership records.
=> fixed
2. It should NOT send reminder email to membership records where owner_membership_id is NOT NULL (i.e. don't "remind" related members - only direct members)
=> fixed
3. For "related" memberships (owner_membership_id NOT NULL), It should check for expired relationship with "owner" - and delete related membership if relationship is expired. NOTE: If this is too complicated, we can push this item to 2.0. If you do that, please create a separate 2.0 issue for it
=>fixed
all changes have been committed to 1.8 branch
As of r10304 tested the cases mentioned in the last 2 comments and all is working as expected, including expired relationships etc.
Verify for 2.0
Consider the scenario :
1. Household has 3 members.
2. Create membership type where
membership.relationship_type_id = 7
membership.relationship_direction = b_a
1. Wrong owner_membership_id is stored if there are more than 1 members for a household.
2. We delete membership record when an relationship expires, but a new membership record is created. Need to fix this.
3. When we run " UpdateMembershipRecord.php " by changing system date < relationship end date . We get two entries for same contact in membership table.
fixed in r13023
assigning for 2.0 verification
Tested and verified for 2.0 r-13074
Tested and Confirmed for 2.1 ( r - 16513 )
We have fixed this issue. Transferring it to dgg so that he can test and resolve it.