Feature #18277
closed
Ability to make groups visible to all users
Description
Need to be able to share with groups without having full read access to the group.
Ideas:
New type of permission link that grants ability to see a group without traversing it- Config option to make all 'role' groups visible without traversing them
Option 1 would allow us to generalize the annoying special case of read access on users (unlike groups, can_read on a user implies seeing the user but not traversing them).
Option 2 is simpler. It does require introducing a special case to the permission checks.
From discussion on Nov 23:
Consensus to do the easier solution (option 2).
Proposal:
New configuration option RoleGroupsVisibleToAll
When enabled, all Users are permitted to see role groups and share things with them.
Default value true, based on feedback, this is how users generally expect the system to work. Does not prevent us from supporting the a complex multi-tenant case (using option 1) in the future -- config option can be turned off.
Will be implemented by adding making role groups a special case within ArvadosModel#readable_by.
Must have at least one non-anonymous, active user in the list of users passed to readable_by.
Updated by Peter Amstutz about 3 years ago
- Description updated (diff)
- Subject changed from Add config option (default off) to make all groups visible to all users to Ability to make groups visible to all users
Updated by Peter Amstutz about 3 years ago
- Target version set to 2021-12-08 sprint
Updated by Peter Amstutz about 3 years ago
- Target version changed from 2021-12-08 sprint to 2022-01-05 sprint
Updated by Tom Clegg about 3 years ago
18277-groups-visible-to-all @ b7fb5c4593dcc679f5343f0f55b3774a7bcfe499 -- developer-run-tests: #2838
Updated by Lucas Di Pentima about 3 years ago
Some comments re: b7fb5c4:
- In the "permission model" doc page, we might need to mention the particular case of role groups being included in list requests at "none" permission level.
- Somewhat related to this story: While looking at the documentation for potential spots that still need tweaking, I think I've found some traces of a currently not supported feature: the
asyncflag on thegroupsAPI:- API documentation mentions it along with the
async_permissions_update_intervalconfig knob. - Some test & config code is still existing about
API.AsyncPermissionsUpdateIntervaland its relationship with the previous point. - Group's controller and arvados model still have some code related the
asyncparameter, but it seems to me that we don't really do anything with it anymore.
- API documentation mentions it along with the
- The proposed new default behavior may cause user confusion on clusters with many role groups (wb2 suddenly offering many 10s of groups on the share dialog, for example). I wanted to mention this just in case it wasn't already discussed with our customers.
Updated by Tom Clegg about 3 years ago
- adds note to "permission model" doc page
Yes, I think we're expecting wb/wb2 to start offering long lists of groups. If this turns out to mean they need usability improvements like better search/sort, I think we'll just have to tackle that next and, if it's really bad, advise sites with lots of groups to leave this at false for now.
Added #18586 for the "async permissions" cleanup.
Updated by Tom Clegg about 3 years ago
- Status changed from In Progress to Resolved
Applied in changeset arvados-private:commit:arvados|7519cf2beb1d81ce578dd2ef0624d77b9588ce70.