Bug #15372

manage permission doesn't work for group members?

Added by Ward Vandewege 2 months ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assigned To:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
(Total: 0.00 h)
Story points:
-

Description

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.


Subtasks

Task #15392: ReviewNewLucas Di Pentima

History

#1 Updated by Ward Vandewege 2 months ago

  • Description updated (diff)

#2 Updated by Ward Vandewege 2 months ago

  • Description updated (diff)

#3 Updated by Tom Morris 2 months ago

  • Description updated (diff)
  • Project changed from Arvados Private to Arvados

#4 Updated by Tom Morris 2 months ago

  • Subject changed from manage permissions bug? to manage permission doesn't work for group members?

#5 Updated by Tom Morris 2 months ago

  • Target version changed from To Be Groomed to 2019-07-03 Sprint

#6 Updated by Tom Clegg 2 months ago

  • Assigned To set to Tom Clegg

#7 Updated by Peter Amstutz 2 months ago

  • Assigned To changed from Tom Clegg to Peter Amstutz

#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.

#9 Updated by Tom Clegg 2 months ago

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

Permissions are narrowed to the least powerful permission on the path.

#10 Updated by Peter Amstutz about 2 months ago

  • Status changed from New to In Progress

#11 Updated by Tom Morris about 2 months ago

  • Target version changed from 2019-07-03 Sprint to 2019-07-17 Sprint

To be investigated - does the group sync tool set things up the same way that workbench does?

#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.

#13 Updated by Tom Morris about 1 month ago

  • Target version changed from 2019-07-17 Sprint to To Be Groomed
  • Assigned To deleted (Peter Amstutz)
  • Status changed from In Progress to New

Also available in: Atom PDF