2.7 KiB
Functional Design Clarifications — Unit 5: User Management
Status: 🚧 Awaiting answers
Your answer on Q7 introduces additional requirements that need clarification before designing.
Please fill in the letter after each [Answer]: tag.
Clarification A: "Copy link at a later point" — where?
You answered that the invite link should be accessible after the dialog closes. Where should the persisted invite link be visible for users with a pending invitation?
A) In the user table row — an "action" button or icon (e.g. a chain-link icon) next to each pending user that copies the invite link to clipboard directly (recommended — minimal UI, no extra page needed) B) In an expandable row detail panel within the user table — clicking a row shows extra details including the invite link C) In a separate user detail modal/drawer — clicking the user opens a drawer with their details + invite link D) Other
Clarification B: "Refresh invite token" — backend approach
Regenerating an invite token requires invalidating the old one and creating a new one. Which backend approach should be used?
A) Add a new backend endpoint POST /api/v1/Users/{userId}/reinvite that invalidates any existing pending invitation for that user and generates a fresh token (recommended — clean, explicit, safe)
B) Re-use the existing POST /api/v1/Users/invite with the same email — the backend simply creates a new token (the old one remains valid until it expires)
C) Other
Answer: C, Never mind this feature. Might be a future feature.
Clarification C: Pending invitation state — backend data
For the frontend to know which users have a pending invitation, the GET /api/v1/Users response needs to indicate this. How should the backend expose this?
A) Add invitationPending: boolean and inviteLink: string | null fields to the user list response — the frontend can show the link directly when invitationPending = true (recommended — no extra roundtrip)
B) Add only invitationPending: boolean — the invite link is fetched on demand via a separate endpoint when the user wants to copy it
C) Other
Clarification D: Scope of "user details" — role promotion
In Q3 you mentioned that an Owner can promote an Administrator to Owner. Is role promotion (changing an existing user's role) in scope for Unit 5, or is it deferred to a later unit/feature?
A) Deferred — Unit 5 only covers inviting new users; role changes for existing users are a separate feature (recommended — keeps Unit 5 focused on the invitation flow) B) In scope for Unit 5 — add a "Change role" action to the user table alongside the invite functionality C) Other