[BIA3IA]

People can register a person in Auth before their first login, using only first and last name, optional contacts, and initial bound admin/team roles. Auth remains the authority for identity details and role assignments. This extends #73 and supports PoliNetworkOrg/backend#99 and PoliNetworkOrg/admin#136.

• Migration 0024_people_registration.sql stores declared contacts separately from verified provider evidence. The preliminary Auth subject has no credentials, provider accounts or sessions, and is excluded from the login-account/signing picker.
• The existing backend-only endpoint accepts idempotent create-person, update-person and link-person commands. Creation/contact editing require admin:access and people:write; every role assignment still passes the original delegation checks. Reused IDs with changed input are refused.
• Verified app email or Telegram identity produces a review proposal. Homonyms are name-only hints; conflicting identifiers require review. No contact or name automatically links accounts or grants access.
• A Master Admin approves the identity link. Auth atomically transfers the preliminary person's current bound roles to the existing login account, keeping that account's other roles and provider accounts. A stable registration ID lets People retain its record and history, including after a backend restart or a lost response.
• Directory responses also expose users[].since, the earliest assignment date conferring each held bound role, including inheritance.

Validation: check, typecheck, all tests and production build/bundle validation passed. 352 tests passed and 117 were skipped, with the People role PostgreSQL suite enabled on a disposable migrated database. New coverage checks contact matching, ambiguity, no pre-login provider account, idempotent creation, rejected non-Master linking, Master approval and canonical directory identity.

Merge into #73 first. Deploy Auth and apply migration 0024 before the matching backend/dashboard feature. Keep the People role bindings and backend idp:people:roles scope configured. Other integration suites requiring their own external configuration remain skipped; no production mutation or real-provider sign-in was performed.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: e241727d-6788-4d0d-b859-a68e48b267c6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[toto04]

For the record: we're not going ahead with the preliminary-person model from this PR. It will be removed from #73's branch by resetting it to d698d3c. Tracked in #78; the overall direction is in PoliNetworkOrg/admin#146.

Why:

• We can't reliably match identities. We often don't know which account someone will sign in with: Entra ID if they're a socio, otherwise any Google account. The name and email we have may not match it.
• Placeholder user rows cost too much. They have to be excluded across the IdP, and linking or unlinking has to move roles between subjects. That's security-sensitive IdP code we'd rather not carry.
• Linking only worked for Master Admins. linkPeoplePerson refuses unless the actor is Master Admin (people-registration.ts:106). feat(people)!: manage Auth-backed people before and after their first login backend#99 sends the invitee or the board member as the actor, so both invite acceptance and manual linking would fail with 403.

Instead, people without a linked account stay in the backend with their pending assignments. Linking happens only through an email invite (any account can accept it) or by hand with a new people:link permission. The backend then sends the normal role command, and Auth checks the actor's clearance as before (PoliNetworkOrg/backend#101, PoliNetworkOrg/backend#102).

If you want to keep anything from here, the per-role assignment date (users[].since) can come back on its own; it's listed as optional in #78.