Bug #7453

[Workbench] User admin page includes a button to create new role groups

Added by Brett Smith about 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Radhika Chippada
Category:
Workbench
Target version:
Start date:
10/27/2015
Due date:
% Done:

100%

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

Description

Bug

When you create a new group in Workbench by using the "Create group" button on the Groups listing, you expect it to be listed in the group memberships pane of the user admin interface. It doesn't, because that pane filters for groups with group_class: role, and your newly-created group has nil role.

It should be easier to create groups to manage user access.

Fix

  • Remove the generic "Create Class" button from all listing pages. This is not the first time we've had trouble with these buttons; see also #6979. We'll just do away with them completely.
  • In the pane to manage a user's group memberships, add a button to create a new group with group_class: role. This button behaves like the button to create a new repository.
    • The button must pop up a modal to prompt the admin for a group name, and use that when creating the group.
    • If group creation fails, report that in the modal.
    • After group creation succeeds, the pane should be reloaded so the new role is included in the listing of groups the user can be added to.

Subtasks

Task #7659: Review branch: 7453-create-new-group-with-roleResolvedNico César


Related issues

Related to Arvados - Bug #6834: How to add users to a newly created group?Closed07/30/2015

Associated revisions

Revision 61c91fe0
Added by Radhika Chippada almost 4 years ago

closes #7453
Merge branch '7453-create-new-group-with-role'

History

#1 Updated by Brett Smith about 4 years ago

  • Target version set to Arvados Future Sprints

#2 Updated by Brett Smith about 4 years ago

  • Story points set to 1.0

Brett to write up Tom's proposed implementation.

#3 Updated by Brett Smith about 4 years ago

  • Subject changed from [Workbench] [Maybe] "Create group" button should set group_class: role to [Workbench] User admin page includes a button to create new role groups
  • Description updated (diff)

Per yesterday's discussion.

#4 Updated by Brett Smith about 4 years ago

  • Description updated (diff)

#5 Updated by Brett Smith about 4 years ago

  • Target version changed from Arvados Future Sprints to 2015-10-28 sprint

#6 Updated by Brett Smith about 4 years ago

  • Target version changed from 2015-10-28 sprint to Arvados Future Sprints

#7 Updated by Radhika Chippada almost 4 years ago

A little more detail about implementation:

  • I think the “add new group button” should behave as follows:
    • If no such group exists with the given name, create a new group with that name (with group_class “role”)
    • Bypass the group creation if one with this name already exists
    • Add user->group and group->user links in both cases
  • Delete the “Tip” note from the “Group memberships” panel

#8 Updated by Brett Smith almost 4 years ago

Radhika Chippada wrote:

  • Add user->group and group->user links in both cases

What's the rationale behind this? I agree that it's common that the administrator will want to add the user to the group, but it won't always be true, and doing it automatically if the administrator isn't expecting it could undermine site security. This goes double for the user→group can_manage link.

Plus, this would create another situation where Workbench is making multiple API objects in a single request, and we don't have any great way to report problems if some, but not all, of those calls fail.

Everything else sounds great to me.

#9 Updated by Tom Clegg almost 4 years ago

I don't think "if group exists, do nothing, but behave as if success" is a good idea. If I create a group called "SuperSecret" and add a user to it, I expect it to have only that one user in it. I shouldn't be able to accidentally add a user to an existing group called "SuperSecret" merely because I didn't manually inspect the list of groups carefully enough before clicking "new group".

Showing an error "a group called Foobar already exists" in the modal seems safer -- it seems easy enough for the user to hit Esc/Cancel and use the existing group if desired.

#10 Updated by Radhika Chippada almost 4 years ago

  • Assigned To set to Radhika Chippada
  • Target version changed from Arvados Future Sprints to 2015-10-28 sprint

#11 Updated by Radhika Chippada almost 4 years ago

  • Status changed from New to In Progress

#12 Updated by Nico César almost 4 years ago

reviewing 9290961beb18476f71aa0ae12478fe50493e8ad9

we create keepDisk and keepServers and virtual machines from the Web UI when we do the deploy

so the change

def self.creatable?
    current_user and current_user.is_admin

should remain there and the corresponding tests.

#13 Updated by Brett Smith almost 4 years ago

Nico Cesar wrote:

we create keepDisk and keepServers and virtual machines from the Web UI when we do the deploy

Uhh, why? You can create them through the CLI as well, and it seems to me like that approach would be more amenable to deployment through Ansible or other automated tools.

#14 Updated by Nico César almost 4 years ago

talk to Brett, talk to Ward . and seems that the agreement is to do it the way we do it in the documentation:

so the generic buttons should go away (It seems I was the only one editing in the web interface anyways)

#15 Updated by Nico César almost 4 years ago

test didn't pass ... I'm investigating why that was my environment

#16 Updated by Nico César almost 4 years ago

LGTM // admin will use the cli

#17 Updated by Radhika Chippada almost 4 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset arvados|commit:61c91fe02574ad751c2c957f6ca0d2e1e21105f9.

Also available in: Atom PDF