Admin UI: Define Specific Publisher Restrictions

[gilluminate]

Closes LJ-593

Description Of Changes

This PR introduces comprehensive TCF configuration management features to the admin UI consent settings page. The changes focus on implementing publisher restrictions, purpose restrictions, and TCF configuration management capabilities. Legacy publisher restrictions are still supported if those are already enabled, giving the user the option to remove those and start over with the new options (see this loom https://www.loom.com/share/903d538e0323444f9766f9742be82962?sid=57b3c17e-1b77-45e9-afe9-9185357deab3) for an example.

Code Changes

• Added new TCF configuration management components:

  • TCFConfigurationDropdown for selecting and deleting TCF configs
  • CreateTCFConfigModal for creating new TCF configurations
  • PublisherRestrictionsConfig and related tables for managing restrictions
  • TCFOverrideToggle as a shared component between legacy and new UX

• Implemented publisher restrictions functionality:

  • Added validation utilities for vendor IDs and ranges
  • Created components for managing purpose and publisher restrictions
  • Added tables and forms for configuring restrictions

• Added state management and API integration:

  • New TCF configuration slice in Redux store
  • API endpoints for configurations and publisher restrictions
  • Autogenerated Types and interfaces for related data structures

Steps to Confirm

Enable TCF and configure a TCF experience

---

Test TCF configurations from the main consent setting screen:
2. Navigate to the consent settings page in the Admin UI (/settings/consent)
3. If consent configs already exist, you should still see the old table (see https://www.loom.com/share/903d538e0323444f9766f9742be82962?sid=57b3c17e-1b77-45e9-afe9-9185357deab3). Otherwise you'll be given the option to enable overrides and to create a new config.
4. Verify ability to create, select, and delete TCF configurations from the main screen.

• Enable the Override vendor purposes toggle which should bring up a few more lines of test and a button.
• Click the "Learn more about publisher restrictions" link and make sure it goes where it's supposed to.
• Click the "Create configuration +" button
• Give your config a name and save it. (you should see the table appear below)
• Add another
• Switch between the 2 using radio button + "apply"
• delete one or both

5. Verify the Faux table for TCF Publisher restrictions that appears looks right

• This is not a real table but a set of Flexbox rows/cells so just make sure borders align, etc.
• When a config is first created, all purposes should have "none" in the Restrictions column.
• Purposes 1, 3, 4, 5, and 6 should have "No" in the Flexible column and should not have an "Edit" button in the Actions

---

Test creating and managing publisher restrictions for one or more of the flexible purposes:

1. Click the "Edit" button, which takes you to a new Consent Configuration page
2. Ensure the breadcrumbs work well and look correct
3. Ensure the TCF Purpose box has a number, name, and description
4. The name you gave your config should be the title of the 2nd instruction box. Click the "Learn more about publisher restrictions" link and make sure it goes where it's supposed to.
5. Click "Add restriction +" (or "Add +" in the table below...they should both open the same thing)
6. Choose any of the Restriction types, and then choose "Restrict all vendors" from the Vendor restriction select and click save.

• Your selection choices should be reflected as a single row in the table and the "Add restriction +" should now be disabled with a tooltip on hover. (You can edit or delete that restriction, but any time "Restrict all vendors" is chosen you should not be able to add any other restrictions.)

7. Delete or edit that previous entry and this time instead of "Restrict all vendors" choose "Restrict specific vendors". This will cause a new field to appear. Follow the instructions on how to add vendors to that field (add as tags, for example "10" and "100-200" can be added)

• Now when saved, the "Add restriction +" button should be enabled. You should see the data you entered reflected in the single row.

8. Add another restriction

• The Restriction type created before should now be disabled (you can only ever have one type active at a time)
• Choose "Restrict specific vendors" again and test out the form validation:
  • any same number or number within a range should throw an error (if 10, 100-200 was chosen above, 10 should throw an error, and 150 should also.) No vendor should be able to be restricted for more than one Restriction type!
• Before saving, test the validation for "Allow specific vendors" which should behave the opposite of the restriction as far as valid ranges go. You can pick numbers within restricted ranges (or single IDs), but nothing outside those numbers.
• Once you have a valid set of numbers/ranges, save the new restriction

9. Use the breadcrumb to go back to the consent settings page and make sure the Restrictions column for the purpose you just edited says "2 restrictions"
10. Do similar for other flexible purposes and ensure they behave correctly and appear correctly in the tables.

---

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
• 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 Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
fides-plus-nightly	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 9, 2025 11:47pm
fides-privacy-center	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 9, 2025 11:47pm

[jpople]

Changes overall look good-- nitpicky, but in a few spots some text needs to be appropriately sentence-cased.

I think the "Vendor IDs" input has some issues though:

• I don't think "Enter a single ID or range of IDs and press enter" is the most helpful as a placeholder-- it's unclear to me that that means I can enter multiple single IDs or ranges, and also that the ranges are meant to be in exactly the format "##-##". I would prefer something like:

Enter IDs or ranges (e.g. "1-10") and press enter

• I think validation/feedback is also a bit lacking-- if I put something invalid, the backend just throws an error but it might be hard to know from this exactly what I did wrong. It'd be helpful to have at least an error status on the field and a generic error message in this case, if not something more specific.

• I'm also getting a seemingly-incorrect error message in one case; if I add a "restrict specific vendors" restriction and then try to add an "allow specific vendors", I get the overlap error message and can't submit even when none of the entered IDs overlap with the restricted ones.

[jpople]

In testing it felt like some feedback would be nice here-- a toast, or maybe even fake a loading state for a moment?

[gilluminate]

@jpople "Allow" is the exact opposite of "Restrict." So to allow something is to restrict everything else. That's why the ranges behave that way, any Allow along-side a restrict must be a value within the restrict ranges when it's set on another restriction type. Hope that helps.

[gilluminate]

@jpople There's a bug in my FE validation that's letting it get through and then the BE is catching it. I'll address that bug.

[gilluminate]

@jpople Thanks for the feedback. I've updated the titles with sentence-case, updated the Vendor IDs field with better instructions/restrictions, as well as fixing the Allow list validations to match the Backend validation. Ready for another review.

[jpople]

Thanks for the changes, tested locally and everything's looking good to me.

[cypress]

fides    Run #12802

Run Properties:   Passed #12802  •  4db1eeea97: Admin UI: Define Specific Publisher Restrictions (#6013)

Project	fides
Branch Review	main
Run status	Passed #12802
Run duration	00m 50s
Commit	4db1eeea97: Admin UI: Define Specific Publisher Restrictions (#6013)
Committer	Jason Gill
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	0
Pending	0
Skipped	0
Passing	5
View all changes introduced in this branch ↗︎