Back again

Noticed something new having resolved some of the (pilot error) problems that caused the previous incarnation of this issue #339698: OG User Roles permissions misbehaving. Unlike the previous issue, my test user no longer has admin privileges on the site outside the group.

The following is happening on my site.

Now, (i hadn't tried this before) when a fresh user with no administrator privileges (either at the OG group or site wide levels) views the "subscribers" link in the group details panel he/she sees three tabs (faces, list, add members)

On the list tab, the user is able to see and use the "create admin" or "remove admin" links on each other user (including admins). the non-admin user can promote him/herself to admin for the group and then perform group admin functions. Including "demoting" the current admins.

on the "add members" tab the fresh user without admin privileges can add new members.

When the user promotes him/herself, the configure user roles tab becomes visible when viewing the "subscribers" link on the group details panel.

When the user (or an admin) clicks the "remove admin" link on his/her name on the "list" tab, the admin role is removed visibly from both the list tab, and also the "configure roles" tab display. A listing of the user's roles at the sitewide level also shows that he/she lacks admin privilege at the site level. Thats the good news.

The bad news is that the "config user roles" tab is even visible and functional to a non-admin user. The user still retains user privileges within the group. I have checked the configure user roles tab as the actual admin and find that the user has no indicated admin roles that can be removed. I also checked the site wide roles for this user and there is also no admin role that can be manually removed.

Short version, within the group, the new user has latent admin capabilities, can elevate himself (officially) to admin, and retains the admin privileges after he/she or an admin removes them.

i have the clear cache function enabled and performed the necessary patch to enable it.

Ideas? How can I demote this user to normal (non-admin) status?

Is this a bug or something I'm just not understanding?

thanks.

Comments

somebodysysop’s picture

somebodysysop commented

The only permission that allows a user to see the group admin tabs is the "edit group content" permission. So, if a user has had the OG "create: admin" function removed, but still has this permission either group-limited, or site-wide, then he will still be able to edit the group.

A user can only see the "configure member roles" tab if he has permission via a role that's been assigned either manually or automatically, group-limited or sitewide. That's the first place I'd check.

OGUR does not give users permissions that have not been granted via a role, either group-limited or sitewide.

jackspiv’s picture

jackspiv commented
Status: Fixed » Active

SomebodySysop,

As usual, thankyou so much again. That was it.

I have been playing (working?) with this module now for a while and I had not yet stumbled on my really fundamental misunderstanding... as in messed up big time.

I thought that i needed to confer the "edit group content" permission on a sitewide basis so that it would be available for OGUR to control/restrict them within a group. I now understand that I only need to *MAKE* the role with the appropriate permissions... not actually *CONFER* this role on any users. OGUR will do that from within a group.

My new understanding is that

1) I need to restrict permissions (even for a group admin) to a minimal set sitewide
2) Create a group administrator role that has appropriate "within group" privileges.
3) Do not give anyone (except site admins) "group administrator role" permissions on a site wide basis
4) Group owners and admins can Use/Allow OGUR (the config user roles tab) to permit the "group administrator role" to be granted only within the local group.

Assigning an individual to a group administrator role site wide will actually give him/her (dunnhhh...) privileges sitewide in all groups. If the assignment is made from within the group using the "config user roles tab" then the role permissions remain local to the group.

I'm primarily describing my understanding for those who may find themselves similarly misunderstanding.

Does all this seem correct?

If so, I will look again at the readme and see where I took a "left turn". Maybe I can contribute some language like the above (if its right) as an "example" that might be clarifying.

This is an *AWESOME* module. I don't understand what usecase would allow an Organic Groups enabled site to function without this. Except perhaps the case where the site admin controlled every group on the site or where user roles are all sitewide roles like (registered site member, standard group member, premium group member). In that case, the site would be "Groups" enabled, but it would be controlled from a strictly hierarchical viewpoint. There would be nothing possible that would resemble 'Organic" or grassroots control or organization.

I think that this distinction and the path a developer needs to take to resolve it needs to be made clearer in some documentation paragraph that is shared perhaps in OGUR and in OG itself.

jackspiv’s picture

jackspiv commented
Status: Active » Fixed
somebodysysop’s picture

somebodysysop commented
Status: Active » Fixed

My new understanding is that

1) I need to restrict permissions (even for a group admin) to a minimal set sitewide
2) Create a group administrator role that has appropriate "within group" privileges.
3) Do not give anyone (except site admins) "group administrator role" permissions on a site wide basis
4) Group owners and admins can Use/Allow OGUR (the config user roles tab) to permit the "group administrator role" to be granted only within the local group.

Assigning an individual to a group administrator role site wide will actually give him/her (dunnhhh...) privileges sitewide in all groups. If the assignment is made from within the group using the "config user roles tab" then the role permissions remain local to the group.

Bingo! That's it exactly. Please feel free to contribute to the online documentation here: http://drupal.org/node/163565

Or, submit whatever you think should go into the README.txt file here. Can never have too much good documentation.

Thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.