-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TCF Backend #3804
TCF Backend #3804
Conversation
- Privacy Notices are not needed for the TCF Experience. Instead, the content is generated at runtime by looking at what TCF data uses are on current systems. - Add a new experience type: the TCF overlay. - Expands the abilities to retrieve and save consent preferences with respect to "vendors", "data_uses" and "features", not just "privacy notices". - Relaxes constraints on PrivacyPreferenceHistory, ServedNoticeHistory, CurrentPrivacyPreference, and LastServedNotice to use these tables to store when preferences were saved and served against not just notices, but vendors, data uses, and features.
…s/vendors. Improve logic around loading tcf data uses.
… need to track consent mechanism, enforcement level, or has_gpc_flag. - Start drying up code related to saving privacy preferences and unit testing w.r.t data use, vendor, or feature.
Passing run #4242 ↗︎
Details:
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. |
…notices were served for various identities. Refactor methods now that we're sharing a lot of code here.
…s on getting settings.
- Split TCF schemas into their own file - Add test verifying that we can't create PrivacyPreferenceHistory records against multiple preference types. - Rename schemas for saving/serializing that notices were served to be more generic. - Write unit test for saving that tcf items were served.
…with many data uses, rather than a "data use" directly, as a purpose can be associated with many data uses. - Temporarily pin to a fideslang commit on a branch and pull in the tcf purpose mapping from there.
…thod. - Fix bug with saving current privacy preferences with respect to a special purpose and special feature.
- Fix duplicate region in EEA_COUNTRIES - Add test for ConsentSetting model - Add test for PrivacyExperience.get_should_show_banner in the case where it is a TCF overlay - I return True here - Add test for PrivacyExperience.get_related_privacy_notices for TCF overlay - exits early with an empty list - not relevant here! - Add method tests for cache_saved_and_served_on_consent_record for special purpose, notice, and vendor - Add docstrings to TCF schemas and move TCFExperienceContents out of the file for schemas that are returned via the API - Add test for PrivacyPrefenceHistory.preference_type property - Add some checks on PrivacyPreferenceHistory and CurrentPrivacyPreference records on create - Rename PreferenceType enum and preference_type property to be more generic since they're also shared with served notices - Docstrings for schemas - Updated to TCF_COMPONENT_MAPPING and TCF_PREFERENCES_FIELD_MAPPING - Add test for privacy_notice_id - that it works w/ TCF too
- Added more fields to the vendor record - "has_notices" flag now also takes into account if TCF content exists too. - Tried to take care of areas accessing info off of the privacy notice history - "relevant_systems" definition has changed, and also now factors in TCF components. - Fix bug where wrong field is returned in historical report - Add validation on purposes and special purposes and duplicates for both saving preferences and serving TCF components - Surface tcf version in consent report
- Fix bug related to Consent Settings scope name, copy/paste error - Fix test that relaxes returning systems as related even if they do not have system wide enforcement
…ng) work with TCF without error. - Don't return TCF data in the privacy center unless TCF is turned on. (hopefully the FE is just looking at privacy preferences saved against notices).
@adamsachs hoping you could review TCF backend this week! I've added vendors, features/special features, and did a sweep to see what remaining items needed to be addressed regarding code sharing with notices/experiences and the new tcf components. I'll annotate the PR with areas to focus on tomorrow 9/5 |
src/fides/api/alembic/migrations/versions/66df7d9b8103_add_tcf_columns.py
Outdated
Show resolved
Hide resolved
TODO:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pattisdr high level this is looking great! nothing stands out to me as particularly problematic.
i still haven't been able to get down to the level of detail i'd like to in a few areas, namely around the TCF overlay rendering logic. i do think that's worth a thorough review, i just didn't get the time for it today. i'll look to circle back to that on monday, but in the mean time wanted to leave you with some of the comments i had in the meantime!
src/fides/api/alembic/migrations/versions/66df7d9b8103_add_tcf_columns.py
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK! i took a deeper dive into the TCF overlay population logic and it looks great 👍 really nice job taking a lot of care to get that right, there's a lot packed in there.
i just had some minor comments that may help to improve readability, though by and large this is quite readable for the complexity involved.
i'd also like to get your thoughts on the broader comment i have about a future refactor, it'd be good to align on how we see this shaping up for future iterations!
# Conflicts: # requirements.txt Pin fideslang to TCF work branched off of 1.4.6. Bump downrev of tcf columns.
- Removing auto-generated messaging template commits from my already-large migration. - Revert consent settings endpoint to being public again - Add an alias to for has_notices query param. - Try to better clarify when saving TCF preferences that nothing is saved if preferences are an empty list. - Fix mypy region issue - Add code comments to automatically generated migration that adds a lot of new columns - Get rid of _clone_top_level_record_then_add_legal_bases function - Add assert_length_of_tcf_sections helper, and add an auto use fixture for clearing the cache - "..ad_serving" is not a fideslang data use
# Conflicts: # requirements.txt # tests/fixtures/application_fixtures.py
- Update features to v3 - Get rid of lru_cache. - Rearrange where we're extending legal bases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we're ready to go! amazing work, this is a milestone PR. really exciting to have this coming into main
! 🙌
thanks for bearing with me on some of the nits 😄
great thanks for your comments @adamsachs plan to merge tomorrow after 2.20 is released |
…ven (#3870) Co-authored-by: eastandwestwind <[email protected]> Co-authored-by: Adam Sachs <[email protected]>
Getting up to date with main again, error with migration heads - |
Conflicts: Changelog, migrations.
Closes #3817
Closes #3822
Closes #3876
Closes #3935
Closes https://github.com/ethyca/fidesplus/issues/1051
❗ Contains migration; bump downrev before merge
Description Of Changes
Adds the backend for being able to build a TCF overlay.
Importantly:
Code Changes
has_notices
param's meaning has been extended to mean "does the experience have content?" - so does it have notices or TCF contentembed_experience_details
that either populates the Experience with either TCF content, or with notices (existing behavior), depending on the type of experiencecache_saved_and_served_on_consent_record
that pulls previous records where consent was saved and served both for privacy notices or individual TCF componentspurpose
,special_purpose
,feature
,special_feature
,system
andvendor
columns added to PrivacyPreferenceHistory (tracks all saved preferences), ServedNoticeHistory (tracks all served records), CurrentPrivacyPreference (tracks most current preference across version/time/multiple identities for the same user), and LastServedNotice (tracks most current served across version/time/multiple identities) tables to record serving or saving consent against individual TCF components, not just privacy noticesupsert_last_saved_record
to be more generic - we have records of when consent was last saved or served to make for a faster query when building Experiences. These records are upserted every time consent is saved or served. Modify to share between notices and individual TCF componentsPrivacyPreferenceHistory.relevant_systems
column to be any systems related to that preference calculated at runtime, removing the logic that it needed to be a system for which we were also propagating backend consentSteps to Confirm
vendor_id
to the system in the backend. Otherwise it will show up under "tcf_systems"Pre-Merge Checklist
CHANGELOG.md