You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 as claimed_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 })
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.
Problem
We need a route (at a path to be decided on here) which will be used to claim a user invite
Subtasks
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 slightlyMy prefered approach
user.save({ inviteId: userInvite.id })
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.
The text was updated successfully, but these errors were encountered: