Arvados

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 is let people who can see the group see that this person is "in" the group. Users want to be able to grant users access to a group at less than the "manage" level, and try to use this to do that (since it's a "can_read" permission).

Proposed change:

Remove both current checkboxes from the current membership pane. 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.

Underneath the pulldown+group name, there's a checkbox "☐ User is listed as a group member". Workbench creates/destroys the "GROUP can_read USER" link when this box is checked/unchecked, respectively.

When the pulldown transitions from None (no permission) to another value, JavaScript automatically checks membership checkbox. Conversely, when the pulldown transitions from another value to None, JavaScript automatically unchecks the membership checkbox. The effect is that users get the usual behavior with a single action: they give/revoke a user permission to a group, and the user is listed/delisted as a member at the same time. But admins who want finer control (or who have weird setups on the API end from other clients) will also be able to manage that.

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.