...

Services to implement or modify

...

• 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.
  How many invitees choose to register a new account and how many choose to sign in.
  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.

...

•  MembershipInvtnSignedToken
•  EmailValidationSignedToken
•  InviteeVerificationSignedToken (Not merged yet)
•  AccountCreationToken

Update existing models

•  MembershipInvtnSubmission (Not merged yet)
•  AccountSetupInfo
•  NewUser

Update existing services

•  POST /membershipInvitation (Not merged yet)membershipInvitation
•  POST /account/emailValidation

...

•  POST /membershipInvitation/{id} (Not merged yet)
•  POST /membershipInvitation/{id}/verification (Not merged yet)
•  PUT /membershipInvitation/{id}/inviteeId (Not merged yet)

...

•  PUT /membershipInvitation/{id}/inviteeId

Update web client

•  Make everything work

Sequence of events

Image Added

Made on https://sequencediagram.org/ with the following markup:

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