Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add route to fulfill invites

Open
#1,679 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
javascript

Research direction

Start by resolving the route path in this issue, then inspect the existing signup form, app routing, and user adapter. Use Mirage while the API dependency is pending. Done means the route handles missing, plain, and project invites, creates the user with the invite ID, and has acceptance and integration coverage for the listed cases.

Written by the indexing model from the issue text.

Description

needs clarification Time: 4 hours

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 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 })
    • modify user adapter by overriding
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.

Dominant language
JavaScript
Stars
120
Forks
75
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from code-corps/code-corps-ember

All issues in code-corps/code-corps-ember

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.