m/paliad
1
0
Fork 0
Code Issues 152 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Team Administration: add 'Add user' action alongside 'Invite colleague' / 'Onboard existing' #49

New Issue
Open
opened 2026-05-20 11:38:17 +00:00 by mAi · 1 comment
mAi commented 2026-05-20 11:38:17 +00:00
Collaborator
Copy Link

Trigger

m 2026-05-20 13:37:

And I would like to add users, too — so far in Team Administration I only see invite colleague or Onboard existing account.

Current state (verified 2026-05-20)

  • /admin/team (Team Administration) exposes two user-creation paths:
    • Invite colleague — sends an email invitation to a new email; user signs up on receipt.
    • Onboard existing account — picks up someone who already has a Supabase auth user but no paliad.users row.
  • Neither path lets a global_admin create a user directly with all fields populated (email, display_name, office, profession, job_title, etc.) without involving an email round-trip or pre-existing auth account.

What m wants

A third 'Add user' action that lets a global_admin create a complete paliad.users row + (if necessary) the matching auth.users row, in one form submission. The new user can then be added to project teams immediately. This is the right path when:

  • An admin is onboarding a colleague who isn't checking email promptly.
  • A colleague needs to be visible in dropdowns (e.g. as a potential team member, approver, owner) before they've actually logged in.
  • Bulk onboarding scenarios where the admin is faster than the invitation flow.

Design considerations

  • Auth account: needs an auth.users row for the user to ever log in. Two paths:
    • (R) Generate a Supabase magic-link / password-reset link as part of the create flow → email it. The user can log in via the link to set a password. Bridges admin-create and email-onboard.
    • Alternative: pure metadata-only create with no auth.users row — user is reachable in dropdowns but can never log in until invited. Useful for placeholder records; risks orphans.
  • Required fields: email, display_name, office (from the firm office list), profession (now backfilled per recent work), job_title. global_role defaults to standard.
  • Uniqueness: email must be unique against both paliad.users.email and auth.users.email. Duplicate behaviour: refuse the create + nudge admin to use 'Onboard existing'.
  • Audit: emit a user_added_by_admin event recording the creator + the new user_id.
  • Permission: global_admin only. The new Project-Admin role (separate issue) does NOT grant org-wide user creation.
  • Welcome email: optional checkbox 'Send welcome email with login link'. Default on.

Acceptance

  • A global_admin can navigate to /admin/team and click 'Add user' (next to 'Invite colleague' + 'Onboard existing').
  • A modal collects email, display_name, office, profession, job_title.
  • On submit, the paliad.users + auth.users rows are created in one tx (or the auth row + paliad row are linked atomically).
  • The new user appears in all dropdowns (team picker, approver list, owner picker) immediately.
  • The new user can log in via the emailed magic link (if 'Send welcome email' was on).
  • Audit row written.
  • Duplicate emails refused with a clear error nudging to 'Onboard existing'.

Out of scope

  • Bulk CSV / Excel user import (separate feature; might be Phase 2).
  • Editing existing users' fields via this surface (separate admin edit flow).
  • Cross-tenant user provisioning (paliad is single-firm per deploy).

Role recommendation

inventor — Supabase auth integration nuance + the magic-link path + atomic two-table create deserve a design pass. Then coder shift. Branch: mai/<inventor>/admin-add-user.

## Trigger m 2026-05-20 13:37: > And I would like to add users, too — so far in Team Administration I only see invite colleague or Onboard existing account. ## Current state (verified 2026-05-20) - `/admin/team` (Team Administration) exposes two user-creation paths: - **Invite colleague** — sends an email invitation to a new email; user signs up on receipt. - **Onboard existing account** — picks up someone who already has a Supabase auth user but no `paliad.users` row. - Neither path lets a global_admin create a user directly with all fields populated (email, display_name, office, profession, job_title, etc.) without involving an email round-trip or pre-existing auth account. ## What m wants A third 'Add user' action that lets a global_admin create a complete `paliad.users` row + (if necessary) the matching `auth.users` row, in one form submission. The new user can then be added to project teams immediately. This is the right path when: - An admin is onboarding a colleague who isn't checking email promptly. - A colleague needs to be visible in dropdowns (e.g. as a potential team member, approver, owner) before they've actually logged in. - Bulk onboarding scenarios where the admin is faster than the invitation flow. ## Design considerations - **Auth account**: needs an `auth.users` row for the user to ever log in. Two paths: - **(R)** Generate a Supabase magic-link / password-reset link as part of the create flow → email it. The user can log in via the link to set a password. Bridges admin-create and email-onboard. - Alternative: pure metadata-only create with no `auth.users` row — user is reachable in dropdowns but can never log in until invited. Useful for placeholder records; risks orphans. - **Required fields**: email, display_name, office (from the firm office list), profession (now backfilled per recent work), job_title. global_role defaults to `standard`. - **Uniqueness**: email must be unique against both `paliad.users.email` and `auth.users.email`. Duplicate behaviour: refuse the create + nudge admin to use 'Onboard existing'. - **Audit**: emit a `user_added_by_admin` event recording the creator + the new user_id. - **Permission**: global_admin only. The new Project-Admin role (separate issue) does NOT grant org-wide user creation. - **Welcome email**: optional checkbox 'Send welcome email with login link'. Default on. ## Acceptance - A global_admin can navigate to /admin/team and click 'Add user' (next to 'Invite colleague' + 'Onboard existing'). - A modal collects email, display_name, office, profession, job_title. - On submit, the `paliad.users` + `auth.users` rows are created in one tx (or the auth row + paliad row are linked atomically). - The new user appears in all dropdowns (team picker, approver list, owner picker) immediately. - The new user can log in via the emailed magic link (if 'Send welcome email' was on). - Audit row written. - Duplicate emails refused with a clear error nudging to 'Onboard existing'. ## Out of scope - Bulk CSV / Excel user import (separate feature; might be Phase 2). - Editing existing users' fields via this surface (separate admin edit flow). - Cross-tenant user provisioning (paliad is single-firm per deploy). ## Role recommendation **inventor** — Supabase auth integration nuance + the magic-link path + atomic two-table create deserve a design pass. Then coder shift. Branch: `mai/<inventor>/admin-add-user`.
mAi self-assigned this 2026-05-20 11:38:17 +00:00
mAi commented 2026-05-20 13:20:14 +00:00
Author
Collaborator
Copy Link

Slice B shipped via gauss; merged into main at https://mgit.msbls.de/m/paliad/commit/9dd47a0. t-paliad-223 complete (Slices A + B + C). Live after Dokploy deploys the new SUPABASE_SERVICE_ROLE_KEY env var (redeploy queued earlier).

Slice B shipped via gauss; merged into main at https://mgit.msbls.de/m/paliad/commit/9dd47a0. t-paliad-223 complete (Slices A + B + C). Live after Dokploy deploys the new SUPABASE_SERVICE_ROLE_KEY env var (redeploy queued earlier).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#49
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?