Manually adding/removing contact in CiviCRM group results in inconsistent state

[twomice]

I'm observing this behavior under CiviCRM 5.19.2, Joomla 3.19.13, version 2.2 of this extension:

Summary:

The general impression is that in the first attempt to add (or remove) a CiviCRM contact in a CiviCRM group, that add/remove action fails silently, while the Jooma user group is updated as expected (thus we have bad behavior in CiviCRM and inconsistent state between Joomla and CiviCRM). Then, on the second attempt to add (or remove) that contact in the CiviCRM group, the add/remove action succeeds, the Joomla user group is still correct as expected, and all is well.

Details:

• Inspect rules at /administrator/index.php?option=com_civigroupsync&view=synchronizationrules and ensure there's a sync rule for Joomla group named "JGroup" and CiviCRM group named "CiviGroup".
• In civicrm, find a contact who has an associated Joomla user.
• Observe that this contact is not a member of the CiviGroup group, and that the associated Joomla user is not added to the JGroup user group.
• Navigate to this contact's Groups tab, add the contact to the CiviGroup group.
• Observe the success message, "Contact has been added to the 'CiviGroup' group", as expected.
• Observe that the 'CiviGroup' group is now listed in the contact's Past Groups listing. This is not the unexpected behavior. (Expected behavior is that the group should appear in the contact's "Regular Groups" listing.) Reload as much as you like; it's really listed as a Past Group.
• Edit the associated Joomla user, navigate to the "Assigned User Groups" tab, and observe that the user is added to the 'JGroup' group. This is inconsistent with the CiviCRM group status. (Consistent would be that the user doesn't have the 'JGroup' group, because the contact is not currently added to the CiviCRM group.)
• In the Groups tab of the CiviCRM contact, click the "Rejoin" link for the 'CiviGroup' group. Observe that the group is moved to the contact's "Regular Groups" listing (as expected); and in Joomla, observe that the Joomla user now has the 'JGroup' group (as expected).

Similar behavior can be seen when removing a contact from a CiviCRM group and then re-adding them with the "Rejoin" link.

Best guess at the cause:

Looking into the code, it seems that there's a feedback loop happening here.

1. CiviCRM GroupContact record is changed, triggering an update of the Joomla user's group memberships.
2. This update of the Joomla user's group memberships then triggers an update to all GroupContact records for the CiviCRM contact; in here somewhere, the CiviCRM contact is removed from the CiviCRM group.

Suggested solution and PR forthcoming:

I think we could fix this by refusing to update the same person/group membership (where "person" means that person who is a certain Joomla user and a certain CiviCRM contact) twice in the same PHP run. I've put this in place already on my site, to good effect, at least so far.

Hopefully approach this isn't overly naive: I mean, is there a conceivable use case for adding a contact to a group and then removing them in the same motion? Could some chained API situation lead to that? If so, this approach might again leave us in an inconsistent state.

[twomice]

This issue is referenced in #12, which explains the deeper issue, of which this ticket is just one example.

[lcdservices]

@twomice sorry I sat on this so long. I finally dug into the issue, and review your PR. I think you were on the right path, but the issue is a bit different. In my test, what I found was that in the civi post hook, when we add/remove someone from the Joomla user group, it triggers the onUserAfterSave hook, which in turn might attempt to add someone to a Civi group and trigger the post hook. I'm actually surprised there weren't scenarios where it got stuck in a loop. But that race-type condition seems to be what caused the inconsistencies.

After banging my head for a while, I found the best way to cut the loop short was to add some sanity check conditions in the onUserAfterSave hook. I've pushed up a patch to the master branch. Can you apply and test it? I'll push a release out once I hear from you.

[twomice]

Thanks @lcdservices I've got this scheduled for this week.

[joshgowans]

Commenting here as opposed to #12 because this issue is more consistent with what I'm experiencing. I've been testing this on a few instances of Joomla 3.9.21 and CiviCRM 5.28.3 and 5.29.1. I've attempted using CiviCRM smart groups as well as manual groups + CiviRules to move contacts in and out of the "sync" group. I've attempted with version 2.2 and master of this extension.

The result is the same in all cases. What I experience is:

• Contacts are successfully added to the "CiviGroup", be it based on smart group criteria, CiviRules criteria or manual addition.
• 1 contact from the "CiviGroup" is added as a user to the correspondencing "JoomlaGroup".
• In CiviCRM, adding the same contacts to "CiviGroup" results in "0 contacts added to group, # contacts were already in group". However, each time this is done, exactly 1 user will be added to the corresponding "JoomlaGroup".

Video screen grab demonstrates an attempt to add 4 contacts to the "CiviGoup", yet only 1 syncs to the "JoomlaGroup".

Additional things I've noticed:

• Re-adding a contact to the "CiviGroup" from the contact details screen will successfully add that specific user to the corresponding "JoomlaGroup".
• Manually removing all contacts from the "CiviGroup" results in only the last added user in the "JoomlaGroup" being removed. All other previously added users remain in the "JoomlaGroup".
• Subsequently re-adding all contacts to the "CiviGroup" from which they were previously removed will add only the last user that was added previously to the "JoomlaGroup".
• Manually removing users from the "JoomlaGroup" does not remove contacts from the "CiviGroup".