Personen loeschen -- mit Vorschau und einer Sicherung unmittelbar davor
Wunsch Filipe: "ich will auch die moeglichkeit haben die loeschen zu
koennen."
Das ist die einzige Handlung im ganzen Workspace, die sich nicht
rueckgaengig machen laesst. Vier Vorkehrungen:
1. NUR DOGFATHER. Nicht die Leitung, nicht ein Manager -- "nur DogFather
hat alle endgueltigen Rechte" heisst genau hier etwas. Ein Manager
kann weiterhin sperren; das reicht fuer den Alltag und ist umkehrbar.
Alle anderen bekommen 404, auch fuer die Vorschau: Die verraet, wie
viel an einer Person haengt.
2. VORSCHAU. Vor dem Klick steht da, was MITGEHT (Profil, Start-Check,
Content-Saeulen, Sitzungen, Zustaendigkeit) und was BLEIBT und nur
seine Zuordnung verliert (Aufgaben, Termine, Bereichseintraege,
Dateien, Leads). Eine Aufgabe verschwinden zu lassen, weil jemand
geht, waere Geschichtsfaelschung.
Dazu die gefaehrlichste Einzelwarnung: Wer einen Scout loescht, nimmt
seinen Creators die zustaendige Person weg. Die Vorschau nennt sie
beim Namen.
3. EINE SICHERUNG DIREKT DAVOR -- und wenn sie scheitert, wird NICHT
geloescht. Damit ist "geloescht" wiederherstellbar. Das ist der
eigentliche Gewinn aus der Sicherungsarbeit von heute Nachmittag.
4. Der Name muss getippt werden. Nicht als Schikane: Der Loeschknopf
sitzt neben dem Sperrknopf, und die beiden sind sehr verschieden. Wer
den Namen tippt, hat die Zeile gelesen, die er trifft.
ZWEI FEHLER, die erst die Pruefung sichtbar gemacht hat:
a) Alle Loeschungen schrieben in DIESELBE Tagessicherung. Nach der
dritten kannte sie die erste geloeschte Person nicht mehr -- die
Sicherung haette genau in dem Fall versagt, fuer den sie da ist.
Loeschungen bekommen jetzt eine eigene Datei ("vorher-…") mit
Zeitstempel, die nie ueberschrieben wird. Aufgefallen nur, weil die
Pruefung die ANZAHL der Dateien zaehlt und nicht bloss, ob eine da ist.
b) Der Zeitstempel hatte Sekundenaufloesung -- drei Loeschungen in
derselben Sekunde ergaben wieder eine einzige Datei. Jetzt mit
Millisekunden, plus Zaehler als Notloesung. Und: Eine Sicherung vor
dem Loeschen setzt NICHT den Vermerk fuer den planmaessigen Lauf,
sonst faellt die naechtliche Sicherung aus.
Dabei auch ein Fehler in meiner eigenen Pruefung gefunden: Sie griff die
alphabetisch erste Datei und nannte sie "die aelteste" -- "vorher-…-2.db"
sortiert aber VOR "vorher-….db", weil "-" kleiner ist als ".". Sie prueft
jetzt die Eigenschaft selbst: JEDE geloeschte Person muss sich aus
irgendeiner Sicherung zurueckholen lassen.
43 Pruefungen, Schwerpunkt auf dem, was NICHT gehen darf.
Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
@@ -17,6 +17,7 @@ import express from "express";
|
||||
import {
|
||||
db, protokolliere, echteIp, sitzungLesen, personAnlegen, codeNeu, personSperren, betreuungSetzen, istLeitung, istDogFather, ROLLEN_SORTIERUNG, ROLLEN_REIHE,
|
||||
} from "./workspace.js";
|
||||
import { sicherungJetzt } from "./workspace-sicherung.js";
|
||||
|
||||
export const personenRouter = express.Router();
|
||||
|
||||
@@ -259,6 +260,160 @@ personenRouter.patch("/workspace/api/verwaltung/personen/:id", gleicheHerkunft,
|
||||
}
|
||||
});
|
||||
|
||||
/* =====================================================================
|
||||
Löschen.
|
||||
|
||||
Wunsch Filipe, 31.08.2026: "ich will auch die möglichkeit haben die
|
||||
löschen zu können."
|
||||
|
||||
Das ist die einzige Handlung im ganzen Workspace, die sich nicht
|
||||
rückgängig machen lässt. Deshalb vier Vorkehrungen:
|
||||
|
||||
1. NUR DOGFATHER. Nicht die Leitung, nicht ein Manager -- "nur
|
||||
DogFather hat alle endgültigen Rechte" heisst genau hier etwas.
|
||||
Ein Manager kann weiterhin sperren; das reicht für den Alltag und
|
||||
ist umkehrbar.
|
||||
|
||||
2. VORSCHAU, was daran hängt. Man muss VOR dem Klick sehen, was
|
||||
mitgeht und was nur seine Zuordnung verliert. Ohne diese Liste
|
||||
löscht man ein Creator-Profil und merkt erst Wochen später, dass
|
||||
damit auch der Start-Check und die Content-Säulen weg sind.
|
||||
|
||||
3. EINE SICHERUNG DIREKT DAVOR. Das ist der eigentliche Gewinn aus der
|
||||
Sicherungsarbeit von heute: Vor jedem Löschen schreibt der Server
|
||||
eine vollständige, sofort geprüfte Sicherung. Geht sie schief, wird
|
||||
NICHT gelöscht. Damit ist "gelöscht" wiederherstellbar -- aus einer
|
||||
unumkehrbaren Handlung wird eine, die man zurückholen kann.
|
||||
|
||||
4. Sich selbst und den letzten DogFather nie. Dieselbe Regel wie beim
|
||||
Sperren, aus demselben Grund: Sonst sperrt man sich aus.
|
||||
|
||||
Was BLEIBT: Aufgaben, Termine, Bereichseinträge, Dateien und
|
||||
Protokollzeilen. Sie verlieren nur den Verweis auf die Person
|
||||
(ON DELETE SET NULL). Das ist Absicht -- eine Aufgabe verschwinden zu
|
||||
lassen, weil jemand geht, wäre Geschichtsfälschung.
|
||||
|
||||
Was MITGEHT (ON DELETE CASCADE): Profil, Start-Check, Content-Säulen,
|
||||
Sitzungen, Zuständigkeit. Dinge, die es ohne die Person nicht gibt.
|
||||
===================================================================== */
|
||||
|
||||
/* Was hängt an dieser Person? Wird von der Vorschau UND vom Löschen
|
||||
benutzt -- damit die Anzeige nicht etwas anderes behaupten kann, als
|
||||
das Löschen dann tut. */
|
||||
function anhang(id) {
|
||||
const zahl = (sql, ...w) => db().prepare(sql).get(id, ...w)?.n ?? 0;
|
||||
return {
|
||||
mit: {
|
||||
"Profil": zahl("SELECT COUNT(*) AS n FROM profile WHERE person_id = ?"),
|
||||
"Start-Check": zahl("SELECT COUNT(*) AS n FROM startcheck WHERE creator_id = ?"),
|
||||
"Content-Säulen": zahl("SELECT COUNT(*) AS n FROM content_saeulen WHERE creator_id = ?"),
|
||||
"offene Sitzungen": zahl("SELECT COUNT(*) AS n FROM sitzungen WHERE person_id = ?"),
|
||||
},
|
||||
bleibt: {
|
||||
"Aufgaben": zahl("SELECT COUNT(*) AS n FROM aufgaben WHERE creator_id = ? OR verantwortlich_id = ?", id),
|
||||
"Einträge in den Bereichen": zahl("SELECT COUNT(*) AS n FROM eintraege WHERE creator_id = ?"),
|
||||
"Termine": zahl("SELECT COUNT(*) AS n FROM termine WHERE creator_id = ? OR teilnehmer_id = ?", id),
|
||||
"Dateien": zahl("SELECT COUNT(*) AS n FROM dateien WHERE creator_id = ?"),
|
||||
"Leads in der Pipeline": zahl("SELECT COUNT(*) AS n FROM leads WHERE scout_id = ? OR creator_id = ?", id),
|
||||
},
|
||||
/* Der gefährlichste Einzelfall: Wer einen Scout löscht, nimmt seinen
|
||||
Creators die zuständige Person weg -- und die stehen danach ohne
|
||||
Betreuung da, ohne dass jemand etwas davon mitbekommt. */
|
||||
verliertBetreuung: db().prepare(
|
||||
"SELECT p.name FROM betreuung b JOIN personen p ON p.id = b.creator_id WHERE b.betreuer_id = ?")
|
||||
.all(id).map((r) => r.name),
|
||||
};
|
||||
}
|
||||
|
||||
/* Alles, was gegen ein Löschen spricht -- als Fehlertext oder null.
|
||||
Steht getrennt, damit Vorschau und Löschen GARANTIERT dieselbe Antwort
|
||||
geben. Zwei Stellen mit derselben Regel laufen irgendwann auseinander. */
|
||||
function darfGeloeschtWerden(person, akteur) {
|
||||
if (!istDogFather(akteur)) return "Löschen darf nur DogFather.";
|
||||
if (person.id === akteur.id) return "Dich selbst kannst du nicht löschen.";
|
||||
if (istDogFather(person)) {
|
||||
const { n } = db().prepare("SELECT COUNT(*) AS n FROM personen WHERE rolle = 'admin'").get();
|
||||
if (n <= 1) return "Das ist der letzte DogFather-Zugang.";
|
||||
}
|
||||
return null;
|
||||
}
|
||||
|
||||
personenRouter.get("/workspace/api/verwaltung/personen/:id/loeschbar", (req, res) => {
|
||||
try {
|
||||
const id = Number(req.params.id);
|
||||
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
|
||||
/* Wer gar nicht löschen darf, sieht auch die Vorschau nicht -- sie
|
||||
verrät, wie viel an einer Person hängt. */
|
||||
if (!istDogFather(req.person)) return res.status(404).json({ fehler: "nicht_gefunden" });
|
||||
|
||||
const person = db().prepare("SELECT id, name, rolle, aktiv FROM personen WHERE id = ?").get(id);
|
||||
if (!person) return res.status(404).json({ fehler: "nicht_gefunden" });
|
||||
|
||||
res.json({
|
||||
person: { id: person.id, name: person.name, rolle: person.rolle, aktiv: person.aktiv },
|
||||
hindernis: darfGeloeschtWerden(person, req.person),
|
||||
...anhang(id),
|
||||
});
|
||||
} catch (fehler) {
|
||||
console.error("[workspace] Löschvorschau:", fehler?.message);
|
||||
res.status(503).json({ fehler: "nicht_verfuegbar" });
|
||||
}
|
||||
});
|
||||
|
||||
personenRouter.delete("/workspace/api/verwaltung/personen/:id", gleicheHerkunft, (req, res) => {
|
||||
try {
|
||||
const id = Number(req.params.id);
|
||||
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
|
||||
if (!istDogFather(req.person)) return res.status(404).json({ fehler: "nicht_gefunden" });
|
||||
|
||||
const person = db().prepare("SELECT id, name, rolle, aktiv FROM personen WHERE id = ?").get(id);
|
||||
if (!person) return res.status(404).json({ fehler: "nicht_gefunden" });
|
||||
|
||||
const hindernis = darfGeloeschtWerden(person, req.person);
|
||||
if (hindernis) return res.status(400).json({ fehler: hindernis });
|
||||
|
||||
/* Der Name muss wortwörtlich mitgeschickt werden. Nicht als Schikane:
|
||||
Der Löschknopf sitzt neben dem Sperrknopf, und die beiden sind sehr
|
||||
verschieden. Wer den Namen tippt, hat die Zeile gelesen, die er
|
||||
trifft. */
|
||||
if (String(req.body?.name ?? "").trim() !== person.name) {
|
||||
return res.status(400).json({ fehler: "Zum Löschen bitte den Namen genau eingeben." });
|
||||
}
|
||||
|
||||
const vorher = anhang(id);
|
||||
|
||||
/* Sicherung DIREKT davor -- scheitert sie, wird nicht gelöscht. Das
|
||||
ist der Punkt, an dem aus "unumkehrbar" "wiederherstellbar" wird. */
|
||||
let sicherung = null;
|
||||
try {
|
||||
/* Eigene Datei mit Uhrzeit -- drei Loeschungen hintereinander
|
||||
wuerden sonst dreimal dieselbe Tagessicherung ueberschreiben,
|
||||
und die erste geloeschte Person waere trotzdem weg. */
|
||||
sicherung = sicherungJetzt("vor dem Löschen von " + person.name, true);
|
||||
} catch (fehler) {
|
||||
console.error("[workspace] Sicherung vor dem Löschen:", fehler?.message);
|
||||
return res.status(503).json({
|
||||
fehler: "Die Sicherung vor dem Löschen ist fehlgeschlagen – es wurde nichts gelöscht.",
|
||||
});
|
||||
}
|
||||
|
||||
/* Fremdschlüssel müssen an sein, sonst greifen CASCADE und SET NULL
|
||||
nicht und es bleiben Reste zurück, die auf niemanden mehr zeigen. */
|
||||
db().exec("PRAGMA foreign_keys = ON");
|
||||
db().prepare("DELETE FROM personen WHERE id = ?").run(id);
|
||||
|
||||
protokolliere("person_geloescht", {
|
||||
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
|
||||
detail: `${person.name} (${person.rolle}) · Sicherung: ${sicherung.datei}`.slice(0, 160),
|
||||
});
|
||||
|
||||
res.json({ ok: true, sicherung: sicherung.datei, war: vorher });
|
||||
} catch (fehler) {
|
||||
console.error("[workspace] Person löschen:", fehler?.message);
|
||||
res.status(503).json({ fehler: "nicht_verfuegbar" });
|
||||
}
|
||||
});
|
||||
|
||||
/* ---------- Protokoll ---------------------------------------------------- */
|
||||
|
||||
personenRouter.get("/workspace/api/verwaltung/protokoll", (req, res) => {
|
||||
|
||||
Reference in New Issue
Block a user