3

I've noticed recently on one site that I look after that a small number of records appear to have 'lost' their membership record. The site in question has organisational memberships and individuals have membership by dint pf their relationship. What I've seen is that while the individuals involved continue to show their membership, the related org record is showing no membership record. Invariably there is an org record in the trash which has the membership record associated with it. So I've got a little digging to do to understand why the org record with the membership is getting deleted, while a duplicate with no membership remains.

Odd behaviour with merging records may be part of the issue: if I recover the deleted record I then have two 'duplicate' records, one with a membership and one without. If I merge the record with the membership into the other one, and ensure that the checkbox is ticked to move the memberships, I end up with a single record with no membership. If I flip the two records and then merge, I end up with one record with a membership, which is what I want. Why, when I have explicitly ticked to move the membership record, is it not getting moved? This strikes me as highly dangerous behaviour - at the very least I would expect to see a large red alert to warn me that I was about to delete a record with a membership record that isn't being transferred to the merge result. Unless it's a bug?

I note that there is also an additional checkbox when merging, to "add a new membership". Do I need to check this as well in order for the membership to be moved, even though I'm not adding a new membership but moving an existing one?

  • 1
    Sounds like a bug - if you tick the box to move the membership, it should be moved. Could you log in lab.civicrm.org/dev/core/issues? What version are you seeing this on? – Aidan Jan 3 at 13:24
  • This is on version 5.8.2, but I've noted it previously to updating to 5.8.2 on this same site. I'll log an issue, thanks. – Graham Jan 3 at 13:46
  • 1
    Duly logged at lab.civicrm.org/dev/core/issues/631 – Graham Jan 3 at 13:51
3

I looked into the code and seems like you need to enable the add new checkbox to move the membership to the newer contact.

Add New stands for adding a new membership on the main contact from the duplicate contact.

Case when add new is not needed:

This is not needed when both the contacts have a membership of same type and they need to be merged between the two contacts. For eg.

  • Contact A has a membership of type 1 with start date = 1/1/2018.
  • Contact B has a membership of type 1 with start date = 2/2/2018.

Now, when contact A is merged to contact B, the merge membership is done and all the field values of A membership is copied on to B. Here, no new membership need to be created. Hence, add new should not be checked.

But, in your case, as the membership on the main contact is not present and need to be "added" from the duplicate contact - we need to select the add new checkbox on the merge screen.

Agree it should be documented as I don't see it anywhere on docs.civi.

  • That's really helpful clarification, thanks. My reading was that the default of 'move memberships' meant that any membership linked to contact A would be moved to contact B, and that I would only need to tick the 'add new' checkbox if contact B already had a membership and I didn't want the moved one and the existing one to be merged but rather kept distinct. Clearly what's there is not sufficiently obvious and some on-screen help and additional documentation would be valuable. – Graham Jan 7 at 12:03
  • Revisiting this. I find that if I merge two records where the duplicate (contact A) has a membership and the target (contact B) has none, and I don't tick the 'add new' checkbox (but all other options are ticked), this creates an illogical result: the resulting contact has the related contribution record (memberships are paid in my use case), but the membership record stays with contact A which gets deleted, giving me a deleted contact with a live membership, which is nonsensical. I would argue that a membership and its related contribution record should not get split up like this. It's crazy! – Graham Jan 27 at 16:11
2

We have also experienced this bug, which appears to be longstanding.

The behaviour described is opposite of what happens when merging by checking the box "Move related..." contributions, activities, groups, etc. so it would be very confusing for users for this to be the case. I believe it is a bug, not expected behaviour. The end result is losing memberships (into the trash), which is a big deal for membership based orgs. We have already had a few members pay for new memberships when it turns out they were already members.

It is also not consistent with how the "add new" button works in other cases. I think the logical understanding of "add new" in this context is that it would add a second membership if each contact already had one membership. Also note that the red / green / yellow colour coding of merge conflicts shows memberships as yellow in this case, when if there was a conflict and a membership was going to be sent to the trash, it should definitely appear red.

I've reproduced this on demo. Steps are: 1) Create two contacts, the second one with a membership. 2) Merge the two contacts with the default options (Move related... memberships selected)

Expected result: One contact with a membership, a contact with no membership in the trash. Result: One contact with no membership, a contact with a membership in the trash.

Note that this only happens if the duplicate contact has the membership (as there is no membership to move if the original contact, the contact that is being merged into, has the membership).

  • Also note that the docs indicate that: "Yellow indicates a row where the default option is a tick in the check-box which means the data from the duplicate will be added to the data already in the original record. This applies to tags, groups and activity data (including event attendance, contributions, etc.). If you untick the check-box the data belonging to the duplicate will be lost." This line is yellow, but the membership is not being added as indicated. docs.civicrm.org/user/en/latest/common-workflows/… – Lars SG Feb 1 at 16:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.