-
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_ids
on 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.