Alice is a researcher at a lab and she is in the process of starting a new project. She is trying to recruit people to join her research team to work on her new project. Alice thinks that her friend Bob who is a researcher at a different lab might be interested in joining her team.
| Goal | Alice wants to invite Bob to join her Synapse team. |
| Primary actor | Alice |
| Secondary actor | Bob |
| Precondition | Alice has created a team and she is at her team's page. |
| Postcondition | Bob receives an email invitation to join Alice's team. |
Main success scenario | Step 1. Alice invites Bob to join her team by entering his email address and an optional invitation message. Step 2. System sends Bob an email containing an invitation link to join Alice's team. |
| Error scenarios | Replacing step 2.
|
| Goal | Alice wants to invalidate the invitation she sent previously. |
| Primary actor | Alice |
| Secondary actor | Bob |
| Preconditions |
|
| Postcondition | The invitation link Bob received is no longer valid. |
Main success scenario | Step 1. Alice retrieves the pending invitations to her team and removes the one associated with Bob. Step 2. System invalidates the invitation link sent to Bob. |
Sub use case C1 - Bob wants to create a Synapse account using the same email address to which Alice sent the email invitation.
Sub use case C2 - Bob wants to create a Synapse account using a different email address, not the one to which Alice sent the email invitation.
| Goal | Bob wants to create a Synapse account and accept Alice's invitation. |
Primary actor | Bob |
| Secondary actor | Alice |
| Preconditions |
|
| Postcondition | Bob is part of Alice's team. |
Sub use case C1 Success scenario | Step 1. Bob clicks on the invitation link in the email he received and is directed to the Synapse web client. Step 2. The web client presents Bob with the option to create a Synapse account or sign in with an existing account. Step 3. Bob creates his new Synapse account. Step 4. The web client displays Alice's invitation to Bob. Step 5. Bob accepts Alice's team invitation. Step 6. System sends a notification email to Alice saying that Bob has joined her team. |
Sub use case C2 Success scenario | Step 1. Bob clicks on the invitation link in the email he received and is directed to the Synapse web client. Step 2. The web client presents Bob with the option to create a Synapse account or sign in with an existing account. Step 3. Bob creates his new Synapse account. Step 4. System sends a verification email to the address to which Alice sent the invitation. Step 5. The web client prompts Bob to verify that he owns the above email address by clicking the link in the verification email. Step 6. Bob clicks on the verification link and is directed to the Synapse web client. Step 7. The web client displays Alice's invitation to Bob. Step 8. Bob accepts Alice's team invitation. Step 9. System sends a notification email to Alice saying that Bob has joined her team. |
Sub use case D1 - Bob wants to sign in to his existing Synapse account which is associated with the same email address to which Alice sent the invitation.
Sub use case D2 - Bob wants to sign in to his existing Synapse account which is not associated with the email address to which Alice sent the invitation.
| Goal | Bob wants to sign in to his existing Synapse account and accept Alice's invitation. |
Primary actor | Bob |
| Secondary actor | Alice |
| Preconditions |
|
| Postcondition | Bob is part of Alice's team. |
Sub use case D1 Success scenario | Step 1. Bob clicks on the invitation link in the email he received and is directed to the Synapse web client. Step 2. The web client presents Bob with the option to create a Synapse account or sign in with an existing account. Step 3. Bob signs in with his existing Synapse account. Step 4. The web client displays Alice's invitation to Bob. Step 5. Bob accepts Alice's team invitation. Step 6. System sends a notification email to Alice saying that Bob has joined her team. |
Sub use case D2 Success scenario | Step 1. Bob clicks on the invitation link in the email he received and is directed to the Synapse web client. Step 2. The web client presents Bob with the option to create a Synapse account or sign in with an existing account. Step 3. Bob signs in with his existing Synapse account. Step 4. System sends a verification email to the address to which Alice sent the invitation. Step 5. The web client prompts Bob to verify that he owns the above email address by clicking the link in the verification email. Step 6. Bob clicks on the verification link and is directed to the Synapse web client. Step 7. The web client displays Alice's invitation to Bob. Step 8. Bob accepts Alice's team invitation. Step 9. System sends a notification email to Alice saying that Bob has joined her team. |
This use case is covered by use case C.
Guaranteeing the security of our users' data is a top priority. Inviting a person to join your team is effectively giving that person access to all the data contained in all the projects your team has access to. This means that inviting someone through email inherently carries some risk.
Consider the following scenarios that could result in data breaches:
In order to protect our users from these types of situations, we could make the following design decisions:
| New models | Existing models (modified) | |||||
|---|---|---|---|---|---|---|
| EmailMembershipInvitation | EmailMembershipInvitationId | EmailMembershipInvitationsResponse | EmailValidationSignedToken | InviteeVerificationSignedToken | AccountSetupInfo | NewUser |
emailAddress teamId createdBy id | emailMembershipInvitationId | results - ARRAY<EmailMembershipInvitation> nextPageToken | timestamp hmac | inviteeId emailMembershipInvitationId timestamp hmac | firstName lastName
emailValidationSignedToken username password |
|
New services
| Description | Intended User | URI | Method | Request Parameters | Request Body | Response Body |
|---|---|---|---|---|---|---|
Create an email membership invitation. Send an email containing an invitation link to the invitee. The link will contain a serialized EmailMembershipInvitationId. | team administrator | /emailMembershipInvitation | POST | portalEndpoint | EmailMembershipInvitation | EmailMembershipInvitation |
| Retrieve a pending email membership invitation. The emailAddress field of the response body object will be null. | authenticated user | /emailMembershipInvitation/{id} | GET | -- | -- | EmailMembershipInvitation |
| Retrieve all the pending email membership invitations from a Team. | team administrator | /team/{id}/emailMembershipInvitations | GET | nextPageToken | -- | EmailMembershipInvitationsResponse |
| Delete a pending email membership invitation. | team administrator | /emailMembershipInvitation/{id} | DELETE | -- | -- | -- |
Start the process of creating a new account, similarly to POST /account/emailValidation, but also the process of associating a membership invitation to the new account. Send a 'validation email' message to the provided email address. The email will contain a link to complete the registration process. The link will contain a serialized EmailValidationSignedToken (used for new account registration) and a serialized EmailMembershipInvitationId (used to create membership invitation). Intended to be used in conjunction with POST /account. | public | /emailMembershipInvitation/{id}/account/emailValidation (or extend the existing /account/emailValidation service with an optional parameter emailMembershipInvitationId) | POST | portalEndpoint | NewUser | -- |
Verify whether the authenticated user is the invitee of the indicated EmailMembershipInvitation. If they are, the response body will contain an InviteeVerificationSignedToken. If they are not, the response body will be null and an identity verification email containing a link will be sent to the address associated with the indicated EmailMembershipInvitation. The link will contain a serialized InviteeVerificationSignedToken. | authenticated user | /emailMembershipInvitation/{id}/verification | POST | portalEndpoint | -- | InviteeVerificationSignedToken |
Create a MembershipInvitation. The invitation is created from the team associated with the given email membership invitation to the currently authenticated user. A valid InviteeVerificationSignedToken must have an inviteeId equal to the id of the authenticated user and an emailInvitationId equal to the id in the URI. Doesn't send any email notifications. | authenticated user | /emailMembershipInvitation/{id}/membershipInvitation | POST | -- | InviteeVerificationSignedToken | MembershipInvtnSubmission |
Related services: POST /account, POST /session
I expect that in most cases, invitees will choose to sign in or register with the invited email address. I'll refer to this as the "happy" case.
In phase 1 I will implement use cases A, B, C1, D1 and E. These use cases represent the happy case.
There will be some invitees that want to sign in or register with a different email address. I expect that the number of users who choose this path will be low enough that this will be an edge case.
In phase 2 I will implement use cases C2 and D2. These use cases represent the edge case described above.
