ENG-3447: Add att_exempt field to PrivacyNotice#8029
Conversation
Adds a boolean att_exempt column to privacynotice, privacynoticehistory, and privacynoticetemplate. When false (default), the notice is controlled by Apple's ATT prompt — automatically disabled and locked when the user denies tracking. When true, the notice is exempt and remains user-toggleable regardless of ATT. Includes Alembic migration and schema update.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8029 +/- ##
=======================================
Coverage 85.19% 85.19%
=======================================
Files 638 638
Lines 42008 42010 +2
Branches 4937 4937
=======================================
+ Hits 35788 35790 +2
Misses 5111 5111
Partials 1109 1109 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
| sa.Column( | ||
| "att_exempt", | ||
| sa.Boolean(), | ||
| nullable=False, |
There was a problem hiding this comment.
I'd argue maybe this should be nullable=True, since some privacy notices (notice-only) cannot be affected by ATT right?
There was a problem hiding this comment.
Notice-only handling isn't a DB concern; it's application logic (filterAttDeniedFromDraft keeps notice_only notices regardless of att_exempt). Making it nullable would introduce ambiguity: what does null mean - unset? exempt? not exempt? — and you'd need null-checks everywhere - null only makes sense from the persepctive of a notice only row, but how it treast this filed is already clear
I'd like to avoid this change for now unless it has some real value, since it adds code risk and change
There was a problem hiding this comment.
That's fine- if not at the BE level, we do need to handle the beginning and end of the flow:
- When a user sets ATT exempt for a notice-only notice, can we at least have some info / help text that says notice-only notices are not affected or something?
- At the end of the flow (Mobile SDK) let's remember to add tests around what we expect for this use case
There was a problem hiding this comment.
- I'll add this into this ticket for when we create the UI
- I will definitely add this test coverage in the final PR #3467
…CHANGELOG.md edit
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
2 participants
Ticket ENG-3447
Description Of Changes
Adds an
att_exemptboolean field to thePrivacyNotice,PrivacyNoticeHistory, andPrivacyNoticeTemplatemodels (viaPrivacyNoticeBase).Behaviour: By default all privacy notices are ATT-controlled (
att_exempt: false) — when a user denies Apple's App Tracking Transparency prompt, the notice is automatically disabled and locked. Settingatt_exempt: truemarks the notice as exempt from ATT, so it remains user-toggleable regardless of the ATT decision.Includes an Alembic migration to add the column to all three tables with
server_default=false.Code Changes
att_exemptBoolean column toPrivacyNoticeBaseSQLAlchemy model (flows toprivacynotice,privacynoticehistory,privacynoticetemplate)att_exempt: bool = FalsetoPrivacyNoticeHistorySchemae3f4a5b6c7d8adding the column withserver_default=falseSteps to Confirm
alembic upgrade head— confirm column appears on all three tables/api/v1/privacy-noticewithoutatt_exempt— confirm response hasatt_exempt: falseatt_exempt: true— confirm it round-trips correctlyPre-Merge Checklist
CHANGELOG.mdupdatedmaindowngrade()migration is correct and works