Update privacy experience endpoints to use new experience config

[allisonking]

Closes #3259

Code Changes

Mostly the behavior has not changed, except for the part marked by ❗

• Update autogenerated typescript types
• Update all privacy-experience endpoints to use experience-config endpoints instead. This involved:
  • Updating the urls in the slice and in the tests
  • The new patch and post take a single obj instead of an array, so some adjustments there
  • The new patch requires regions to always be in the payload
  • ❗ Removed form logic which rendered special conditions based on privacy notices. For instance, we originally had "acknowledgment label" replacing "confirmation" and "reject" labels if all notices were notice_only. Since experience configs are now, in the data model, independent of notices, we instead render all form fields and ask for the user to fill them all in.

Steps to Confirm

• You'll need some privacy experiences! First make sure you have some notices, then post an experience config to /api/v1/experience-config Here's one that works

{
  "component_title": "two",
  "component": "overlay",
  "regions": ["us_ca"],
  "delivery_mechanism": "link",
  "link_label": "Manage preferences"
}

• All privacy experience forms should work and persist their data

Pre-Merge Checklist

• All CI Pipelines Succeeded
• Documentation:
  • documentation complete, PR opened in fidesdocs
  • documentation issue created in fidesdocs
• Issue Requirements are Met
• Relevant Follow-Up Issues Created
• Update CHANGELOG.md
• For API changes, the Postman collection has been updated

Description Of Changes

[cypress]

Passing run #2031 ↗︎

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

Details:

Merge c99436d into fffc7eb...
Project: fides	Commit: 6397218397 ℹ️
Status: Passed	Duration: 00:48 💡
Started: May 17, 2023 8:18 PM	Ended: May 17, 2023 8:18 PM

_{This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.}

[pattisdr]

Can we update this copy here in light of trying to keep the ExperienceConfig more separate from the Notices - this is actually a link overlay too with no notices attached.

[pattisdr]

Should we still toggle the fields that are displayed depending on whether "banner" or "link" is selected for an overlay?

If "link" was selected, I might expect banner fields to disappear -

OR! it's possible I misunderstood here and we still need some of these banner fields

[pattisdr]

Could we add a default text if there are no regions attached?

These "default" Experience Configs that Michael is working on wouldn't necessarily have regions out of the box

[pattisdr]

Is there any way to edit regions? This is the main action that attaches a Privacy Experience in the background that the components will use to this Privacy Experience Config. Backend will prevent this from being saved if the regions are invalid for the notices.

[pattisdr]

If I go into a banner overlay and try to update button text, the save button doesn't enable, there's just a few scenarios that seem to cause this.

[pattisdr]

@allisonking thanks for jumping on this to help get the backend mergeable 🎉

[allisonking]

Should we still toggle the fields that are displayed depending on whether "banner" or "link" is selected for an overlay?

If "link" was selected, I might expect banner fields to disappear -

OR! it's possible I misunderstood here and we still need some of these banner fields

Yeah, I remember wondering this too! The designs didn't indicate that so I kept them always showing, but now that I'm touching the component UI side more, I think you're right that we may not need these. We might not even need link_label since now we are having users put in their own link... I'll ask about it!

[allisonking]

Is there any way to edit regions? This is the main action that attaches a Privacy Experience in the background that the components will use to this Privacy Experience Config. Backend will prevent this from being saved if the regions are invalid for the notices.

There isn't right now, that was intentionally left out of scope of this initial version (since users can't make their own privacy experiences). Does that still work with how the new model for experiences?

[allisonking]

If I go into a banner overlay and try to update button text, the save button doesn't enable, there's just a few scenarios that seem to cause this.

it's probably because there's nothing in the required field of "Link label" in this case (the "Save" button is disabled as long as the form is invalid). also, perhaps link label shouldn't be required in this case...

[pattisdr]

There isn't right now, that was intentionally left out of scope of this initial version (since users can't make their own privacy experiences). Does that still work with how the new model for experiences?

I think it would be okay if we get these default Experience Configs in the database that I can link to automatically that Michael's working on. For example, someone creates an overlay Privacy Notice for CA, I create an overlay PrivacyExperience in the backend, and then link it to the "default" overlay PrivacyExperience temporarily. But I think it's functionality we would need soon!

[pattisdr]

it's probably because there's nothing in the required field of "Link label" in this case (the "Save" button is disabled as long as the form is invalid). also, perhaps link label shouldn't be required in this case...

Ah okay, it sounds like on the backend what is "required" for each experience might not be correct on my end then. I was assuming a link label wasn't required for a banner overlay.

[allisonking]

it's probably because there's nothing in the required field of "Link label" in this case (the "Save" button is disabled as long as the form is invalid). also, perhaps link label shouldn't be required in this case...

Ah okay, it sounds like on the backend what is "required" for each experience might not be correct on my end then. I was assuming a link label wasn't required for a banner overlay.

That's probably the correct assumption! I'm starting to think we don't need link label at all, so I'll at least make it not required for now

[allisonking]

Could we add a default text if there are no regions attached?

These "default" Experience Configs that Michael is working on wouldn't necessarily have regions out of the box

Is None ok?

[pattisdr]

Is None ok?

That's great!

[allisonking]

Should we still toggle the fields that are displayed depending on whether "banner" or "link" is selected for an overlay?

If "link" was selected, I might expect banner fields to disappear -

OR! it's possible I misunderstood here and we still need some of these banner fields

Thanks for bringing this up! I think we got this logic sorted out, captured here: #3320

I think I've got most of the things you caught (thanks for the sharp eyes!!), and am thinking I will defer the banner/link conditional rendering logic to #3320 so that we can unblock your backend branch from merging, does that sound okay?

[pattisdr]

that sounds great @allisonking thanks for all your work on this

[pattisdr]

This looks great, so perhaps I just leave the other fields in the backend as they are, and adjust in a followup to go with #3320