ENG-2149: basic DB support for monitor stewards

[adamsachs]

Ticket ENG-2149

Description Of Changes

Initial DB model support for monitor stewards: join table for many-to-many relationship between users and monitors.

Steps to Confirm

1. test with associated fidesplus branch: https://github.com/ethyca/fidesplus/pull/2927

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	Review	Updated (UTC)
fides-plus-nightly	Ignored	Preview	Dec 23, 2025 10:56am
fides-privacy-center	Ignored		Dec 23, 2025 10:56am

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.17%. Comparing base (95efd69) to head (59cd7f0).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7131   +/-   ##
=======================================
  Coverage   87.17%   87.17%           
=======================================
  Files         534      535    +1     
  Lines       35312    35325   +13     
  Branches     4113     4113           
=======================================
+ Hits        30783    30796   +13     
  Misses       3638     3638           
  Partials      891      891           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[adamsachs]

quick self review:

[adamsachs]

a simple abstraction for some scope/role checks, used in the fidesplus branch.

i wanted to leverage this same helper in other utility methods already in this module, to make the code DRYer, but it doesn't quite work, because the helpers here generally take the scopes directly from the endpoint as SecurityScopes

[greptile-apps]

Greptile Summary

• Adds database model support for monitor stewards feature with a new many-to-many join table linking users to monitor configurations
• Implements proper foreign key relationships and unique constraints to prevent duplicate steward assignments
• Includes comprehensive test coverage for the new roles_have_scopes utility function used for authorization validation

Important Files Changed

Filename	Overview
src/fides/api/alembic/migrations/versions/xx_2025_12_18_1400_b9c8e7f6d5a4_add_monitor_steward_table.py	New migration creates monitorsteward join table but uses mixed design with both separate ID primary key and unique constraint on foreign key pair
src/fides/api/models/detection_discovery/monitor_steward.py	New join table model with proper unique constraint preventing duplicate user-monitor assignments
src/fides/api/models/detection_discovery/core.py	Added many-to-many relationship from MonitorConfig to FidesUser via stewards property using secondary table

Confidence score: 4/5

• This PR is generally safe to merge but requires attention to database migration design consistency
• Score reflects solid implementation with proper constraints and relationships, but migration design doesn't follow existing SystemManager pattern which uses composite primary keys rather than separate ID fields
• Pay close attention to the migration file design and consider aligning with existing join table patterns in the codebase

PR Description Notes:

• Missing required db-migration label in changelog entry despite including database migration

[greptile-apps]

_{9 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[adamsachs]

@greptile

[adamsachs]

decided to add this to enforce uniqueness, i.e. at the moment we'll only support a single link between users and monitors. i got worried about accidental duplicates and the complexity to support multiple types of joins was not worth it for this first increment - we only need a single join, and it shouldn't be hard to remove constraints as we go forward (the opposite is not true - harder to add constraints then remove them!)

[greptile-apps]

_{9 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[vcruces]

Great work! I tested adding, removing, and fetching monitor stewards. I also tested filtering by steward in /aggregate-results, and everything worked as expected. The migration applied and rolled back cleanly