- 
                Notifications
    
You must be signed in to change notification settings  - Fork 78
 
Description
Problem
We need a route (at a path to be decided on here) which will be used to claim a user invite
Subtasks
- Decide on path for the route through discussion in this issue
 -  Add route to app
- Loads invite, has a 404/not_found substate
 - Displays different informational UI depending on the invite being for a project or just a plain invite
 - Displays form UI for user account creation - mostly the same as the signup form
 - When creating the user, add invite ID to the new user payload
 - Write acceptance test for success case for a plain invite
 - Write acceptance test for success case for a project invite
 - Write fail case for an invite not found
 - Write any integration tests for components added as part of the solution
 
 
Notes
How to specify an invite id
- 
We could add the invite id as a virtual attribute and push it as part of the payload. Would require a virtual attribute API side as well
 - 
We could ad a
hasMany('claimed-invites')to the user model, since the API already has it, then push the loaded invite into the association and save that way. Should end asclaimed_invite_idson the API, but would require rewriting our API approach slightly - 
My prefered approach
- save a plain user, but when calling save, specify 
user.save({ inviteId: userInvite.id }) - modify user adapter by overriding
 
 - save a plain user, but when calling save, specify 
 
urlForCreateRecord(modelName, snapshot) {
  if (snapshot.inviteId) {
    return this._super(...arguments) + `?invite_id=${snapshot.inviteId}`
  } else {
    return this._super(...arguments);
  }
}This way, we keep the create "switch" separate from the create attributes, since it becomes a query param. At the same time, the API should keep working.
References
Requires code-corps/code-corps-api#1351 merged, but can be worked on using mirage in the interim.