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 creates a permission for "GROUP can_read USER"—the group is the tail, and the user is the head. This is almost never what users want. Rather, they want "USER can_read GROUP," so the user can read a group's projects, repositories, etc. without permission to 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.
This interface only creates permission links where the user being managed is the tail, and the group in this row is the head. It does not create any links where the group is the tail and the user is the head. These are rare enough that we can leave them at the 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.