Story #15372

Updated by Lucas Di Pentima almost 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 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 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)

h3. Implementation (Taken from #note-19)

|_. Group permission type |_. detail |_. current |_. future |
| (non-group target) | target is visible | can_read | can_read |
| (Project) viewer | project+children+grandchildren are visible | can_read | can_read |
| (Project) collaborator| project+children+grandchildren are writable | can_write | can_write |
| Viewer | group is visible | (n/a) | can_read |
| Viewer+ | group membership list is visible (implies viewer) | (n/a) | can_list_members |
| Member | permissions on other objects via group (implies viewer, but not viewer+) | (n/a) | can_use_permissions |
| Member+ | permissions on other objects via group (implies viewer+) | (n/a) | can_use_permissions + can_list_members |
| Administrator | can add/remove members and viewers (implies member and viewer+) | can_manage→, ←can_read | can_use_permissions + can_manage |
| Administrator- | can add/remove members and viewers (without implying member) | (n/a) | can_manage |

* A "role" group's UUID cannot be used as an owner_uuid (IOW a non-project group can't have children)
* A "project" group's UUID cannot be used as the tail_uuid of a permission link
* A user UUID can be a target of a can_use_permission link -- this allows access to all of the user's permissions and home project tree
* A group cannot have a group_class other than "role" or "project" (and group_class cannot be null)
* A group can have a can_use_permissions link to another group; this graph is (still) traversed, so groups can be composed
* A can_list_members link permits its subject (tail_uuid) to read all can_use_permissions links from other users/groups to the same head_uuid, as well as the member users/groups themselves
* can_manage implies can_list_members

* Obviously, update the materialized view of permissions and the "readable_by" query
* Clients that (might) need to be updated: Workbench1, Workbench2, group-sync, login-sync, arv-mount (probably drop Workbench1's group admin feature entirely rather than update it)
* Existing "Administrator" permissions convert to "Member+"
* Existing group→user links (e.g., "all users" links) convert to "Member"
* Existing project-sharing links (including read-only sharing, and sharing with role groups) can be left alone
* Warn/error if a non-project group is used as any object's owner_uuid, or a project group is used as a permission link's tail_uuid
* Update use of "all users" links in user activation code