manage permission doesn't work for group members?
From a customer:
When I share a project with a user and give her manage permissions she can see the sharing page in wb2 and open the sharing dialog in wb2 ... when i change this to write she cannot see and change the sharing anymore but still read and write within the project. I think this is the behavior which was expected in our current release.
Now I remove her as user, add a group where she is member of, and give it write permissions. She cannot see and change the sharing but can read and write within the project ... expected behavior ... when changing the permissions to manage, however nothing changes .... she still cannot see and change the sharing but read and write within the project. My expectation was that giving manage permission to a user directly or to a group with this user as member does not make any difference.
This behavior is reported to be consistent between Workbench 1 and Workbench 2.
#8 Updated by Peter Amstutz 2 months ago
I suspect this is working as designed.
It depends on the access that the user has to the group.
If the user has "write" access to the group, that means the user only gets "write" access to things that the group can "write" or "manage".
If the user has "manage" access to the group, then the user also gets "manage" access to things the group can manage.
If the user has "manage" access to the group, and the groups gets "write" access, then the user only gets "write" access.
As a feature, we may be missing a permission level where a user is able to manage things the group can manage, but not manage the group itself.
I think the expected behavior depends on what you mean by a user being a member of a group, which isn't quite clear in the description.
In this case the user should see sharing controls for the project. This is what Workbench1 does when you use the "add user to group" admin feature.
can_manage can_manage user --------------> group --------------> project
In this case the user should not see sharing controls for the project. This might happen if something other than the Workbench1 admin page is used to add the user→group permission link.
can_write can_manage user --------------> group --------------> project
#12 Updated by Tom Morris about 2 months ago
If I'm understanding it correctly, the current model seems wrong to me. I expect the rights to manage a group to be orthogonal to the rights that membership in a group grants me. The rights that I have to an object should be the union of my individual rights plus the rights of all groups of which I'm a member. Granting a group member manage access to the group itself, just so that they're able to exercise their right to manage objects shared with the group, allows them to change membership of the group, which seems highly undesirable.
Permissions should be based on group membership, not access to the group.