Story #15372

Updated by Tom Morris about 2 years ago

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 apparently working as designed, but is inconsistent with user expectations. Part of the existing behavior may be due reported to implementation details where projects are a form of group, but that isn't something that users are (or should be) aware of.

Here's a sketch of how I think the model should work:

* Groups have the following types of relationships:
** Viewer - users who have permission to see that the group exists and know its name, but not its membership. It's arguably desirable that they
be able to see the owner or some other point of contact, but I think a blinded "contact the owner" or "request membership" feature might be a better way to connect people.
** Viewer+ - users who can see the members (and, separately, administrators?) of a group. We may be able to bundle this with Viewer to simplify the model.
** Administrator - users who can edit add/remove group members, change the group name or description. Administrators aren't granted access to the objects shared with the group unless they are also a member (and they can, of course, trivially add themselves, but that creates an audit trail)
** Member - users who belong to the group
consistent between Workbench 1 and are granted the same permissions that the group has. Perhaps in the future this could be extended to groups as well so that you could have nested groups. Members can't necessarily see the membership list, but they can see the name of the group. Group membership does *not* convey any privileges on the group itself other than being able to see its name.
** Shared objects - objects which are shared with the group members on either a read-only, read/write, or manage basis. All group members have the same access to the object and it's children ie access privileges are *not* tailored on a member by member basis.

*Special cases:
** "all users" group - users will be able to see the name of the group by virtue of their membership in it, but won't be able to see the full list unless they also have Viewer+ privileges
** groups which are secret from their members (ie the admin's "Losers" group) - this model doesn't currently support this, but could be modified by removing member's default access to the names of projects that they are members of and granting this separately (one mechanism would be to share the group with itself, granting that access to its members)
Workbench 2.