User invitation

[corvus-ch]

Summary

As an owner of a Team, Organization or BillingEntity I want to invite other users (existing or not) So that they can collaborate with me on the Team, Organization or BillingEntity.

Context

Allowing other users to collaborate with me, is an involved process. It requires the other person having an existing user account on the platform. Then I must know that person's username. This then allows me to add that users as a member/owner of Teams, Organizations and BillingEntities.

Instead, I want to send an invitation, using the person's email address. The rest then just happens.

The requirements for this are documented at https://kb.vshn.ch/appuio-cloud/references/functional-requirements/portal.html#_feature_send_invitations and https://kb.vshn.ch/appuio-cloud/references/functional-requirements/portal.html#_feature_accept_invitations. The architecture can be found at https://kb.vshn.ch/appuio-cloud/references/architecture/control-api-invitation.html.

Out of Scope

No response

Further links

No response

Acceptance Criteria

Scenario: List Invitations
  When I visit the portal
  And I press "Invitations" on the left hand menu
  Then I see a list of all invitations I have access to

Scenario Outline: Create Invitation
  When I visit the invitations list
  And I press the button "Invite user"
  And I select <entity> along with an access level
  And I press "invite"
  Then I am on the invitation list
  And I see an entry for created invitation
  And I see a success message

  Scenarios:
    | entity        |
    | Organization  |
    | Team          |
    | BillingEntity | 

Scenario: Accept Invitation
  Given I have received an invitation email
  When I follow the link in the email
  Then I am logged in to the appuio cloud portal
  And I see a notification naming the entities I have been added to
  And I am on the detail view of the entity if I have been invited to only a single entity

Implementation Ideas

No response

[ccremer]

@corvus-ch The API docs specifically mention status conditions like email send failures. Should the portal display those conditions in any way? What are possible action points for a user when there are failures in the status?

[corvus-ch]

@corvus-ch The API docs specifically mention status conditions like email send failures. Should the portal display those conditions in any way? What are possible action points for a user when there are failures in the status?

Yes, that information should be made available to the users. It is not the user's turn to act, but our. So, it should be of an informational kind.

One thing I need to add on our side is to have monitoring of such errors.

[ccremer]

First iteration: PR #509

I would propose to format the date more human friendly, also I'm not pleased with how the individual targets are displayed. Maybe it's better to completely omit them and only show the main condition(s).

[corvus-ch]

Yes definitely, please parse the dates and display them in a more human form (preferably take the users' locale into account).

As for the targets, can we use an icon for BillingEntity, Organization, and Team (with a hover showing the actual entity name)? The icon then is followed by the Human friendly name of the entity (spec.displayName with fallback to metadata.name) followed by the access level in brackets.

Example: $ be-2345 (viewer)

I do not see a need to have a redeemed flag for each and every target. The fact the invitation is redeemed, applies to all targets so one indication is enough.

[ccremer]

Yes definitely, please parse the dates and display them in a more human form (preferably take the users' locale into account).

:+1:

As for the targets, can we use an icon for BillingEntity, Organization, and Team (with a hover showing the actual entity name)? The icon then is followed by the Human friendly name of the entity (spec.displayName with fallback to metadata.name) followed by the access level in brackets.

Example: $ be-2345 (viewer)

Hover generally isn't mobile/tablet friendly, so I'd avoid that. I'll come up with a different proposal.

I do not see a need to have a redeemed flag for each and every target. The fact the invitation is redeemed, applies to all targets so one indication is enough.

yeah, me too. I'll remove it.

[corvus-ch]

@ccremer We recently were discussing "Bulk invitation". I do now remember the use case that lead to this. It is actually a multi-user, multi-entity use case. I am not so sure anymore this is actually needed. So in the spirit of agile and MVP, I decided to drop this for the first iteration.

[ccremer]

@corvus-ch Ack. Just to double-check my understanding: A single invitation is multi-entity capable, since the targetRefs is an array: https://kb.vshn.ch/appuio-cloud/references/architecture/control-api-invitation.html#_object Would you also drop this single-user, multi-entity case?

[corvus-ch]

Would you also drop this single-user, multi-entity case?

Let us scope it as: what ever can be done with a single invitation object. So yes, as targetRefs is an array, this includes the use case to invite a single user to multiple entities (for instance, viewer on an Organization and admin on a team, or any other possible combination).

[ccremer]

@corvus-ch I believe this can be closed now.