Files
dogfather-universe/server/workspace-aufbewahrung.js
T
DogFatherGit dcd0298700 Spenden: vier Knoepfe, eine Karte im Bild -- und die Wahrheit ueber PayPal
Filipe: "ich will dass das richtig perfekt gemacht wird so dass die
leute so einfach wie moeglich eine spende aufs paypal machen koennen.
und wenn jemand spendet soll auch der betrag erscheinen mit einem
bild."

WAS GEHT UND WAS NICHT -- NACHGESEHEN, NICHT ANGENOMMEN

Hinterlegt ist ein PayPal.me-Link auf ein PRIVATES Konto. Daraus
folgt zweierlei, und beides bestimmt den ganzen Aufbau:

  ES GEHT: `paypal.me/<name>/5EUR` oeffnet PayPal mit schon
  eingetragenem Betrag. Ein Tipp, fertig. Belegt an PayPals eigener
  Hilfeseite zu PayPal.Me.

  ES GEHT NICHT VON SELBST: PayPal meldet eine Zahlung nur, wenn ein
  Webhook oder IPN eingerichtet ist -- beides braucht Zugangsdaten,
  die nur Filipe selbst anlegen kann. Ob ein PRIVATES Konto das
  ueberhaupt kann, sagt PayPals eigene Doku nicht eindeutig; ich habe
  es gesucht und nicht gefunden, und etwas zu behaupten, das ich
  nicht belegen kann, waere hier das Gefaehrlichste.

DESHALB DREI HERKUENFTE UND NICHT EINE

  "hand"      Filipe sieht die PayPal-Meldung auf dem Handy und tippt
              den Betrag ins Pult. Geht immer, braucht nichts, ist in
              drei Sekunden getan, und die Karte laeuft sofort.
  "gemeldet"  Der Zuschauer sagt nach dem Spenden selbst Bescheid.
              Landet als OFFEN und wird erst gezeigt, wenn die
              Leitung es bestaetigt.
  "paypal"    Kommt automatisch, sobald ein Webhook eingerichtet ist.
              Bis dahin steht dieser Weg leer da -- die Tabelle und
              die Sperre gegen doppelte Zahlungsnummern sind schon
              fertig.

WARUM EINE MELDUNG NICHT SOFORT ERSCHEINT: Sonst tippt irgendwer
"500 Euro" und steht damit gross im Bild. Eine Spende ist eine
Aussage ueber Geld; die gehoert bestaetigt, bevor sie oeffentlich
wird. Der Weg dahin ist EIN Tipp -- billig genug, dass niemand in
Versuchung kommt, ihn abzukuerzen. Beim Bestaetigen darf der Betrag
berichtigt werden: Die Leitung hat die PayPal-Meldung vor sich und
weiss es besser als die Behauptung.

FUER DIE ZUSCHAUER

Vier Betraege im Chat (2, 5, 10, 25 EUR) statt eines Links. Wer eine
Liste sieht, rechnet; wer vier Knoepfe sieht, tippt. Die Adresse wird
NICHT zweimal gepflegt -- sie steht auf der Unterstuetzen-Seite, und
von dort wird sie gelesen. Steht dort nichts oder ist der Weg auf
unsichtbar, gibt es hier auch keine Knoepfe. An einer Adresse, die
kein paypal.me ist, wird kein Betrag angehaengt: Er fuehrte sonst zu
einer Seite, auf der etwas anderes steht als auf dem Knopf.

DIE KARTE

Betrag gross, Name, Gruss, ein Bild dazu -- und eine Farbe, die von
der Stufe kommt. Drei Stufen ab Werk: Danke (ab 1), Starke Runde (ab
5), Rudel-Legende (ab 20), je mit eigener Vorlage, Farbe und Dauer.
Gilt immer die HOECHSTE, die noch passt; mit Ober- UND Untergrenze je
Stufe waere die doppelte Gelegenheit, eine Luecke zu lassen -- durch
die faellt dann ausgerechnet der grosse Betrag.

EINE NACH DER ANDEREN. Drei Spenden in zehn Sekunden sind keine
Seltenheit; uebereinander gelegt waere keine mehr lesbar, und
ausgerechnet die groesste ginge unter. Bei voller Schlange werden die
Zeiten gekuerzt, nicht die Karten weggeworfen -- wer gegeben hat,
soll es sehen.

DIE KARTE IST EIN EIGENES STUECK (spendenkarte.js/.css) und haengt an
nichts aus der Reaction. Dieselbe Karte laeuft spaeter als eigene
Seite fuer OBS und TikTok Studio; zweimal gebaut hiesse, sie sieht
nach der naechsten Aenderung an einem der beiden Orte anders aus --
und man merkt es erst im Livestream.

DER BETRAG STEHT IN CENT

Nie als Kommazahl. 0.1 + 0.2 ist in keiner Programmiersprache 0.3,
und bei Geld faellt das irgendwann jemandem auf -- meistens dem, der
zahlt. Formatiert wird erst auf dem Bildschirm.

DREI EIGENE FEHLER, VON DEN PRUEFUNGEN GEFUNDEN

1. Ein Weg aus einer Verzweigung: `/spenden/${id}/${ja ?
   "bestaetigen" : "ablehnen"}`. `pruef-struktur` hat das zu Recht
   beanstandet -- ein Tippfehler im selteneren Zweig faellt erst auf,
   wenn er mitten in einer Sendung gebraucht wird. Beide Wege stehen
   jetzt ausgeschrieben da.

2. "Genau 5 Register" -- zweimal am selben Tag dieselbe feste Zahl,
   in der Messung UND in der Pruefung. Beim sechsten Register wurden
   beide rot, obwohl nichts kaputt war. Jetzt wird gezaehlt: zu jedem
   Reiter gehoert eine Tafel, und keine steht ohne Reiter da.

3. Die Messung war zu ungeduldig: Die erste Karte laeuft elf
   Sekunden (die hoechste Stufe steht am laengsten), die zweite
   wartet in der Schlange -- richtig so. Die Messung wartete 1,6
   Sekunden und meldete "laeuft nicht". Jetzt wird auf das Merkmal
   gewartet, nicht auf die Uhr.

GEMESSEN

  mess-reaktion   4 Betragsknoepfe mit richtiger Adresse.
                  25 EUR von Hand -> Karte "Rudel-Legende" bei der
                  Zuschauerin. 500 EUR gemeldet -> steht NICHT im
                  Bild, wartet im Pult. Bestaetigt mit berichtigten
                  10 EUR -> Karte "Starke Runde". Stufe passt zum
                  Betrag, beide Male.
  pruef-spenden   46 Punkte, 0 Fehler (neu) -- darunter die
                  Gegenprobe, dass ohne Zahlungsnummer beliebig viele
                  Zeilen nebeneinander stehen duerfen (sonst liesse
                  sich nur EINE Spende von Hand eintragen).
  pruef-reaktion  154, unterstuetzung 70, aufbewahrung 45,
                  struktur 35, css-klassen 33, portnummern 15,
                  tippziele 11, ports 8, meldungen 8 -- alle 0 Fehler.

SCHEMA: zwei Tabellen (spenden, spenden_stufen) mit einem
Einmalig-Index auf die Zahlungsnummer. Auf einer Kopie der echten
Datenbank durchgespielt: 20 Personen, 227 Chatnachrichten, keine
Tabelle verliert eine Spalte.
2026-09-28 08:34:42 +02:00

564 lines
26 KiB
JavaScript
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
/* =====================================================================
Das Löschkonzept — als Tabelle, die sich selbst durchsetzt (15.09.2026)
Stufe 8 aus [[Creator Workspace – Plan zur Perfektion Stufe 2]]:
„Löschkonzept je Datenart · IP-Adressen im Protokoll nach 30 Tagen
weg. Je mehr Daten, desto teurer das Nachholen."
---------------------------------------------------------------------
WARUM DAS KEIN DOKUMENT IST
Ein Löschkonzept als Notiz ist nach dem ersten neuen Feld falsch, und
niemand merkt es. Diese Datei ist deshalb beides: die Übersicht, was
wie lange aufgehoben wird — UND das Programm, das es tut. Was hier
nicht steht, wird nicht geräumt; was hier steht, wird geräumt.
---------------------------------------------------------------------
WAS GEMESSEN WURDE, BEVOR HIER ETWAS STAND
42 Tabellen durchgesehen, drei halten IP-Adressen:
versuche.ip wird beim Anmelden selbst im Fenster geräumt (ok)
sitzungen.ip wird beim Abmelden geloescht -- ABGELAUFENE
Sitzungen aber nie (Luecke)
protokoll.ip wird nirgends geraeumt, waechst ewig (Luecke)
Zwei echte Luecken also, nicht fuenf vermutete.
---------------------------------------------------------------------
DREI SORTEN EINTRAG, UND DIE DRITTE IST DIE WICHTIGSTE
raeumen Diese Datei loescht selbst.
fremd Eine andere Stelle loescht -- hier wird nur GEZAEHLT.
Bricht die andere Stelle, steht die Zahl trotzdem da.
bleibt Wird absichtlich aufgehoben, mit Begruendung.
Ein Loeschkonzept, das nur Loeschungen auffuehrt, ist ein halbes:
Die begruendete Aufbewahrung ist der Teil, nach dem gefragt wird.
===================================================================== */
import express from "express";
/* Die Frist steht dort, wo auch die Begruendung steht -- in
`hilfe-tabellen.js`. Sie hier ein zweites Mal hinzuschreiben hiesse
zwei Wahrheiten, von denen eine veraltet. `hilfe-tabellen.js`
importiert absichtlich nichts, es kann also kein Kreis entstehen. */
import { AUFBEWAHRUNG_TAGE as HILFE_TAGE, FALL_STAND } from "./hilfe-tabellen.js";
import { AUFBEWAHRUNG_TAGE as SUPPORT_TAGE } from "./support-tabellen.js";
import { supportAufraeumen } from "./workspace-support.js";
import { notizenAufraeumen } from "./workspace-notizen.js";
import { reaktionAufraeumen } from "./workspace-reaktion.js";
import { spendenAufraeumen } from "./workspace-spenden.js";
import { VERLAUF_TAGE } from "./reaktion-tabellen.js";
import { SPENDEN_TAGE } from "./spenden-tabellen.js";
import { PAPIERKORB_TAGE as NOTIZ_TAGE } from "./notiz-tabellen.js";
import { ZAEHLUNG_TAGE } from "./unterstuetzung-tabellen.js";
import { unterstuetzungAufraeumen } from "./workspace-unterstuetzung.js";
import {
db, sitzungLesen, istDogFather, protokolliere, echteIp,
einstellung, einstellungSetzen,
} from "./workspace.js";
export const aufbewahrungRouter = express.Router();
/** Auf welcher Grundlage die Daten eines Menschen verarbeitet werden.
*
* ABGELEITET, NICHT GESPEICHERT. Ein Modi arbeitet hier — das ist ein
* Vertragsverhaeltnis. Ein Mitglied der Community ist freiwillig da —
* das ist eine Einwilligung. Die Grundlage folgt damit aus der Rolle,
* und was sich ableiten laesst, bekommt keine eigene Spalte: Sonst
* gaebe es zwei Wahrheiten, von denen eine veraltet, sobald jemand
* die Rolle wechselt.
*
* Gebraucht wird sie an zwei Stellen: in der Auskunft (Art. 15 Abs. 1
* lit. a — der Mensch darf den Zweck erfahren) und im Loeschkonzept. */
export function grundlageVon(rolle) {
if (rolle === "gast") {
return {
grundlage: "Art. 6 Abs. 1 lit. a DSGVO – Einwilligung",
warum: "Du bist freiwillig im Rudel. Du kannst jederzeit gehen, und deine "
+ "Daten gehen mit.",
};
}
return {
grundlage: "Art. 6 Abs. 1 lit. b DSGVO – zur Durchführung des Vertrags",
warum: "Du arbeitest hier. Ohne diese Daten lässt sich die Zusammenarbeit "
+ "nicht durchführen.",
};
}
/** Wie lange IP-Adressen im Protokoll stehen bleiben.
*
* 30 Tage: lang genug, um einen Missbrauch nachzuvollziehen, den man
* erst spaeter bemerkt -- kurz genug, dass daraus kein Bewegungsbild
* wird. Dieselbe Frist, die Filipe im Plan genannt hat. */
export const IP_TAGE = 30;
const vorTagen = (n) => new Date(Date.now() - n * 86400000).toISOString();
const jetzt = () => new Date().toISOString();
/** Zaehlt, ohne zu aendern. Ein Fehler hier ist kein Befund, sondern
* eine Zahl, die fehlt -- deshalb null statt 0, damit „konnte nicht
* nachsehen" nicht wie „nichts zu tun" aussieht. */
function zaehle(d, sql, ...werte) {
try { return d.prepare(sql).get(...werte)?.n ?? null; } catch { return null; }
}
/* =====================================================================
DIE TAFEL
===================================================================== */
export const FRISTEN = [
{
/* =================================================================
DER VERTRAULICHE MELDEWEG (nachgetragen am 20.09.2026)
DIESE TABELLE FEHLTE HIER -- und das ist der teuerste Eintrag,
den man vergessen kann: In `hilfe_nachrichten` stehen die
empfindlichsten Texte des ganzen Hauses. Jemand beschreibt ein
Problem, oft mit anderen Menschen darin.
Die Frist selbst war nie strittig: `AUFBEWAHRUNG_TAGE = 90`
steht seit dem 19.09. in `hilfe-tabellen.js`, mit Begruendung.
Und `hilfeAufraeumen()` gab es auch. Nur hat sie NIEMAND
aufgerufen: Gesucht im ganzen Verzeichnis war der einzige
Aufrufer ihre eigene Pruefung. Der Kommentar darueber behauptete
„Wird beim Start aufgerufen (siehe index.js)" -- das war nie
wahr. Die Pruefung war gruen und bewies nichts ueber den
Betrieb.
Jetzt steht es hier, wo es sich selbst durchsetzt: Diese Datei
ist beides -- die Uebersicht, was wie lange aufgehoben wird, UND
das Programm, das es tut. Nebenbei taucht der Meldeweg damit in
der Auskunft auf (Art. 15 DSGVO), und das gehoert sich: Wer
gemeldet hat, darf erfahren, wie lange das noch gespeichert ist.
GEMESSEN VOR DEM EINSCHALTEN: In der echten Datenbank steht
heute KEIN einziger Fall. Der erste Lauf loescht also nichts,
und der erste Fall kann fruehestens in drei Monaten 90 Tage alt
werden. Einschalten ist jetzt frei -- spaeter waere es der
riskante Moment gewesen.
DIE NACHRICHTEN GEHEN MIT: `hilfe_nachrichten.fall_id` traegt
`ON DELETE CASCADE`, und `PRAGMA foreign_keys` steht im Dienst
auf 1. Beides nachgemessen an einem echten Fall mit Nachricht:
vorher 1/1, nachher 0/0. Ohne diese Messung waere der Fall
verschwunden und der eigentliche Text liegengeblieben. */
schluessel: "hilfe_geschlossen",
was: "Abgeschlossene vertrauliche Meldungen samt Verlauf",
art: "raeumen",
frist: `${HILFE_TAGE} Tage nach dem Abschluss`,
zweck: "Ein abgeschlossener Fall kommt manchmal wieder auf "
+ "(oft Monate spaeter) – dann muss man nachlesen "
+ "können, was damals vereinbart wurde.",
grundlage: "Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse "
+ "(Schutz der Mitglieder), Art. 5 Abs. 1 lit. e – Speicherbegrenzung",
wirkung: "Der Fall und ALLE Nachrichten darin verschwinden ganz. "
+ "Offene Fälle werden nie geräumt – nur abgeschlossene, und erst "
+ `${HILFE_TAGE} Tage danach.`,
offen: (d) => zaehle(d,
"SELECT COUNT(*) AS n FROM hilfe_faelle WHERE stand = ?"
+ " AND geschlossen_am IS NOT NULL AND geschlossen_am < ?",
FALL_STAND.zu, vorTagen(HILFE_TAGE)),
raeumen: (d) => d.prepare(
"DELETE FROM hilfe_faelle WHERE stand = ?"
+ " AND geschlossen_am IS NOT NULL AND geschlossen_am < ?")
.run(FALL_STAND.zu, vorTagen(HILFE_TAGE)).changes,
},
{
schluessel: "protokoll_ip",
was: "IP-Adressen im Protokoll",
art: "raeumen",
frist: `${IP_TAGE} Tage`,
zweck: "Einen Missbrauch nachvollziehen können, der erst später auffällt.",
grundlage: "Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse",
wirkung: "Nur die IP wird geleert. Wer wann was getan hat, bleibt stehen – "
+ "das Protokoll ist die Sicherung gegen stille Änderungen.",
offen: (d) => zaehle(d,
"SELECT COUNT(*) AS n FROM protokoll WHERE ip IS NOT NULL AND zeitpunkt < ?", vorTagen(IP_TAGE)),
raeumen: (d) => d.prepare(
"UPDATE protokoll SET ip = NULL WHERE ip IS NOT NULL AND zeitpunkt < ?")
.run(vorTagen(IP_TAGE)).changes,
},
{
schluessel: "sitzungen_abgelaufen",
was: "Abgelaufene Anmeldungen (mit IP und Browser)",
art: "raeumen",
frist: "sofort nach Ablauf",
zweck: "Angemeldet bleiben, solange die Sitzung gilt.",
grundlage: "Art. 6 Abs. 1 lit. b DSGVO – zur Durchführung erforderlich",
wirkung: "Die Zeile verschwindet ganz. Nach Ablauf ist sie zu nichts mehr nütze – "
+ "sie stand bisher nur da und trug eine IP mit sich.",
offen: (d) => zaehle(d,
"SELECT COUNT(*) AS n FROM sitzungen WHERE gueltig_bis < ?", jetzt()),
raeumen: (d) => d.prepare("DELETE FROM sitzungen WHERE gueltig_bis < ?")
.run(jetzt()).changes,
},
{
schluessel: "versuche",
was: "Fehlversuche beim Anmelden (IP)",
art: "fremd",
frist: "10 Minuten",
zweck: "Ausprobieren von Codes bremsen.",
grundlage: "Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse",
wirkung: "Wird beim Anmelden selbst geräumt (workspace.js). Hier steht die Zahl "
+ "trotzdem – bricht die andere Stelle, sieht man es hier.",
offen: (d) => zaehle(d,
"SELECT COUNT(*) AS n FROM versuche WHERE zeitpunkt < ?",
new Date(Date.now() - 60 * 60000).toISOString()),
},
{
schluessel: "protokoll_eintraege",
was: "Die Protokolleinträge selbst (ohne IP)",
art: "bleibt",
frist: "unbefristet",
zweck: "Nachvollziehen, wer wann einen Zugang angelegt, gesperrt oder gelöscht hat.",
grundlage: "Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse an Nachvollziehbarkeit",
wirkung: "Bleibt. Ein Protokoll, das sich selbst löscht, sichert nichts.",
offen: (d) => zaehle(d, "SELECT COUNT(*) AS n FROM protokoll"),
},
{
schluessel: "treff_massnahmen",
was: "Maßnahmen im Rudel (Hinweis, Pause, Ausschluss) mit Begründung",
art: "bleibt",
frist: "solange die Person ein Konto hat",
zweck: "Eine Entscheidung über einen Menschen muss begründet nachlesbar sein – "
+ "das schützt beide Seiten.",
grundlage: "Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse",
wirkung: "Bleibt, solange es den Zugang gibt. Wird der Zugang gelöscht, geht die "
+ "Maßnahme mit (ON DELETE CASCADE).",
offen: (d) => zaehle(d, "SELECT COUNT(*) AS n FROM treff_massnahmen"),
},
{
schluessel: "alter_bestaetigt",
was: "Der Zeitpunkt der Altersbestätigung (Community)",
art: "bleibt",
frist: "solange der Zugang besteht",
zweck: "Nachweisen können, dass das Mindestalter bestätigt wurde – "
+ "eine Regel, die man nicht belegen kann, hat man nicht.",
grundlage: "Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse an Nachweisbarkeit",
wirkung: "Gespeichert wird NUR der Zeitpunkt, kein Geburtsdatum. Für die Frage "
+ "„hat bestätigt, und wann?“ reicht das – ein Geburtstag wären mehr Daten "
+ "für dieselbe Auskunft.",
offen: (d) => zaehle(d,
"SELECT COUNT(*) AS n FROM personen WHERE alter_bestaetigt_am IS NOT NULL"),
},
{
/* ERLEDIGTE AUFGABEN (nachgetragen am 20.09.2026)
Aufgefallen beim Suchen nach dem naechsten `hilfe_faelle`:
Genau ZWEI Tabellen im ganzen Haus tragen eine Spalte, die
sagt „hier ist etwas zu Ende" -- `hilfe_faelle.geschlossen_am`
und `aufgaben.erledigt_am`. Die erste war gar nicht im Konzept,
die zweite ebenso wenig.
Hier ist die Antwort aber eine andere: Sie BLEIBEN. Eine
erledigte Aufgabe ist Arbeitsdokumentation, keine Meldung ueber
einen Menschen -- und wer im Dezember wissen will, was im
September verabredet war, findet es sonst nicht mehr.
`aufgaben.verantwortlich_id` traegt ON DELETE SET NULL, nicht
CASCADE: Wird eine Person geloescht, bleibt die Aufgabe stehen
und verliert nur den Namen. Auch das ist Absicht -- eine
Aufgabe, die verschwindet, weil jemand das Team verlaesst,
reisst die Geschichte des Projekts mit. */
schluessel: "aufgaben_erledigt",
was: "Erledigte und abgebrochene Aufgaben",
art: "bleibt",
frist: "unbefristet",
zweck: "Nachlesen können, was wann verabredet und getan wurde.",
grundlage: "Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse an "
+ "nachvollziehbarer Zusammenarbeit",
wirkung: "Bleiben. Beim Löschen einer Person verlieren sie nur den Namen "
+ "(ON DELETE SET NULL) – die Aufgabe selbst bleibt lesbar.",
offen: (d) => zaehle(d,
"SELECT COUNT(*) AS n FROM aufgaben WHERE erledigt_am IS NOT NULL"),
},
/* ==== ZWEI EINTRÄGE, DIE HIER GEFEHLT HABEN (24.09.2026) ========
Beim Einbau des Unterstützen-Bereichs ist aufgefallen, dass
`supportAufraeumen()` in workspace-support.js zwar EXPORTIERT,
aber nirgends AUFGERUFEN wird — gesucht im ganzen Verzeichnis,
null Treffer. Die Meldungen samt Bildschirmfotos wären also für
immer liegen geblieben, obwohl im Kopf der Datei "90 Tage" steht.
Das ist dieselbe Sorte Fehler wie eine Prüfung, die nie läuft:
Es sieht fertig aus, es ist dokumentiert, und es passiert nichts.
Diese Liste ist die einzige Stelle im Haus, die wirklich räumt —
wer eine Frist verspricht und hier keinen Eintrag hat, verspricht
nichts. */
{
schluessel: "support_erledigt",
was: "Erledigte Support-Meldungen samt Bildschirmfoto",
art: "raeumen",
frist: `${SUPPORT_TAGE} Tage nach dem Erledigen`,
zweck: "Ein Fehler kommt oft wieder – dann hilft es, nachlesen zu können, "
+ "was beim letzten Mal daran war.",
grundlage: "Art. 5 Abs. 1 lit. e DSGVO – Speicherbegrenzung",
wirkung: `Die Meldung verschwindet ganz, mitsamt dem Bild auf der Platte. `
+ `Offene Meldungen werden nie geräumt – nur erledigte, und erst `
+ `${SUPPORT_TAGE} Tage danach.`,
offen: (d) => zaehle(d,
"SELECT COUNT(*) AS n FROM support_meldungen WHERE stand = 'erledigt'"
+ " AND erledigt_am IS NOT NULL AND erledigt_am < ?", vorTagen(SUPPORT_TAGE)),
/* ÜBER supportAufraeumen() UND NICHT ÜBER EIN DELETE HIER: Zu
jeder Meldung gehört eine Bilddatei auf der Platte. Ein DELETE
an dieser Stelle würde die Zeile löschen und das Bild liegen
lassen — und ein Bild ohne Zeile findet danach niemand mehr. */
raeumen: () => supportAufraeumen(),
},
/* ==== DER PAPIERKORB DES NOTIZBLOCKS (26.09.2026) ==============
Der Eintrag entsteht ZUSAMMEN mit der Frist und nicht danach.
Am 24.09. ist genau das schiefgegangen: `supportAufraeumen()`
war geschrieben, exportiert und dokumentiert -- und wurde
nirgends aufgerufen. Im Kopf der Datei stand „90 Tage", und
geräumt wurde nie. */
{
schluessel: "notizen_papierkorb",
was: "Weggelegte Notizblätter",
art: "raeumen",
frist: `${NOTIZ_TAGE} Tage im Papierkorb`,
zweck: "Ein versehentlich weggetipptes Blatt zurückholen können.",
grundlage: "Art. 5 Abs. 1 lit. e DSGVO – Speicherbegrenzung",
wirkung: `Das Blatt verschwindet ganz. Was auf dem Block liegt, wird `
+ `nie geräumt – nur was jemand selbst weggelegt hat, und erst `
+ `${NOTIZ_TAGE} Tage danach.`,
offen: (d) => zaehle(d,
"SELECT COUNT(*) AS n FROM notizen WHERE weg_am IS NOT NULL AND weg_am < ?",
vorTagen(NOTIZ_TAGE)),
raeumen: () => notizenAufraeumen(),
},
{
schluessel: "reaktion_verlauf",
was: "Verlauf der Reaction-Sendungen",
art: "raeumen",
frist: `${VERLAUF_TAGE} Tage`,
zweck: "Nachsehen können, was wir gemeinsam geschaut haben – "
+ "und ob überhaupt jemand dabei war.",
grundlage: "Art. 5 Abs. 1 lit. e DSGVO – Speicherbegrenzung",
wirkung: "Die Zeile verschwindet: Titel, Video, Datum, wie viele "
+ "zugesehen und wie viel geschrieben wurde. Der Live-Chat einer "
+ "Sendung ist ohnehin schon beim Beenden weg – was hier "
+ "läuft, ist nur die Erinnerung, dass es sie gab.",
offen: (d) => zaehle(d,
"SELECT COUNT(*) AS n FROM reaktion_verlauf WHERE beendet < ?",
vorTagen(VERLAUF_TAGE)),
raeumen: () => reaktionAufraeumen(),
},
{
schluessel: "spenden",
was: "Spenden und ihre Karten",
art: "raeumen",
frist: `${SPENDEN_TAGE} Tage`,
zweck: "Nachsehen können, wer wann unterstützt hat – und eine Karte "
+ "noch einmal zeigen, falls sie im falschen Moment lief.",
grundlage: "Art. 5 Abs. 1 lit. e DSGVO – Speicherbegrenzung",
wirkung: "Die Zeile verschwindet: Betrag, Name auf der Karte, Gruß, "
+ "woher sie kam und wer sie bestätigt hat. Die Zahlung selbst "
+ "liegt bei PayPal, nicht hier – dort gelten deren Fristen.",
offen: (d) => zaehle(d,
"SELECT COUNT(*) AS n FROM spenden WHERE erstellt < ?",
vorTagen(SPENDEN_TAGE)),
raeumen: () => spendenAufraeumen(),
},
{
schluessel: "unterstuetzung_striche",
was: "Tagesstriche der Unterstützen-Seite",
art: "raeumen",
frist: `${ZAEHLUNG_TAGE} Tage`,
zweck: "Sehen, ob ein Weg überhaupt benutzt wird – und ob ein neuer anläuft.",
grundlage: "Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse",
wirkung: "Die Zeile verschwindet. Es steht ohnehin keine Person darin: "
+ "Die Tabelle hat gar keine Spalte dafür (siehe unterstuetzung-tabellen.js) – "
+ "gezählt wird je Weg und Tag, nicht je Mensch.",
offen: (d) => zaehle(d,
"SELECT COUNT(*) AS n FROM unterstuetzung_striche WHERE tag < ?",
vorTagen(ZAEHLUNG_TAGE).slice(0, 10)),
raeumen: () => unterstuetzungAufraeumen(),
},
{
/* AUFGABEN-ZUTEILUNG (nachgetragen 24.09.2026).
Die Tabelle gibt es seit dem 21.09., im Löschkonzept stand sie
nicht -- gefunden von pruef-aufbewahrung, die jede Tabelle mit
einer "erledigt_am"-Spalte hier einfordert. Die Prüfung meldete
sie zusammen mit support_meldungen, und beide waren echte
Lücken: Für jede Tabelle muss JEMAND entschieden haben, ob sie
verschwindet oder bleibt. "Noch nicht bedacht" ist keine der
beiden Antworten.
DIE ANTWORT HIER IST "BLEIBT", und sie ist begründet: Wer welche
Aufgabe übernommen, abgelehnt oder erledigt hat, ist der
Werdegang eines Menschen im Team -- dieselbe Überlegung wie bei
den Aufgaben selbst eine Zeile darüber. Sie verschwindet mit
ihrer Aufgabe (ON DELETE CASCADE) und mit der Person
(ON DELETE CASCADE), aber nicht nach einer Frist. */
schluessel: "aufgaben_zuteilung",
was: "Wer eine Aufgabe übernommen hat",
art: "bleibt",
frist: "gehen mit der Aufgabe und mit der Person",
zweck: "Nachvollziehen, wer was übernommen hat – und was daraus wurde.",
grundlage: "Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse",
wirkung: "Bleiben. Wird die Aufgabe gelöscht, gehen sie mit (ON DELETE CASCADE); "
+ "wird der Zugang gelöscht, ebenso. Eine eigene Frist gibt es nicht – "
+ "eine Zuteilung ohne ihre Aufgabe wäre ohnehin nicht mehr lesbar.",
offen: (d) => zaehle(d,
"SELECT COUNT(*) AS n FROM aufgaben_zuteilung WHERE erledigt_am IS NOT NULL"),
},
{
schluessel: "personen_geloescht",
was: "Daten einer gelöschten Person",
art: "bleibt",
frist: "gehen mit dem Zugang",
zweck: "—",
grundlage: "Art. 17 DSGVO – Recht auf Löschung",
wirkung: "Wer in „Personen & Zugänge“ gelöscht wird, nimmt Sitzungen, Maßnahmen, "
+ "Entwicklungsstände und Chat-Zugehörigkeit mit – die Datenbank erzwingt das "
+ "über ON DELETE CASCADE, nicht eine Liste, die jemand pflegt.",
offen: (d) => zaehle(d, "SELECT COUNT(*) AS n FROM personen WHERE aktiv = 0"),
},
];
/* =====================================================================
DER LAUF
===================================================================== */
/** Räumt alles, was zu räumen ist.
*
* @returns {{getan: Array, fehler: Array}} was passiert ist
*/
export function aufbewahrungLauf() {
const d = db();
const getan = [];
const fehler = [];
for (const f of FRISTEN) {
if (typeof f.raeumen !== "function") continue;
try {
const anzahl = f.raeumen(d);
if (anzahl) getan.push({ schluessel: f.schluessel, anzahl });
} catch (fe) {
/* EIN FEHLSCHLAG DARF DEN REST NICHT AUFHALTEN -- und er darf
nicht still bleiben. Waere er still, hiesse „aufgeraeumt"
irgendwann „einmal probiert". */
fehler.push({ schluessel: f.schluessel, grund: String(fe?.message || fe).slice(0, 200) });
console.error("[aufbewahrung]", f.schluessel, fe?.message);
}
}
try {
einstellungSetzen("aufbewahrung_letzte",
JSON.stringify({ zeitpunkt: jetzt(), getan, fehler }));
} catch { /* der Lauf zaehlt, nicht sein Vermerk */ }
/* Nur protokollieren, wenn wirklich etwas passiert ist. Ein taeglicher
Eintrag „nichts zu tun" waere genau die Art Rauschen, die das
Protokoll unlesbar macht -- und ausgerechnet dieses Protokoll ist
die Sicherung gegen stille Aenderungen. */
if (getan.length || fehler.length) {
try {
protokolliere("aufbewahrung", {
detail: getan.map((g) => `${g.schluessel}: ${g.anzahl}`).join(", ")
+ (fehler.length ? ` | FEHLER: ${fehler.map((f) => f.schluessel).join(", ")}` : ""),
});
} catch { /* egal */ }
}
return { getan, fehler };
}
/** Einmal am Tag, und einmal kurz nach dem Start.
*
* Nicht im Startmoment: Erst soll die Website antworten. Dieselbe
* Ueberlegung wie bei der Sicherung -- ein Aufraeumlauf im
* Startmoment wuerde die Datenbank nur unnoetig frueh oeffnen und
* einen Fehler dort zum Startfehler machen. */
export function aufbewahrungStarten() {
const ersterLauf = setTimeout(() => { try { aufbewahrungLauf(); } catch { /* egal */ } }, 90_000);
const takt = setInterval(() => { try { aufbewahrungLauf(); } catch { /* egal */ } }, 24 * 3600_000);
ersterLauf.unref?.();
takt.unref?.();
}
/* =====================================================================
DIE TAFEL ZUM ANSEHEN
===================================================================== */
/** Kommt die Anfrage von unserer eigenen Seite?
*
* DERSELBE WORTLAUT WIE IN DEN ANDEREN MODULEN und bewusst keine
* eigene Erfindung: Eine zweite, leicht andere Fassung waere eine
* zweite Wahrheit, und beim naechsten Nachschaerfen wuerde genau die
* eine vergessen.
*
* KEIN `origin` HEISST DURCHLASSEN, und das ist Absicht: Browser
* schicken das Feld bei schreibenden Anfragen immer mit. Fehlt es,
* kommt die Anfrage aus einem Werkzeug (curl, eine Pruefung) -- und
* dort ist die Sitzung ohnehin nur da, wenn jemand sie absichtlich
* mitgibt. Der Angriff, um den es geht, braucht einen Browser. */
function gleicheHerkunft(req, res, next) {
const herkunft = req.get("origin");
if (!herkunft) return next();
let erlaubt;
try { erlaubt = new URL(herkunft).host === req.get("host"); } catch { erlaubt = false; }
if (!erlaubt) return res.status(403).json({ fehler: "fremde_herkunft" });
next();
}
function nurDogFather(req, res, next) {
const person = sitzungLesen(req);
if (!person) return res.status(401).json({ fehler: "nicht_angemeldet" });
/* 404 und nicht 403: Wer „kein Zugriff" liest, weiss, dass es die
Seite gibt. Dieselbe Antwort wie ueberall im Haus. */
if (!istDogFather(person)) return res.status(404).json({ fehler: "nicht_gefunden" });
req.person = person;
next();
}
aufbewahrungRouter.get("/workspace/api/aufbewahrung", nurDogFather, (req, res) => {
try {
const d = db();
let letzte = null;
try { letzte = JSON.parse(einstellung("aufbewahrung_letzte") || "null"); } catch { letzte = null; }
const zeilen = FRISTEN.map((f) => ({
schluessel: f.schluessel,
was: f.was,
art: f.art,
frist: f.frist,
zweck: f.zweck,
grundlage: f.grundlage,
wirkung: f.wirkung,
/* `offen` heisst bei „raeumen": so viele warten. Bei „bleibt":
so viele liegen da. Zwei verschiedene Bedeutungen unter einem
Namen waeren eine Falle -- deshalb steht `art` daneben und die
Oberflaeche beschriftet die Zahl danach. */
anzahl: f.offen ? f.offen(d) : null,
}));
res.json({ fristen: zeilen, letzte, ip_tage: IP_TAGE });
} catch (fehler) {
console.error("[aufbewahrung] Tafel:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/** Von Hand anstossen.
*
* Damit es kein schwarzer Kasten ist: Wer sehen will, ob es wirkt,
* drueckt drauf und sieht die Zahlen fallen. */
/* DER RIEGEL STEHT VOR DER RECHTEPRUEFUNG.
Reihenfolge wie im ganzen Haus: erst "kommt das von uns?", dann
"darf der das?". Andersherum waere es nicht falsch, aber die
Abweichung faellt beim Lesen auf und kostet jedes Mal einen
Moment. */
aufbewahrungRouter.post("/workspace/api/aufbewahrung/jetzt", gleicheHerkunft, nurDogFather, (req, res) => {
try {
const ergebnis = aufbewahrungLauf();
protokolliere("aufbewahrung_von_hand", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: ergebnis.getan.map((g) => `${g.schluessel}: ${g.anzahl}`).join(", ") || "nichts zu tun",
});
res.json(ergebnis);
} catch (fehler) {
console.error("[aufbewahrung] Lauf:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});