Why
Part of the epic: need4deed-org/be#922 — inviting existing Volunteer rows (people who
submitted the public volunteer form but never created a login) to register as
a User with role: VOLUNTEER.
Backend will mint an invite JWT (type: "invite") tied to a pre-created,
inactive User row, and email a link. The frontend needs a page where the
invited person sets a password; that page calls a new backend endpoint. This
issue defines that endpoint's request/response contract in the SDK, since per
org convention (shared-rules.md) the SDK is the source of truth for the API
surface and must be published before be/fe consume it.
Scope
Add to src/types/api/ (follow existing file/naming conventions — check
whether an auth.ts file already exists for auth-related bodies, e.g.
password-reset, before deciding where this lives):
- An accept-invite request body type, e.g.
ApiAcceptInviteBody —
{ token: string; password: string; confirmPassword: string }. Match the
field naming/casing of whatever existing password-reset body type already
exists in the SDK exactly (don't invent new naming for the same concept).
- A response type — likely reuse
ApiUserGet if the endpoint logs the person
in / returns the activated account. Confirm against whatever be actually
returns once its issue below is scoped.
- Export the new type(s) from
src/types/api/index.ts.
Open questions to resolve with the be dev during TODO review
- Final endpoint path/method chosen in <BE_INVITE_ISSUE_URL> (extending
POST /auth/password-reset vs a new POST /auth/accept-invite) — confirm
before finalizing type names.
- Whether a new
Endpoint constant should be added to
src/constants/endpoints.ts for consistency with the existing
Endpoint.REGISTER.
Acceptance criteria
Why
Part of the epic: need4deed-org/be#922 — inviting existing
Volunteerrows (people whosubmitted the public volunteer form but never created a login) to register as
a
Userwithrole: VOLUNTEER.Backend will mint an invite JWT (
type: "invite") tied to a pre-created,inactive
Userrow, and email a link. The frontend needs a page where theinvited person sets a password; that page calls a new backend endpoint. This
issue defines that endpoint's request/response contract in the SDK, since per
org convention (
shared-rules.md) the SDK is the source of truth for the APIsurface and must be published before
be/feconsume it.Scope
Add to
src/types/api/(follow existing file/naming conventions — checkwhether an
auth.tsfile already exists for auth-related bodies, e.g.password-reset, before deciding where this lives):
ApiAcceptInviteBody—{ token: string; password: string; confirmPassword: string }. Match thefield naming/casing of whatever existing password-reset body type already
exists in the SDK exactly (don't invent new naming for the same concept).
ApiUserGetif the endpoint logs the personin / returns the activated account. Confirm against whatever
beactuallyreturns once its issue below is scoped.
src/types/api/index.ts.Open questions to resolve with the
bedev during TODO reviewPOST /auth/password-resetvs a newPOST /auth/accept-invite) — confirmbefore finalizing type names.
Endpointconstant should be added tosrc/constants/endpoints.tsfor consistency with the existingEndpoint.REGISTER.Acceptance criteria
src/types/api/index.tsmainvia.github/workflows/publish.yml)be/feissues below can pin the new published version