Idea #9441
Updated by Brett Smith almost 8 years ago
The group memberships pane in the admin tab of a user page has a couple of immediate problems. * It's inscrutable to people who aren't already familiar with the Arvados permissions model at the API level. This was by design at the time, but now that more people are managing their own clusters, we need something friendlier. * The "group→user" checkbox only creates a permission for "GROUP can_read USER"—the group is the tail, and the user is the head. All this does This is let people who can see the group see that this person is "in" the group. almost never what users want. Users Rather, they want to be able to grant users access to "USER can_read GROUP," so the user can read a group at less than the "manage" level, and try group's projects, repositories, etc. without permission to use this to do that (since it's a "can_read" permission). write them. Proposed change: The group memberships pane does not include any checkboxes. Instead, it each lists each group, with a pulldown in front of each group's name (where the checkboxes appear now). Much like the Sharing tab for projects and collections, this pulldown has four options to represent the user's current access level for the group: Manage, Write, Read, and None. Admins change the user's access level to a group by selecting a different value from the puldown. Like the Sharing tab, this sends an AJAX request to make the appropriate permissions link. When "None" is selected, this means the user has no permission link to the group. When This interface only creates permission links where the permission selection for a user being managed is the tail, and the group transitions from None to another value, Workbench automatically creates the "GROUP can_read USER" permission in addition to this row is the new USER→GROUP permission. head. Having one without It does not create any links where the other group is the tail and the user is the head. These are rare enough that we can leave this to an API/CLI operation. Conversely, when them at the selection transitions from another value to None, Workbench automatically deletes any "GROUP can_read USER" permission found. API level for now. Ideally, when the pane is first rendered, it would be sorted by access level: first groups where the user currently has Manage permission, then Write, then Read, then None. Secondary sort on group name. If sorting on access level is too difficult, sorting on name alone is fine for a plan B. Remove any text on the page referring to the permissions checkboxes. You're not expected to need any replacement text. The new interface should be straightforward enough to use without explanation. Hopefully you can reuse code from the Sharing tab to render the pulldowns and respond to changes there. Feel free to refactor whatever's necessary to do that.