Proposal for a more flexible RBAC model

[galvana]

Description Of Changes

A suggestion for a more flexible constraint model.

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • All UX related changes have been reviewed by a designer
  • No UX review needed
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
fides-plus-nightly	Ignored		Feb 12, 2026 0:27am
fides-privacy-center	Ignored		Feb 12, 2026 0:27am

[greptile-apps]

Greptile Overview

Greptile Summary

Refactored RBAC constraint model from pairwise design to NIST-compliant set-based design. The previous rbac_role_constraint table stored constraints as pairs of roles (role_id_1, role_id_2), making multi-role constraints impossible to express atomically. The new design uses rbac_constraint with a threshold column and rbac_constraint_role junction table to represent role sets, following the NIST RBAC standard: SSD(role_set, n) and DSD(role_set, n).

Key Changes:

• Renamed rbac_role_constraint → rbac_constraint
• Replaced role_id_1, role_id_2, max_users columns with unified threshold column
• Added rbac_constraint_role junction table for role sets
• Enhanced constraint validation methods (would_violate_sod, would_violate_cardinality)
• Comprehensive test coverage for multi-role SoD constraints
• Excellent README documenting the migration rationale

Issues Found:

• Migration uses server_default="false"/"true" instead of "f"/"t" for boolean columns (4 occurrences)

Confidence Score: 4/5

• Safe to merge after fixing boolean default formatting in migration
• Well-designed refactoring with comprehensive tests and documentation, but migration has syntax issues with boolean defaults that need correction before merging
• Migration file needs boolean default format corrections before merge

Important Files Changed

Filename	Overview
src/fides/api/alembic/migrations/versions/xx_2026_01_31_1000_d9ee4ea46797_add_rbac_tables.py	Renamed constraint table and restructured from pairwise to set-based design with NIST RBAC compliance. Issue: boolean defaults use incorrect format ("false"/"true" instead of "f"/"t")
src/fides/api/models/rbac/rbac_constraint.py	New NIST-compliant constraint model with comprehensive validation methods for SoD and cardinality constraints
src/fides/api/models/rbac/rbac_constraint_role.py	Junction table for NIST role sets, properly implements composite primary key
tests/api/models/test_rbac.py	Comprehensive tests for new constraint model including multi-role SoD, cardinality constraints, and validation logic

[greptile-apps]

_{13 files reviewed, 4 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (4)

src/fides/api/alembic/migrations/versions/xx_2026_01_31_1000_d9ee4ea46797_add_rbac_tables.py
Use server_default="f" instead of server_default="false" for boolean columns in Alembic migrations per project conventions

            server_default="f",

Context Used: Rule from dashboard - Use server_default="f" for boolean columns in Alembic migrations instead of default=False or oth... (source)

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

---

src/fides/api/alembic/migrations/versions/xx_2026_01_31_1000_d9ee4ea46797_add_rbac_tables.py
Use server_default="t" instead of server_default="true" for boolean columns

            server_default="t",

Context Used: Rule from dashboard - Use server_default="f" for boolean columns in Alembic migrations instead of default=False or oth... (source)

---

src/fides/api/alembic/migrations/versions/xx_2026_01_31_1000_d9ee4ea46797_add_rbac_tables.py
Use server_default="t" instead of server_default="true"

            server_default="t",

Context Used: Rule from dashboard - Use server_default="f" for boolean columns in Alembic migrations instead of default=False or oth... (source)

---

src/fides/api/alembic/migrations/versions/xx_2026_01_31_1000_d9ee4ea46797_add_rbac_tables.py
Use server_default="t" instead of server_default="true"

            server_default="t",

Context Used: Rule from dashboard - Use server_default="f" for boolean columns in Alembic migrations instead of default=False or oth... (source)