Arvados

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

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.

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.

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.

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.

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

• http://doc.arvados.org/install/install-keepstore.html
• http://doc.arvados.org/install/install-keepproxy.html

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

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

LGTM // admin will use the cli