Upgrade Privacy Request table to use FidesTable V2

[gilluminate]

Closes PROD-1786

Description Of Changes

Update the privacy request screen to utilize the new table

Code Changes

• Replace old, hard-coded table with FidesTable v2
• move filters to a modal
• create new MultiSelectTag component for filtering by multiple values per column
• enable server-side sorting
• clean up header actions for consistency and better UI

Steps to Confirm

• visit Privacy Requests page in Admin UI /privacy-requests
• When I click each row I am taken to the details view of the privacy request
• Filter button opens the filter modal
• All existing filters are modeled in the modal.
• All data currently represented in the table is migrated to the new table.

Pre-Merge Checklist

• All CI Pipelines Succeeded
• Issue Requirements are Met
• Relevant Follow-Up Issues Created
• Update CHANGELOG.md

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
fides-plus-nightly	⬜️ Ignored (Inspect)	Visit Preview		Jun 17, 2024 9:47pm

[cypress]

Passing run #8356 ↗︎

0	4	0	0	0
⚠️ You've recorded test results over your free plan limit. Upgrade your plan to view test results.

Details:

Merge bcf2379 into 3400848...
Project: fides	Commit: 0a511c4fbb ℹ️
Status: Passed	Duration: 00:34 💡
Started: Jun 17, 2024 9:58 PM	Ended: Jun 17, 2024 9:59 PM

Review all test suite changes for PR #4990 ↗︎

[jpople]

Question for you, is there a significant difference between TS interfaces and types for component props?

[gilluminate]

Great question.

Yes and No. The general rule is "use interface until you need type". Not a very big difference, especially if you aren't exporting it. If exporting, you run the risk of 2 interfaces with the same name conflicting (extending) one another accidentally, where that's not possible with type.

For example:

interface Props {
  prop1: boolean;
}
interface Props {
  prop2: string;
} 

creates the equivalent of

interface Props {
  prop1: boolean;
  prop2: string;
}

if those were both using type then only prop2 would apply.

I think the main reason our app is inundated with type is because there is no naming convention and just plain old Props is being used everywhere, which was likely creating the scenario where they were accidentally extending each other.

I prefer interface for components because a) if you are consistent with naming conventions (eg. ${componentName}Props) and never export them unless absolutely necessary (rare) then the general rule "use interface until you need type" applies. b) this is what most component libraries are using (see Chakra's components, eg. BoxProps) so extending those with like definitions feels cleaner. c) nitpicky: it's more clear to use extends than & IMO.

[jpople]

This is all looking good to me-- one small suggestion, I feel like there should be a fallback of some kind for the "Days left" and "Actions" cells when those aren't applicable? From this I feel like it's not completely clear whether these are supposed to be empty or not.

[cypress]

Passing run #8357 ↗︎

0	4	0	0	0
⚠️ You've recorded test results over your free plan limit. Upgrade your plan to view test results.

Details:

Upgrade Privacy Request table to use FidesTable V2 (#4990)
Project: fides	Commit: d864095084
Status: Passed	Duration: 00:34 💡
Started: Jun 17, 2024 10:30 PM	Ended: Jun 17, 2024 10:30 PM

Review all test suite changes for PR #4990 ↗︎