[People · Phase 1] Group Admins, Capo Admins and Team members with Auth roles #143

Goal

Board members and team Leads assign people to the association's semantic roles from the admin dashboard:

• Group Admin;
• Capo Admin;
• Team member / Lead.

Each person then receives the matching RBAC roles from PoliNetwork Auth automatically. For example, a Group Admin gets the admin role, which grants tg:messages:delete.

Rules

• Only predetermined roles. Auth only lets People hand out roles that are bound to a People meaning (admin, capo, team:<key>:member, team:<key>:lead). A bound role can never carry idp:* permissions.
• Clearance comes from RBAC and Auth checks it.
  • Admin and team member: admin:access + people:write, or being Lead of that team.
  • Lead and Capo Admin: admin:access + people:appoint.
  • Nobody assigns themselves a role.
  • Nobody hands out a role granting permissions they don't hold.
• People without a linked account live only in the backend. Their assignments wait there, and nothing is created in Auth. We often don't know which account someone will sign in with (Entra ID if they're a socio, otherwise any Google account), and the email and name we have may not match it.
• Two ways to link, and nothing automatic:
  • an email invite with a single-use link, accepted by signing in with any account;
  • a manual link by someone with the new people:link permission.
• Once linked, Auth holds the truth, and People shows what Auth holds. Role changes go to Auth as idempotent, all-or-nothing commands.

Flow

Create a person (manually or by CSV) ──► assignments pending in the backend
        │
        ├─ email invite ──► invitee signs in with any account ──► confirms
        └─ people:link holder links an account by hand
                                   │
                                   ▼
              backend sends role commands to Auth
              (actor = whoever made each assignment, or whoever linked)
                                   │
              Auth checks the actor's clearance ──► roles applied, or refused with a reason shown on the record

Capo Admins managing their admins: later, but designed for

Capo Admins may later add and remove the admins under them. We're not building that now, but Phase 1 must not make it hard:

• Auth's delegation rules are one rule per binding kind ([People · Phase 1] Let People manage bound roles, without preliminary people (rework of #73) auth#78).
• The backend stores Capo of reference as a relation, and its pending-assignment checks mirror Auth's rules ([People · Phase 1] People records, assignments and role sync with Auth backend#101).
• The Capo Admin page is laid out so management could be added ([People · Phase 1] People pages: records, Admins, Capo Admins and Teams #139).

Sub-issues, in order

Deploy order: Auth (PoliNetworkOrg/auth#78) → IdP setup (PoliNetworkOrg/auth#79) → backend → dashboard. Each backend piece deploys before the dashboard piece that uses it.

Permissions after Phase 1