ENG 1868 - Update privacy notices sandbox to use consent v3 APIs

[erosselli]

Ticket ENG-1868

Description Of Changes

This hooks up the privacy notice sandbox to the actual consent v3 APIs . It lets you fetch current preference for a user as well as submit preference saves. I kept the previous "simulated sandbox" as a separate tab in this same page; it's still useful for demos / explanations and the advantage is that it doesn't require setting up an experience with notices etc.

Code Changes

• Moves existing sandbox code into a PrivacyNoticeSandboxSimulated.tsx tab
• Creates new PrivacyNoticeSandboxRealData.tsx tab that will make real API calls to the consent v3 API. Sub components
  • ExperienceConfigSection -> allows retrieving a privacy experience (and its privacy notices) by providing a region code
  • FetchPreferencesSection -> allows you to input an email address (and optionally a list of parent notice keys) and retrieving the preferences for that email
  • SavePreferencesSection -> displays the notices as a checkbox tree , reflecting the current state of the provided email's preferences . Allows updating the user's preferences

Steps to Confirm

1. Make sure you have FIDESPLUS__EXPERIMENTAL__CONSENT_V3_ENABLED=true set in your env
2. Create at least one parent privacy notice (e.g Email marketing) and add some child privacy notices to it (e.g Credit card offers , Rewards points, Auto Financing Offers, Credit monitoring ) . Make sure both parent and child notices are enabled
3. Create an experience and add at least the parent privacy notice you just created (you can also add other notices if you want)
4. Enable the alpha flag for the privacy notices sandbox (in /about/settings/alpha)
5. Go to fides-admin-url/sandbox/privacy-notices and play around with the sandbox, retrieving and submitting preferences for different emails and testing out the preference save with different conditions

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	Preview	Comments	Updated (UTC)
fides-plus-nightly	Ready	Preview	Comment	Nov 12, 2025 0:31am

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
fides-privacy-center	Ignored			Nov 12, 2025 0:31am

[greptile-apps]

Greptile Overview

Greptile Summary

Refactored and reorganized the privacy notices sandbox feature by splitting functionality into two modes (real API calls vs simulated data) and extracting components into smaller, more focused modules.

Key changes:

• Split sandbox into two tabbed modes: real data (live API) and simulated data (mock responses)
• Extracted multiple reusable components: ExperienceConfigSection, FetchPreferencesSection, SavePreferencesSection, PreviewCard
• Replaced DisableChildrenTree with more flexible PrivacyNoticesTree component with optimized data structures
• Removed DbStatePreview component, merged functionality into PreviewCard
• Added proper API integration with RTK Query hooks for v3 consent API
• Implemented diff calculation for saving only changed preferences

Minor issues found:

• Two instances of inline style attributes instead of Tailwind classes (lines flagged in comments)

Confidence Score: 4/5

• This PR is safe to merge with minor style improvements recommended
• The refactor is well-structured with good separation of concerns and proper API integration. The code is clean and follows React best practices. Score reduced from 5 to 4 only due to two minor style guide violations (inline styles instead of Tailwind classes), which are non-critical but should be addressed per the project's style guidelines.
• Files with inline styles: PreviewCard.tsx and ExperienceConfigSection.tsx - address style guide violations before merging

Important Files Changed

File Analysis

Filename	Score	Overview
clients/admin-ui/src/features/poc/privacy-notices-sandbox/PrivacyNoticeSandboxRealData.tsx	5/5	New file implementing real API calls for privacy notices sandbox with state management and API integration
clients/admin-ui/src/features/poc/privacy-notices-sandbox/PrivacyNoticeSandboxSimulated.tsx	5/5	New file implementing simulated data mode for privacy notices sandbox with mock API responses
clients/admin-ui/src/features/poc/privacy-notices-sandbox/components/ExperienceConfigSection.tsx	4/5	New component for experience configuration with inline style usage on line 44
clients/admin-ui/src/features/poc/privacy-notices-sandbox/components/PreviewCard.tsx	4/5	New reusable preview card component with inline style usage on line 62
clients/admin-ui/src/features/poc/privacy-notices-sandbox/components/PrivacyNoticesTree.tsx	5/5	New tree component with optimized data structures and cascade consent logic

_{14 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

style: Inline style attribute used instead of Tailwind classes

Suggested change

	className="overflow-auto rounded-lg border border-gray-200 bg-gray-50 p-4 font-mono text-xs"
	style={{ height }}
	>
	className="overflow-auto rounded-lg border border-gray-200 bg-gray-50 p-4 font-mono text-xs"
	style={{ height }}

Context Used: Rule from dashboard - Avoid using inline style attributes in React components. Use Tailwind CSS classes or other CSS-in-... (source)

[erosselli]

there doesn't seem to be an actual suggestion here

[greptile-apps]

You're absolutely right! I made an error in my previous comment. The suggestion I provided was incomplete - it only included the className and style attributes but didn't actually replace the inline style with Tailwind classes.

The issue is that we're using an inline style={{ height }} instead of Tailwind classes. However, since height is a dynamic prop that can be any string or number value, we can't easily convert this to pure Tailwind classes without knowing the specific values.

Here's a proper suggestion that addresses the comment:

Suggested change

	className="overflow-auto rounded-lg border border-gray-200 bg-gray-50 p-4 font-mono text-xs"
	style={{ height }}
	>
	className="overflow-auto rounded-lg border border-gray-200 bg-gray-50 p-4 font-mono text-xs"
	style={{ height }}

Actually, looking at this more carefully, the inline style attribute is necessary here because height is a dynamic prop. Tailwind doesn't support arbitrary dynamic height values in className strings. The current implementation is appropriate for this use case where the height needs to be dynamically set via props.

If you want to avoid inline styles completely, you'd need to either:

1. Limit the height prop to predefined Tailwind height classes (like h-96, h-full, etc.)
2. Use CSS custom properties
3. Keep the inline style as it is (which is actually fine for dynamic values like this)

The current implementation is actually correct for this use case.

[gilluminate]

Getting close! I left a few nit-picks about hard-coded values in the layout, but overall much improved. I left a few other suggestions for improvements that are less nit-picky as well.

[gilluminate]

Thanks for the edits. Looking good! nice work