| Table of Contents |
|---|
...
| New models | |||
|---|---|---|---|
| MembershipInvtnSignedToken | EmailValidationSignedToken | InviteeVerificationSignedToken | AccountCreationToken |
membershipInvitationId expiresOn timestamp hmac | timestamp hmac | inviteeId membershipInvitationId expiresOn timestamp hmac | emailValidationSignedToken membershipInvtnSignedToken encodedMembershipInvtnSignedToken (optional) |
| Existing models (modified) | ||
|---|---|---|
| MembershipInvtnSubmissionMembershipInvitation | AccountSetupInfo | NewUser |
createdOn message id createdBy expiresOn inviteeId teamId inviteeEmail | firstName lastName
emailValidationSignedToken username password |
membershipInvtnSignedToken encodedMembershipInvtnSignedToken (optional) |
Services to implement or modify
| Existing or new | Description | Intended User | URI | Method | Request Parameters | Request Body | Response Body | |
|---|---|---|---|---|---|---|---|---|
| Existing | Create a membership invitation. The team must be specified. Either an inviteeId or an inviteeEmail must be specified. If an inviteeEmail is specified, send an email containing an invitation link to the invitee. The link will contain a serialized MembershipInvtnSignedToken. | team administrator | /membershipInvitation | POST | acceptInvitationEndpoint (optional) notificationUnsubscribeEndpoint (optional) | MembershipInvtnSubmissionMembershipInvitationMembershipInvtnSubmission | MembershipInvitation | |
| New | Retrieve a membership invitation. | signed token holder | /membershipInvitation/{id} | POST | -- | MembershipInvtnSignedTokenMembershipInvtnSubmission | MembershipInvitation | |
Existing | Start the process of creating a new account, and optionally 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 AccountCreationToken. Intended to be used in conjunction with POST /account. | public | /account/emailValidation | POST | portalEndpoint | NewUser | -- | |
| New | Verify whether the inviteeEmail of the indicated MembershipInvitation is associated with the authenticated user. If it is, the response body will contain an InviteeVerificationSignedToken. If it is not, (in phase 1 the server just responds with a 403) the response body will be null and an identity verification email containing a link will be sent to the inviteeEmail of the indicated MembershipInvitation. The link will contain a serialized InviteeVerificationSignedToken. This call will only succeed if the indicated MembershipInvitation has a null inviteeId and a non null inviteeEmail. | authenticated user | /membershipInvitation/{id}/verificationinviteeVerificationSignedToken | POSTGET | portalEndpoint | MembershipInvtnSignedToken | InviteeVerificationSignedToken | |
New | Set the inviteeId of a MembershipInvitation. A valid InviteeVerificationSignedToken must have an inviteeId equal to the id of the authenticated user and a membershipInvitationId equal to the id in the URI. This call will only succeed if the indicated MembershipInvitation has a null inviteeId and a non null inviteeEmail. | authenticated signed token holder | /membershipInvitation/{id}/inviteeId | PUT | -- | InviteeVerificationSignedToken | -- |
...
- Which users create invitations, when they create them, and from what teams they create them.
- These statistics are captured by the EmailMembershipInvitation MembershipInvitation (formerly MembershipInvtnSubmission) model, which is stored in the database.
- How many invitations are accepted and when they are accepted.
- There is no easy way to track this.
- We know the total number of membership
- when the invitation to the team is accepted, but we can know how many times the invitee will use the email link to create a new account or sign in to their existing account. This is essentially the number of times that PUT /membershipInvitation/{id}/inviteeId is called.
- How many invitees choose to register a new account and how many choose to sign in.
- We know the total number of membership invitations created from the number of POST /emailMembershipInvitation/{id}/membershipInvitation requests.
- We know the total number of invitees who chose to register a new account from the number of POST /emailMembershipInvitation/{id}/account/emailValidation requests.
- We can derive the total number of invitees who chose to sign in with an existing account from the above two numbers.
Implementation outline
Phase 1
...
- We can know how often invitees attempt to sign in using an email address that is not associated with the inviteeEmail of the MembershipInvitation by looking at how often GET /membershipInvitation/{id}/inviteeVerificationSignedToken calls respond with 403 status.
Implementation outline
Phase 1
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.
...
- POST /membershipInvitation/{id}
- POST /membershipInvitation/{id}/verification
- PUT /membershipInvitation/{id}/inviteeId
Update web client
- Make everything work
...
- /membershipInvitation/{id}/inviteeId
Update web client
- Make everything work
Sequence of events
Made on https://sequencediagram.org/ with the following markup:
| Code Block |
|---|
entryspacing 0.9
Frontend->Backend:Invite the new user (POST membershipInvitation)
Backend->OUT OF BAND: Send email that contains MembershipInvtnSignedToken
OUT OF BAND->Frontend: User clicks Join link in email
Frontend->Backend:Get corresponding membershipInvitation (POST membershipInvitation/id)
Backend-->Frontend:Membership Invitation
note over Frontend,Backend:Already has an account
Frontend->Frontend:User clicks "Already have an Account?"
Backend->OUT OF BAND
OUT OF BAND->Frontend
Frontend->Backend: Login
Backend-->Frontend:Successful Login
Frontend->Backend:GET membershipInvitation/id/inviteeVerificationSignedToken
Backend-->Frontend:Return InviteeVerificationSignedToken
Frontend->Backend: Update invitation with user id: PUT /membershipInvitation/{id}/inviteeId
Backend-->Frontend:
Frontend->Frontend: User sent back to the Team page. Single click Join (since there's an open invitation)
note over Frontend,Backend:New account
Frontend->Frontend:User click "Send Registration Info"
Frontend->Backend:POST/account/emailValidation
Backend->OUT OF BAND: Send validation email
OUT OF BAND->Frontend: User clicks create account link
Frontend->Backend:Standard account creation (sign ToU...)
Backend-->Frontend:Standard account creation
Frontend->Frontend: User sent to associated Team page. Single click Join (since there's an open invitation) |
Related JIRA issues
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|