Fides-js consent reporting calls

[allisonking]

Closes #3780

Description Of Changes

Adds calls to consent reporting in fides-js! We need fides-js to make one extra PATCH call to a new /notices-served endpoint when the modal is showing.

This patch returns a list of served notice IDs, which needs to go into the existing PATCH to user preferences.

Code Changes

• Update typescript types
• Add a new Fides event FidesUIShown. I thought this would be a clean way to implement this feature since we only want to patch when the UI is shown (specifically, the modal). Also, I think we'll need this event for TCF work, so I thought it made sense to try it out now.
  • Since this event needed some more data, I updated the payload of a FidesEvent to take the whole cookie object as well as extraDetails
• Call this event when banner or modal are opened up
• Add a hook useConsentServed which checks if this was from the modal, then issues the patch
• Add served notices to the PATCH to user preferences
• Cypress tests

Steps to Confirm

• Run the privacy center via turbo dev
• Visit localhost:3000/fides-js-demo.html and open the network tab
• Open the modal
• You should see a call to /notices-served. The payload should have a serving_component of overlay and some other parts that match your data (fides_user_device_id, user geography, etc)
• Now opt out of notices
• Inspect the PATCH to /privacy-preferences and make sure that the preferences has a served_notice_history_id, i.e.

{
  "privacy_notice_history_id": "pri_1a4b36b3-f92a-48f4-9e72-a54ee86e10bb",
  "preference": "opt_out",
  "served_notice_history_id": "ser_d49cb43d-2d42-4e0b-8224-86ef1b527858"
}

Pre-Merge Checklist

• All CI Pipelines Succeeded
• Issue Requirements are Met
• Update CHANGELOG.md

[cypress]

Passing run #3369 ↗︎

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

Details:

Merge eb13cb2 into 6e1b4dd...
Project: fides	Commit: b247811ae9 ℹ️
Status: Passed	Duration: 01:04 💡
Started: Jul 27, 2023 7:57 PM	Ended: Jul 27, 2023 7:59 PM

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

[eastandwestwind]

Leaving a note that I've manually tested this PR and it works for me:

[pattisdr]

Trying to get this working for testing too!

[pattisdr]

This looks really nice @allisonking! I verified that all of the appropriate columns are being filled out in the backend - saving that a notice was served creates two records, a ServedNoticeHistory (for every single time a notice served) as well as upserts a LastServedNotice that consolidates the last time a notice was served across versions/across time/across different identities of the same user. All of that looked good to me here - Verified that things look good on the backend too when you save preferences -

How do you keep everything matched up on the FE?

[allisonking]

This looks really nice @allisonking! I verified that all of the appropriate columns are being filled out in the backend - saving that a notice was served creates two records, a ServedNoticeHistory (for every single time a notice served) as well as upserts a LastServedNotice that consolidates the last time a notice was served across versions/across time/across different identities of the same user. All of that looked good to me here - Verified that things look good on the backend too when you save preferences -

How do you keep everything matched up on the FE?

Whew, nice! The general flow is:

• when the modal opens, we hit the PATCH /notices-served then we save the response in state. This state is cleared on page refresh
• when the user saves their consent, we pass that saved state along to PATCH /privacy-preferences (matching based on privacy_notice_history_id

let me know if that answers your question?

[pattisdr]

let me know if that answers your question?

Got it that makes sense!