[BIA3IA]

Stacked on #73 (base feat/people-role-api), so its approval stays untouched. Refs #78.

Why

PoliNetworkOrg/backend#105 keeps assignments for People records that aren't linked yet. This IdP only sees them when the record is linked, so the backend must apply peopleRoleChangeProblem's rules itself when they are made (backend#101). Two of those rules need data the backend can't get today: the access snapshot's catalog (#62) only has role keys and names.

• Bounded delegation needs every permission the role grants.
• The inherited-binding rule needs the bindings of the roles it inherits. For example, capo-admin inherits admin, so it also needs people:write.

Without these fields backend#105 refuses new pending assignments, except to Master Admin.

What changes

• Each entry of roles in GET /api/internal/people-roles, and in the POST answer, gains two fields:
  • permissions: effectiveRolePermissions, so through parent roles too, sorted;
  • bindings: the role's own binding, then those of the roles it inherits, which is exactly what peopleRoleChangeProblem checks.
• describePeopleBoundRoles builds them, so both endpoints share them. The fields are additive: an older backend ignores them.
• README: the endpoint description and why the backend needs the fields.

Tests

• Unit test: capo-admin → bindings: ["capo", "admin"], plus the permissions it inherits. hr-lead gets hr-member's permissions. Unbindable roles stay out.
• People PostgreSQL integration: the directory lists capo with bindings: ["capo", "admin"].

Validation:

• vp check passes.
• vp test: 351 passed, 124 skipped. The skips are integration suites that need their own databases.
• The People PostgreSQL integration suite, run on a disposable PostgreSQL with migrations applied: 7/7.
• pnpm run build passes.

I also checked #73 (ce030c5) against every item of #78, and all are covered: migration 0024 is gone and 0023 is after main's 0022, no Soci or azureId, the capo kind, idp:people:bind, PEOPLE_RULES, the MCP tool, and the README.

[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: 196d5f94-928f-4b7b-bc30-e84632317631

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.}