Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I have a scenario that involves users getting assigned to a pair of Drupal roles, and then group memberships for several groups, all controlled through OG. Users can either be in a basic group with very limited permissions or a moderator level group with a larger set of permissions. Everything is fine for the lower level users, the Drupal role gets assigned, and they also get assigned to all their groups. However, the moderators do not get assigned the OG group memberships unless I remove the Administer Organic groups permission from the second role.
Users in the moderator role get assigned to both the basic role, and the role with more permissions (which needs to provide Administer Organic groups). They should also be assigned to several groups in addition to the Drupal roles. Walking through the debugging messages, LDAP Authorize OG finds the list of groups correctly, but the users do not end up as members of the groups, it just seems to fail quietly. If I remove the offending permission, all group membership assignments happen properly.
I'm not completely sure this is an LDAP module issue, but since the group assignments should be handled here I'm opening the ticket here. If anyone can suggest steps to determine concretely if this is an OG or LDAP issue I'd be happy to do my part.
| Comment | File | Size | Author |
|---|
Comments
Comment #1
johnbarclay CreditAttribution: johnbarclay commentedWhat version of OG are you using?
Comment #2
acrosmanSorry, OG 7.x-2.3, and here's the LDAP Config file I created for a previous issue.
Comment #2.0
acrosmanfixed typo
Comment #3
micahw156This is pretty similar to #2144637: LDAP Authorization 7.x-2.0-beta6 and OG 7.x-2.4 - roles only assigned on initial login.
Comment #4
alberghini CreditAttribution: alberghini commentedI just encountered this error today. I set up a fresh install of Drupal 7.26 with LDAP 7.x-2.0-beta8 and Organic Groups 7.x-2.6.
I set up the LDAP server, roles and OG groups. LDAP Authorization - Drupal Roles works fine.
LDAP Authorization - OG appears to work fine in testing, but will not actually add some users to the OG groups on login.
A user with Administer Organic groups permissions is not added to the groups.
A user without the permission is added correctly to the Organic Groups.
Comment #5
johnbarclay CreditAttribution: johnbarclay commentedComment #6
johnbarclay CreditAttribution: johnbarclay commentedComment #7
potassiumchloride CreditAttribution: potassiumchloride commentedWe are experiencing this issue as well, with LDAP Authorization - Drupal Roles enabled but with LDAP Authorization - OG NOT enabled.
We haven't stored groups in LDAP that map to organic groups so we just use LDAP Authorization - Drupal roles. This has consistently worked for us in the past.
Now, with 7.x - 2.0-beta11 a user with a Drupal role that gives "Administer Organic Groups permissions" has his/her organic group membership stripped upon login.
This issue appears to be related to #2188147 and #2148047.
Comment #8
Robert_W CreditAttribution: Robert_W commentedI can confirm this issue with LDAP 7.x 2.0-beta11.
Comment #9
potassiumchloride CreditAttribution: potassiumchloride commentedComment #10
robbertnl CreditAttribution: robbertnl at Wowww commentedLooks like the account object is not fully loaded. I made a quickfix which might help making a final fix.
Comment #11
micahw156Setting version back to dev branch. This affects all existing beta releases for this branch, and is not specific to beta11.
Comment #12
micahw156@robbertnl,
I can understand why you'd want to add this, but I don't think adding user_load() here will work. It's more likely that $account is incomplete because login is still in process, and from reading the rest of this function, that change might even cause wrong information to be written back to the LDAP directory if two-way synchronization is enabled.
I could be wrong, and I haven't dug through the code myself yet, but don't think the actual problem is in ldap_user. It's probably in either the ldap_authorization or ldap_authorization_og module.
Comment #13
grahlHi
So I really wanted to get these old issues out of the way and have tried reproducing this, which I was able to in the test form and in general. I've just committed a simplified version of ldap_authorization_og, which removes og1 support since it's unsupported and removes some static caching to make sure we don't have any side-effects.
The primary reported problem still exists and is a side-effect of og, I believe. The cause is that relevant groups reported back are 2 and 3 for member and admin. When revoke is enabled, ldap_authorization will in some (but not all) cases then consider group 2 not assigned 3 assigned, causing a revoke of 2 after a grant has taken place. This will cause the removal from the group entirely. I've tried to do revokes before grants to get around this but these functions can be called multiple times and then don't work deterministically.
What I've found to be a decent workaround is actually specifying the member AND the admin group as permissions:
One would expect the user to switch between admin and member in that case but as far as I can tell this does not happen and rights stay consistently on admin.
Therefore I believe we have a solution that works with OG, even though ldap_authorization_og is being very weird here.
If anybody still has issues with this workaround on latest dev, feel free to reopen this issue.
Thanks!
Comment #14
grahlThis broke a test, requires more work. Rolling back for now.
Comment #15
grahlIssue resolved, cache within the controller has been added back, workarounds described above still relevant.