RunicGateway/runicgateway.com
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(site): /privacy tells the truth about engagement retention again
All checks were successful
PR checks / checks (pull_request) Successful in 1m23s
Details

Browse Source 
ENGAGEMENT.md Phase 14. The deploy-engagement entry in the collection
inventory said "Kept until the operator removes them; nothing here expires
on its own" and, in its detail, "the delivery log, the suppression list and
the per-person rate limits have no retention sweep, so they are as long as
the site is old". That was the true answer until Phase 14 landed a sweep,
and it is the kind of sentence a Play reviewer reads.

It now describes what the code does: a nightly sweep with an
operator-settable horizon per table (180 days for the delivery log, 30 for
the queue and the rate limits), and the two things that deliberately do NOT
expire — an item still waiting to be sent, because it is a message the site
still intends to deliver, and the suppression list, because ageing an entry
out would mean mailing an address that already bounced.

PLAY_DATA_SAFETY.md is unchanged and check:datasafety stays green:
deploy-engagement is deployment-scoped, and the Play answers are generated
from the app-scoped entries, because Play asks what the app collects rather
than what a self-hosted deployment keeps.

All ten checks green, 42 tests pass.

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
claude
2026-09-01 15:41:14 -05:00
parent a0af01026e
commit 82b55e3084
1 changed files with 14 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
src/data/collection.mjs
View File

@@ -452,17 +452,24 @@ export const collected = [
'operator can see what was suppressed without the list becoming a second address ' +
'book.',
retention: {
summary: 'Kept until the operator removes them; nothing here expires on its own',
summary:
'The delivery log is kept for a period the operator sets (180 days by default) and then ' +
'swept; the suppression list does not expire',
detail:
'Stated plainly because it is the answer people assume the other way round: ' +
'the delivery log, the suppression list and the per-person rate limits have no ' +
'retention sweep, so they are as long as the site is old. Deleting an account ' +
'detaches its rows from it rather than deleting them — a delivery history stops ' +
'naming a person, and a suppressed address stays suppressed.',
'A nightly sweep removes delivery-log entries, finished items from the send queue and the ' +
'per-person rate-limit rows once they pass the horizon the operator has set for each — ' +
'the defaults are 180 days for the log and 30 for the other two. Two things deliberately ' +
'do not expire. An item still waiting to be sent is never swept however old it is, ' +
'because it is a message the site still intends to deliver. And the suppression list is ' +
'permanent by design: it records a standing decision to stop mailing an address, and ' +
'ageing an entry out would mean mailing an address that already bounced or asked to be ' +
'left alone. An operator can remove an entry from it deliberately, one at a time. ' +
'Deleting an account detaches its rows from it rather than deleting them — a delivery ' +
'history stops naming a person, and a suppressed address stays suppressed.',
},
source:
'website server/db/schema.sql — engagement_sends, engagement_suppressions, ' +
'notification_channel_prefs',
'notification_channel_prefs; server/src/utils/engagementRetentionPrune.js',
},
{
id: 'deploy-game-data',