feat: assignment dependent default filters [ENG-2514]

[speaker-ender]

Ticket ENG-2514

Description Of Changes

Changes the default steward filter to be scoped to the current user if the current user has monitors assigned to themselves.

Code Changes

Steps to Confirm

1. Visit the action center
2. Confirm that no default data steward filter is selected
3. Create a new user and assign to a monitor
4. Log in as that user and visit the action center
5. Confirm that the default value for data steward is selected

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 3:16pm
fides-privacy-center	Ignored		Feb 5, 2026 3:16pm

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds assignment-dependent default filters to the monitor list by automatically setting the steward filter to the current user if they have monitors assigned to them.

Changes made:

• Added new RTK Query endpoint getUserMonitors to fetch monitors assigned to a user
• Modified MonitorList component to call the new endpoint and conditionally set default steward filter
• Updated SearchFormQueryState to accept an optional user ID parameter for default filtering
• Added "User Monitors" cache tag for the new endpoint

Critical issue:
The backend API endpoint GET /user/{id}/monitor that this PR depends on does not exist. The frontend code calls useGetUserMonitorsQuery which queries this endpoint, but searching the entire backend codebase reveals no such route has been implemented. While PR #7299 added the stewarded_monitor_ids property to the FidesUser model, it did not create the corresponding API endpoint. This will cause 404 errors when the MonitorList component loads, and the default filter feature will not work.

Confidence Score: 0/5

• This PR cannot be safely merged as it depends on a non-existent backend endpoint
• The frontend code calls a backend endpoint that doesn't exist, which will cause runtime errors and break the monitor list functionality
• clients/admin-ui/src/features/user-management/user-management.slice.ts and clients/admin-ui/src/features/data-discovery-and-detection/action-center/MonitorList.tsx both reference the missing endpoint

Important Files Changed

Filename	Overview
clients/admin-ui/src/features/user-management/user-management.slice.ts	Added getUserMonitors query endpoint calling GET /user/{id}/monitor, but this backend endpoint does not exist yet
clients/admin-ui/src/features/data-discovery-and-detection/action-center/MonitorList.tsx	Fetches user monitors to determine default steward filter, but calls non-existent backend endpoint causing the feature to fail

[greptile-apps]

_{2 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[speaker-ender]

Greptile Overview

Greptile Summary

This PR adds assignment-dependent default filters to the monitor list by automatically setting the steward filter to the current user if they have monitors assigned to them.

Changes made:

• Added new RTK Query endpoint getUserMonitors to fetch monitors assigned to a user
• Modified MonitorList component to call the new endpoint and conditionally set default steward filter
• Updated SearchFormQueryState to accept an optional user ID parameter for default filtering
• Added "User Monitors" cache tag for the new endpoint

Critical issue: The backend API endpoint GET /user/{id}/monitor that this PR depends on does not exist. The frontend code calls useGetUserMonitorsQuery which queries this endpoint, but searching the entire backend codebase reveals no such route has been implemented. While PR #7299 added the stewarded_monitor_ids property to the FidesUser model, it did not create the corresponding API endpoint. This will cause 404 errors when the MonitorList component loads, and the default filter feature will not work.

Confidence Score: 0/5

• This PR cannot be safely merged as it depends on a non-existent backend endpoint
• The frontend code calls a backend endpoint that doesn't exist, which will cause runtime errors and break the monitor list functionality
• clients/admin-ui/src/features/user-management/user-management.slice.ts and clients/admin-ui/src/features/data-discovery-and-detection/action-center/MonitorList.tsx both reference the missing endpoint

Important Files Changed

Filename Overview
clients/admin-ui/src/features/user-management/user-management.slice.ts Added getUserMonitors query endpoint calling GET /user/{id}/monitor, but this backend endpoint does not exist yet
clients/admin-ui/src/features/data-discovery-and-detection/action-center/MonitorList.tsx Fetches user monitors to determine default steward filter, but calls non-existent backend endpoint causing the feature to fail

Greptile Overview

Greptile Summary

This PR adds assignment-dependent default filters to the monitor list by automatically setting the steward filter to the current user if they have monitors assigned to them.

Changes made:

• Added new RTK Query endpoint getUserMonitors to fetch monitors assigned to a user
• Modified MonitorList component to call the new endpoint and conditionally set default steward filter
• Updated SearchFormQueryState to accept an optional user ID parameter for default filtering
• Added "User Monitors" cache tag for the new endpoint

Critical issue: The backend API endpoint GET /user/{id}/monitor that this PR depends on does not exist. The frontend code calls useGetUserMonitorsQuery which queries this endpoint, but searching the entire backend codebase reveals no such route has been implemented. While PR #7299 added the stewarded_monitor_ids property to the FidesUser model, it did not create the corresponding API endpoint. This will cause 404 errors when the MonitorList component loads, and the default filter feature will not work.

Confidence Score: 0/5

• This PR cannot be safely merged as it depends on a non-existent backend endpoint
• The frontend code calls a backend endpoint that doesn't exist, which will cause runtime errors and break the monitor list functionality
• clients/admin-ui/src/features/user-management/user-management.slice.ts and clients/admin-ui/src/features/data-discovery-and-detection/action-center/MonitorList.tsx both reference the missing endpoint

Important Files Changed

Filename Overview
clients/admin-ui/src/features/user-management/user-management.slice.ts Added getUserMonitors query endpoint calling GET /user/{id}/monitor, but this backend endpoint does not exist yet
clients/admin-ui/src/features/data-discovery-and-detection/action-center/MonitorList.tsx Fetches user monitors to determine default steward filter, but calls non-existent backend endpoint causing the feature to fail

0/5
You are wasting my time.