ldap authorization og: Alternating between assigning and revoking groups

I can confirm this issue. Our site has a lot of memberships and the module seems to have problems when you have over 225 lines in the configuration for OG, so it's not really feasible for us to double every assignment to also include a member roles assignment.

I'm marking this as major seeing how it's completely broken every other time someone logs in.

This is similar to #2144637: LDAP Authorization 7.x-2.0-beta6 and OG 7.x-2.4 - roles only assigned on initial login, but that issue does not discuss the problems assigning roles. I've experienced problems similar to both issues, but role assignment has worked for me at all. (I only get member, not any custom roles.)

I can confirm this issue. I've tried version 7.x-2.0-beta8 but after each logon the user is a member > not a member > a member > not a member ...

I found a not so nice workaround by disabeling "Revoke OG groups previously granted by LDAP Authorization but no longer valid." resulting in an out of sync AD security group vs OG group.

I am having the same problem. This problem really is a deal breaker for our company intranet. Would it be permissible to change this to critical?

I have had the same problem, the issue comes from having a mapping for users directly mapping to a role and with no member role. If this happens when ldap does a diff between drupal og group roles and the roles provided from the AD member role is set to remove it from the user and in the code there is a check to unregister user from that group if member role is present in revoke function.

if (in_array($authenticated_rid, $revoking_rids) || count($remaining_rids) == 0) {  // ungroup if only authenticated and anonymous role left
           $entity = og_ungroup($group_entity_type, $gid, 'user', $user->uid);

I think this can be removed, at least it works fine for me but needs to be tested in other configurations.

Attached patch.

I was having this problem, as well. I had an LDAP group mapping for normal group users, as well as an LDAP group mapping for group admins. When I mapped to a group admin user, every other time I logged in as that user, it would revoke, and then grant the group I assigned the user as an admin to.

I was able to solve it by explicitly mapping the normal group member role AND the admin role.
In other words, this presented the alternating revoke/grant problem:

LDAP_GROUP_USER|node:100:5
LDAP_GROUP_ADMIN|node:100:6

...while this fixed it:

LDAP_GROUP_USER|node:100:5
LDAP_GROUP_ADMIN|node:100:5
LDAP_GROUP_ADMIN|node:100:6

Where 5 is normal group user role and 6 is an admin role.

I've been running up against this issue as well the last day or two. I dug through and found a couple of calls to og_roles in the flow for normalizing the mappings that were coded to pull the roles for group 0 rather than the group specified in the mapping. This was resulting in the mapping normalizing to the wrong role IDs and in turn the expected authorization mapping used in the diff step did not include the role IDs for the actual groups roles. Since the actual groups roles weren't in the mapping they get revoked.

I changed the og_roles calls to use the actual groups ID and this has resolved it for me.

Note: On the 7.x-2.x branch the attribute query code seems to have changed slightly from beta8 so I also needed to add the member attr to the attributes needed list.

I tried the patch in #12 and unfortunately it did not solve the issue for me. I do agree, however, that setting the group id to 0 seems weird to me and might be a separate issue.

However, rerolling the patch from #6 gets me partially there, which is what I've included here.

I've tested the patch adding and removing member roles to users, and it adds/removes as expected.

Adding administrative members is fine. However, when I remove the administrative member role, the user still exists as a member of the group.

Ultimately, I agree with #9:

If the authenticated role ID is in $revoking_rids, than they should be removed from the group. It seems like the $authenticated_rid shouldn't be in the list of to be revoked in the first place, and this code would behave as it should.

Here's a patch for the og2Revokes method that removes the authenticated rid from the $revoking_rids if there are $remaining_rids for that group. In my testing, the adding/removing an authenticated role works, in addition to adding/removing an additional role without explicitly granting the authenticated role.

I was thinking that this type of check should happen in grantsAndRevokes() directly, but would require duplication of calling several og functions that are called directly in og2Revokes.

Anyone else using this patch?

Could this also be related to #2148047: Data loss: OG memberships are deleted when group member gets saved and/or #2321213-7: Rules integration bug - user added twice to same group?

Closing issue as outdated due to no further development on 7.x, if you feel this issue is still relevant and you are willing to work on a patch and/or debug the problem, please reopen.