fix: ensure ClientDetail.monitors are populated upon creation of ClientDetails

[adamsachs]

Description Of Changes

Fixes a bug in monitor steward features. Associated monitors were not being assigned to ClientDetails if they were created after monitor steward assignment, i.e. if user logs in after they were assigned as a monitor steward.

Code Changes

• ensure we populate monitors whenever create a ClientDetail record based on a real user.

Steps to Confirm

1. users assigned as monitor stewards can act on monitor results after logging in after monitor steward assignment

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	Preview	Feb 5, 2026 9:41pm
fides-privacy-center	Ignored		Feb 5, 2026 9:41pm

[greptile-apps]

Greptile Overview

Greptile Summary

This PR fixes missing monitor stewardship propagation into OAuth client details during login flows.

Specifically, it populates ClientDetail.monitors from FidesUser.stewarded_monitor_ids when creating an in-memory client for the temporary (invalid) login-flow user (src/fides/api/oauth/utils.py), and when creating or refreshing the persistent client during UserService.perform_login (src/fides/service/user/user_service.py). This aligns monitors with the existing roles/systems hydration behavior so monitor-steward features have the expected data immediately after client creation/refresh.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk.
• Changes are small and targeted: they only add the missing monitors hydration alongside existing roles/systems fields during client creation and refresh. No schema changes or control-flow changes were introduced, and the new field maps directly to an existing user attribute (stewarded_monitor_ids).
• No files require special attention

Important Files Changed

Filename	Overview
src/fides/api/oauth/utils.py	Populate in-memory ClientDetail.monitors when creating a temporary login-flow user.
src/fides/service/user/user_service.py	Ensure ClientDetail.monitors is set from user.stewarded_monitor_ids on client creation and refresh during login.

[greptile-apps]

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[adamsachs]

@greptile

[greptile-apps]

_{2 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[vcruces]

LGTM! Very simple change