LDAP Authorization. General cleanup for 7.x-2.0 [#1845358]

This is just a general thread for the 7.x-2.0 LDAP Authorization stuff. I ended up rewriting it a bit to clean up some performance issues and am working through the test coverage. Most of the changes are tied to ldap authorization and I'll get it up in the sandbox as soon as its functional.

I had a question on the mapping. Currently the id for mapping to og2 is: "group_entity_type:group id:role id"

Should it be extended to: "group_entity_type:group id:role id:membership type id" and role id and membership id be made optional and default to the defaults? I'm unclear how important og2 roles and membership types are.

Comments

Comment #1

crystal_alexandre_froger CreditAttribution: crystal_alexandre_froger commented 20 November 2012 at 06:36

Roles are important because it determines the permissions of users within a group - as amitaibu says, we can see an OG as a sub-site, with it's own roles & permissions.
Knowing that, we should definitely keep the roles in the mapping - however, they should be optional. In my opinion, the module should allow to simply add the users to a group as members, and let the site administrators take care of the other roles.
This would mean that it could be very convenient to have something like group_entity_type:group id for the mapping, and the roles are taken care of automatically in the background.

Comment #2

Renee S CreditAttribution: Renee S commented 21 November 2012 at 00:13

Having membership ID might be useful, but I'm not sure. We don't use it, but I believe the idea is that it's for providing services to different members of a group that isn't related to their role (ie: for assigning different "membership levels" like manager or editor per group to different people; and, asking for certain kinds of information from those different kinds of users on registration, sort of an OG advanced profile kit, as membership is fieldable). Membership type ID is also tied into rules, so different things can happen when different kinds of users are involved (ie: if group manager, send an email...)

However, I'm hard-pressed to think of a use-case where this info would be contained within an org's LDAP -- it seems to me to be fairly local information specific to each site/group. But I could be wrong, maybe some SSO functionality would want it.

Comment #3

johnbarclay CreditAttribution: johnbarclay commented 3 December 2012 at 14:35

I didn't get the membership type in, but committed the og authorization code to 7.x-2.x-dev. I decided to commit the new code directly to 7.x-2.x-dev since (1) I don't really have the energy to go through the forking process (2) it has pretty good test coverage and (3) ldap authorization og was broken in previous 7.x-2.x-dev.

Can you do some og 2.0 testing against the current 7.x-2.x-dev code? See http://drupal.org/node/1115704#comment-6804496

Comment #4

johnbarclay CreditAttribution: johnbarclay commented 5 December 2012 at 04:09

One of the simpletest was failing. It was trying to revoke the og member role when a user had other roles and was failing. What should be the behavior when a user has the member role and another role, and ldap authorization wants to revoke the member role, but not the other role?

Seems to me it should do nothing OR remove all roles and ungroup the account from that group. The latter seems more secure and a more expected behavior. We need to pick one and add it to the documentation/UI.

Comment #5

johnbarclay CreditAttribution: johnbarclay commented 5 December 2012 at 13:44

Of course the problem with the latter, is if ldap authorization is set to grant an admin role, but not a member role, it would never function. Seems like the rule needs work on a per group logic rather than per role.