Allow users to have multiple instances

[2opremio]

Currently a user can only have one scope instance. They may want to have more than one, and to share those instances with others.

This requires introducing the following new functionality:

As a Weave Cloud user, I should be able to

• create new instances, which automatically grants me access to that instance
  • API: Add an org Label #650 (POST /api/users/org)
  • UI
• see all instances I have access to
  • API (GET /api/users/lookup)
  • UI
• view any of my instances
  • API (GET /private/api/user/lookup/{orgName} – already called by our authenticator)
  • UI
• invite others to access any of my instances
  • existing users (Cannot invite an existing user to my instance. #505)
    • API: Allow users to be invited to multiple organizations #656
    • UI
  • people who aren't users yet
    • API
    • UI
• see who has access to each of my instances
  • API (GET /api/users/org/{orgName}/users, already used by the UI.)
  • UI
• revoke a user's access to any of my instances
  • API (DELETE /api/users/org/{orgName}/users/{userEmail}): Revoke user access to org #661
  • UI
• see that I have been granted access to an instance by someone else
  • API (GET /api/users/org/{orgName})
  • UI
• revoke my own access to an instance Revoke my own access to an instance #687
  • API (DELETE /api/users/org/{orgName}/users/{myUserEmail}): Revoke user access to org #661
  • UI

These have some corollaries:

• when I sign up to Weave Cloud for the first time, the UI should not assume that I want to create my own instance. Options include:
  • create a demo instance
  • don't create an instance automatically

Terminology note: "my instances" means "instances that I have access to" rather than "instances I have created. Having a concept of instance ownership is out of scope for this work.

[rade]

To clarify...

We are using team/org/instance sometimes interchangeably, and sometimes to mean different things. Right now, they do all mean the same thing. Let's call it 'instance' for now, and ditch all the other terms.

There is a 1-1 relationship between instances and tokens (the thing you tell your probes when pointing them at Weave Cloud). Everything reported by these probes will be treated by Weave Cloud as "belonging together"; all views a user is looking at in Weave Cloud are scoped (pun intended) to a single instance.

Right now there is a n-1 relationship between users and instances.

This issue is about relaxing that relationship to a n-m relationship: i.e. a single user can access multiple instances

That requires introducing the following new functionality

1. a user should be able to create new instances, which automatically grants them access to that instance
2. a user should be able to list all instances they have access to, and select which one to view
3. a user should be able to invite a user to any of the instances they have access to
4. a user should be able to see which other users have access to an instance (that they themselves have access to)
5. a user should be able to remove a user's access to an instance (that they themselves have access to)

(3) is an extension of the existing 'invite' functionality and comes in two flavours:

a) inviting a new user to scope - I think this is exactly as it works now
b) inviting an existing scope user - as a minimum that should simply include the instance in the list the user sees at (2). We may also want to send the user an email notification, perhaps with a direct link to the instance. This is the subject of #505.

(4) and (5) are existing functionality extended to the multi-instance case.

As part of this, we should probably change the sign-up process s.t. it doesn't automatically create an instance.

[rade]

What happens to an instance when no user has access to it? I reckon that should deny access by probes with the instance's token, and deny access to the 'view instance' functionality (and any other instance-related functionality that may exist). We shouldn't actually remove any data though, so that a later point we can introduce functionality to resurrect such 'disabled' instances.

[tomwilkie]

Right now there is also a 1-1 relationship between users and instances.

There is currently an n-1 relationship between users and 'instances'

Plus, the backend has support for n-m, but we punted on the UX pieces so it is intentionally blocked.

[rade]

There is currently an n-1 relationship between users and 'instances'

Ah yes, otherwise the present invite feature would be pointless. Have updated the text.

Plus, the backend has support for n-m, but we punted on the UX pieces so it is intentionally blocked.

Understood.

[jml]

I've updated the description with what I think are all the exit criteria for this ticket.

[rade]

I've updated the description with what I think are all the exit criteria for this ticket.

Looks reasonable, though I suggest clarifying what is meant by "my instances". It's simply the list of all instances I have access to. not the list of instances I have created. i.e. the notions of ownership and access are one and the same.

[rade]

UI flows

[jml]

• When I hit "Remove" to revoke someone's access, nothing happens on the UI for me, but the other person gets revoked
• When someone adds you to an instance, you aren't really "invited"—there's nothing to accept or reject. We should change the wording
• The invite email says "organization" when it should say "instance"

[jml]

I can't revoke my own access to an instance, but that's OK for now, because that adds extra complexity. We should definitely do it later. I've filed #687 to track that and will update the checklist in this issue's description to remove those elements.

[jml]

I'll hold off looking at the invite wording change's until @paulbellamy's big refactoring (starting #678) gets merged

[jml]

Invitation wording is #692. This bug is done. Thanks all!