feat: infra monitor details tray [ENG-3119]

[speaker-ender]

Ticket ENG-3119

Description Of Changes

• Added a drawer for Idp monitor results in the action center
• Allowing item actions from within details drawer
• Allowing editing of descriptions from within details drawer

Code Changes

Steps to Confirm

1. Create an idp monitor
2. Go to the action center and navigate to that monitor screen
3. Click the title of a monitor result
4. Verify that the details are displayed correctly for that system
5. Test that updating the data uses and descriptions from within the details drawer function correctly

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.

Project	Deployment	Actions	Updated (UTC)
fides-plus-nightly	Ready	Preview, Comment	Apr 24, 2026 1:51pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
fides-privacy-center	Ignored		Apr 24, 2026 1:51pm

[github-actions]

Title	Lines	Statements	Branches	Functions
admin-ui		6.31% (2799/44303)	5.56% (1402/25209)	4.41% (579/13105)
fides-js		79.39% (2011/2533)	65.99% (1240/1879)	73.09% (345/472)
privacy-center		85.97% (331/385)	81.36% (179/220)	78.87% (56/71)

[gilluminate]

Had to do a bit of digging to see what this was all about. Seems that preferred_description is just not being auto-generated in the API response types? Should we just extend that Type instead of adding this complexity?

[speaker-ender]

I'm willing to add it as an extension if you think that's best.
Even though ugly, this is safer and won't break the FE if there is a BE change to the types and we continue using our modified types.

[gilluminate]

Aren't we just saying that if preferred_description goes missing, nothing breaks? If so, doesn't that obfuscate the problem instead of an error letting us know there's a problem? Regardless, I think item.preferred_description ?? "" would prevent an error.

[speaker-ender]

It's not just protecting if preferred_description goes missing, it's also protecting if the type changes to something that can't be rendered to the dom and causes a crash.
IMO the ideal solution (outside of the BE fixing the types) would be to have a runtime transformer that allows us to centralize the patches + run validation so we can have graceful fallbacks and try to set up some kind of notification that the types are wrong.
I tend to lean toward obfuscations that don't crash in production if not caught over a little less visibility into missing renders.
Totally open to arguments to the contrary