Prune managed-voice daily counters after 90 days
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 45/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- typescript
- Bereich
- backend, databases, documentation
Rechercherichtung
Read hosted/server/runtime-roles.sql and the "Managed voice" section in docs/specs/hosted.md to understand the runtime permissions and history-sweep constraint; then inspect the voice Worker's speak-request transaction and scheduled-job entry points. Choose between the two approaches described in the issue, prune dormouse_voice_usage rows older than 90 days, and update the retention sentence in website/src/pages/Privacy.tsx; done means pruning is implemented and the policy states the 90-day bound.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
dormouse_voice_usage keeps one (userId, day, count) row per subscriber per UTC day, and nothing deletes them before account deletion. The fair-use cap only reads today's row, so older rows serve no purpose. Keeping them indefinitely is a GDPR storage-limitation weak spot, and it makes the Privacy policy's retention sentence longer than it needs to be.
Prune rows older than 90 days. The voice Worker's runtime role has no DELETE grant (hosted/server/runtime-roles.sql), and docs/specs/hosted.md → "Managed voice" keeps the history-sweep cron off the database, so choose between:
- a
DELETEgrant plus pruning that piggybacks on the speak request's existing transaction, or - a separate scheduled job that runs as the migration role.
When this lands, change "Account-linked daily voice counters currently remain until account deletion" in website/src/pages/Privacy.tsx → "Storage, retention, and security" to the new bound.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 5
- Forks
- 1
- Ø Merge
- 11 Std. 45 Min.
- Gemergte PRs (30 T.)
- 478
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus diffplug/dormouse
-
Schwierigkeit 3/5 Ein halber Tag Anfängerfreundlichkeit 25/100
diffplug/dormouse#1393 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 1/100
diffplug/dormouse#1383 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 35/100
diffplug/dormouse#1373 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 4/5 1-2 Tage Anfängerfreundlichkeit 25/100
diffplug/dormouse#1235 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 4/5 1-2 Tage Anfängerfreundlichkeit 48/100
diffplug/dormouse#1234 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in diffplug/dormouse
Ähnliche Issues
-
New icon: `filter-clear`Offencalcite-ui-icons enhancement impact - p3 - not time sensitive needs triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 67/100
Esri/calcite-design-system#15467 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
diegosouzapw/OmniRoute#18390 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
-
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 86/100
guilhermerodz/input-otp#157 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
davidjerleke/embla-carousel#1414 ·
Maintainer antworten meist innerhalb von 4 Tagen