56 lines
2.7 KiB
Markdown
56 lines
2.7 KiB
Markdown
# 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
|
|
|
|
[Answer]: A
|
|
|
|
---
|
|
|
|
### 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
|
|
|
|
[Answer]: A
|
|
|
|
---
|
|
|
|
### 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
|
|
|
|
[Answer]: B
|