Files
dogfather-universe/server/workspace-personen.js
T
DogFatherGitandClaude Opus 5 9e523d3ea2 Manager sehen nur noch ihre zugeteilten Scouts -- und deren Creator
Wunsch vom 01.09.2026: "er soll nur die Scouts sehen, die ihm zugeteilt
sind." Dazu entschieden: Ein Manager sieht dann AUCH die Creator dieser
Scouts, und zuteilen darf NUR DogFather.

WAS VORHER WAR. Ein Manager sah die gesamte Scout-Pipeline -- alle Leads
aller Scouts, dazu dieselben in der Suche und in "Was ist dran". Das war
die letzte Stelle, an der "nur DogFather sieht alles" noch nicht galt.

EINE EIGENE TABELLE, KEIN ZWEITER EINTRAG IN `betreuung`.
Dort heisst die Spalte creator_id, und der ganze uebrige Code liest sie
als "das ist ein Creator". Ein Scout darin waere technisch moeglich und
fachlich eine Luege gewesen: betreuteIds() gaebe Scout-Nummern zurueck,
die anderswo als Creator behandelt wuerden. Solche Abkuerzungen raechen
sich genau dann, wenn niemand mehr weiss, dass sie getroffen wurden.

DIE KETTE steht an EINER Stelle (betreuteIds in workspace.js):
Manager -> seine Scouts -> deren Creator. Ohne sie muesste jeder Creator
einem Manager einzeln zugewiesen werden, und beim ersten vergessenen
faende er ein Loch in seiner Uebersicht, ohne zu merken, dass es eines
ist. Dieselbe Regel gilt fuer Leads in Pipeline, Suche und Hinweisen --
aus einer Quelle (pipelineIds), nicht dreimal abgeschrieben.

ZUTEILEN DARF NUR DOGFATHER, und das ist keine Foermlichkeit: Diese
Zuteilung ERWEITERT die Sicht eines Managers. Duerfte er sie selbst
setzen, koennte er sich seine eigene Sichtbarkeit vergeben -- eine
Grenze, die der Begrenzte selbst verschieben kann, ist keine. Deshalb
istDogFather und ausdruecklich NICHT istLeitung.

In der Personenliste steht bei jedem Scout "Gehoert zu", sichtbar nur
fuer DogFather. Der Leerwert heisst "— direkt bei DogFather —" und nicht
"— niemand —": Ein Scout ohne Manager ist nicht unbetreut, er haengt an
DogFather. Das ist ein Zustand, kein Mangel.

NEBENBEI KORRIGIERT: In der Zustaendigkeits-Route stand als Kommentar
noch "ein Eintrag auf DogFather oder Manager aendert an den Rechten
nichts, die Leitung sieht ohnehin jeden Creator". Das gilt seit heute
nicht mehr -- fuer einen Manager entscheidet dieser Eintrag jetzt sehr
wohl ueber die Sichtbarkeit. Ein falscher Kommentar ist schlimmer als
keiner: Er wird geglaubt.

DIE PRUEFUNG STELLT DEN MISSBRAUCH AN DEN ANFANG. Diese Aenderung
erweitert Sichtbarkeit -- alles andere heute hat sie eingeschraenkt. Ein
Fehler dort zeigt jemandem zu wenig und faellt auf; ein Fehler hier
zeigt zu viel und faellt niemandem auf. Geprueft wird deshalb: Manager
und Scout duerfen nicht zuteilen (404, und es wird auch wirklich nichts
geschrieben), Scout an Scout und Scout an DogFather werden abgewiesen,
ein Creator laesst sich nicht zuteilen. Danach die Kette in beide
Richtungen, das Zuruecknehmen, und dass ein Scout zu genau einem Manager
gehoert.

Ein lehrreicher Fehlschlag in der Pruefung selbst: Sie meldete, die
Auswahl fehle in der Oberflaeche. Sie fehlte nicht -- die Personenliste
ist nach Rollen ZUGEKLAPPT, und die Pruefung hatte nicht aufgeklappt.
Sah aus wie ein Produktfehler, war einer der Pruefung. Sie klappt jetzt
auf und stellt vorher fest, dass wirklich alle sieben Zeilen dastehen.

Gesamtlauf: 30 von 30 Dateien, 1210 von 1210 Einzelpunkten.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-01 22:44:30 +02:00

523 lines
24 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.
/* =====================================================================
workspace-personen.js — Personen und Zugangscodes über den Browser
verwalten. Ausschließlich für die Rolle "admin".
Bisher ging das nur per SSH über workspace-code.js. Das bleibt als
Notweg bestehen (etwa wenn niemand mehr hineinkommt), für den Alltag
ist es aber zu umständlich.
Zum Anzeigen des Codes im Browser: Der Code wird genau einmal in der
Antwort auf das Anlegen zurückgegeben und danach nirgends gespeichert
-- in der Datenbank steht nur sein scrypt-Hash. Das ist dasselbe
Verfahren, das etwa GitHub für Zugriffstoken verwendet. Er läuft über
HTTPS und landet weder im Protokoll noch im Serverlog.
===================================================================== */
import express from "express";
import {
db, protokolliere, echteIp, sitzungLesen, personAnlegen, codeNeu, personSperren, betreuungSetzen, scoutZuteilungSetzen, istLeitung, istDogFather, ROLLEN_SORTIERUNG, ROLLEN_REIHE,
} from "./workspace.js";
import { sicherungJetzt } from "./workspace-sicherung.js";
export const personenRouter = express.Router();
/* Reihenfolge und Umfang kommen aus workspace.js -- eine eigene
Liste hier waere die naechste Stelle, die beim Aendern vergessen wird. */
const ROLLEN = ROLLEN_REIHE;
const NAME_MAX = 60;
/* Nur Management. Alles andere bekommt 404 statt 403 -- wer nicht
berechtigt ist, muss nicht erfahren, dass es diesen Bereich gibt. */
function nurAdmin(req, res, next) {
const person = sitzungLesen(req);
if (!person) return res.status(401).json({ fehler: "nicht_angemeldet" });
if (!istLeitung(person)) return res.status(404).json({ fehler: "nicht_gefunden" });
req.person = person;
next();
}
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();
}
personenRouter.use("/workspace/api/verwaltung", nurAdmin);
/* ---------------------------------------------------------------------
Schranke: An DogFather und Managern aendert nur DogFather etwas.
Sie haengt an JEDEM Weg mit einer :id, nicht an einzelnen Routen. Der
erste Versuch sicherte nur Anlegen und Sperren ab -- und prompt blieb
"neuer Zugangscode" offen. Ein Manager konnte DogFather einen neuen
Code ausstellen, bekam ihn angezeigt und haette ihn damit aus seinem
eigenen Konto ausgesperrt. Genau das soll "nur DogFather hat alle
endgueltigen Rechte" verhindern.
Als Schranke statt als Einzelpruefung, damit der naechste Weg, der
hier dazukommt, automatisch mitgeschuetzt ist. */
function nurDogFatherBeiLeitung(req, res, next) {
if (istDogFather(req.person)) return next();
const id = Number(req.params.id);
if (!Number.isInteger(id)) return next();
const ziel = db().prepare("SELECT rolle FROM personen WHERE id = ?").get(id);
if (ziel && (ziel.rolle === "admin" || ziel.rolle === "manager")) {
return res.status(403).json({
fehler: "An DogFather und Managern ändert nur DogFather etwas.",
});
}
next();
}
/* ---------- Übersicht --------------------------------------------------- */
/* Sortierung: Die ROLLE zuerst, dann erst der Zustand.
Vorher stand "p.aktiv DESC" ganz vorn -- dadurch wanderte jede
gesperrte Person ans Ende der GESAMTEN Liste, quer durch alle Rollen.
Ein gesperrter Manager stand also unter den Creators, und die
Reihenfolge DogFather-Manager-Scout-Creator, die ueberall sonst gilt,
war ausgerechnet auf der Personenseite aufgehoben.
Jetzt: Rolle, dann Gesperrtes ans Ende SEINER Rolle, dann Name.
(Der Kommentar steht bewusst hier und nicht in der Abfrage: Er enthaelt
Rueckwaerts-Anfuehrungszeichen, und die beenden mitten in einer
Zeichenkette genau diese -- der Server startete danach nicht mehr.) */
personenRouter.get("/workspace/api/verwaltung/personen", (req, res) => {
try {
res.json({
personen: db().prepare(`
SELECT p.id, p.name, p.rolle, p.aktiv, p.erstellt, p.letzter_login,
(SELECT COUNT(*) FROM sitzungen s WHERE s.person_id = p.id) AS sitzungen,
(SELECT COUNT(*) FROM aufgaben a
WHERE (a.creator_id = p.id OR a.verantwortlich_id = p.id)
AND a.status <> 'erledigt') AS offene_aufgaben,
b.betreuer_id,
(SELECT name FROM personen x WHERE x.id = b.betreuer_id) AS betreuer_name,
(SELECT COUNT(*) FROM betreuung y WHERE y.betreuer_id = p.id) AS betreut_anzahl,
/* Manager -> Scouts (01.09.2026). Bei einem Scout steht
hier, wem er zugeteilt ist; bei einem Manager, wie viele
Scouts an ihm haengen. Beides aus derselben Abfrage --
eine zweite waere eine zweite Gelegenheit, dass die
Liste etwas anderes sagt als die Rechte. */
sz.manager_id,
(SELECT name FROM personen m WHERE m.id = sz.manager_id) AS manager_name,
(SELECT COUNT(*) FROM scout_zuteilung z WHERE z.manager_id = p.id) AS scouts_anzahl
FROM personen p
LEFT JOIN betreuung b ON b.creator_id = p.id
LEFT JOIN scout_zuteilung sz ON sz.scout_id = p.id
ORDER BY ${ROLLEN_SORTIERUNG.replace("rolle", "p.rolle")}, p.aktiv DESC, p.name`).all(),
/* Wer ueberhaupt als zustaendig eingetragen werden kann.
Bis zum 31.08.2026 waren das nur Scouts. In der Auswahl stand
"DogFather" -- aber als LEER-Wert, nicht als Person. Das sah aus
wie eine Zuordnung und war keine: Dieselben Creator zaehlten
gleichzeitig im Hinweis "Creator ohne zustaendige Person". Zwei
Stellen, zwei Aussagen, beide auf demselben Bildschirm.
Jetzt kann jede betreuende Rolle eingetragen werden -- DogFather
und Manager genauso wie Scouts. In der ueblichen Reihenfolge. */
betreuer: db().prepare(
`SELECT id, name, rolle FROM personen
WHERE rolle IN ('admin', 'manager', 'scout') AND aktiv = 1
ORDER BY ${ROLLEN_SORTIERUNG}, name`).all(),
});
} catch (fehler) {
console.error("[workspace] Personen lesen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* ---------- Zuständigkeit ------------------------------------------------
Wer betreut welchen Creator. Nur das Management setzt das -- sonst
koennte sich ein Scout selbst Creator zuteilen und haette damit die
Rechtevergabe in der Hand, die ihn eigentlich begrenzen soll. */
personenRouter.put("/workspace/api/verwaltung/betreuung/:id", gleicheHerkunft, (req, res) => {
try {
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
const creator = db().prepare("SELECT id, rolle FROM personen WHERE id = ?").get(id);
if (!creator || creator.rolle !== "creator") {
return res.status(404).json({ fehler: "nicht_gefunden" });
}
const w = req.body?.betreuer_id;
if (w === null || w === "" || w === undefined) {
betreuungSetzen(id, null, { ...req.person, ip: echteIp(req) });
return res.json({ ok: true, betreuer_id: null });
}
const z = Number(w);
if (!Number.isInteger(z) || z < 1) return res.status(400).json({ fehler: "Ungültige Auswahl." });
const betreuer = db().prepare(
"SELECT id, name, rolle FROM personen WHERE id = ? AND aktiv = 1").get(z);
/* DogFather, Manager und Scouts. Ein Creator kann nicht fuer einen
anderen zustaendig sein -- das waere eine Rolle, die es nicht gibt.
ACHTUNG, SEIT DEM 01.09.2026 ANDERS: Hier stand frueher "ein
Eintrag auf DogFather oder Manager aendert an den Rechten nichts,
die Leitung sieht ohnehin jeden Creator". Das gilt nicht mehr --
nur noch DogFather sieht alles. Fuer einen MANAGER entscheidet
dieser Eintrag jetzt genauso ueber die Sichtbarkeit wie fuer einen
Scout: Wer ihm nicht zugeteilt ist (weder direkt noch ueber einen
seiner Scouts), taucht bei ihm nicht auf.
Nur bei DogFather sagt der Eintrag weiterhin bloss, WER sich
kuemmert. Die Regel dazu steht an genau einer Stelle:
betreuteIds() in workspace.js. */
if (!betreuer || !["admin", "manager", "scout"].includes(betreuer.rolle)) {
return res.status(400).json({
fehler: "Zuständig können nur aktive DogFather, Manager oder Scouts sein.",
});
}
betreuungSetzen(id, z, { ...req.person, ip: echteIp(req) });
res.json({ ok: true, betreuer_id: z, betreuer_name: betreuer.name });
} catch (fehler) {
console.error("[workspace] Betreuung setzen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* ---------- Welcher Scout gehoert zu welchem Manager --------------------
"er soll nur die Scouts sehen, die ihm zugeteilt sind." (01.09.2026)
NUR DOGFATHER darf das setzen -- ausdruecklich so entschieden, und
der Grund ist nicht Misstrauen, sondern Bauart: Diese Zuteilung
ERWEITERT die Sicht eines Managers (auf die Leads seiner Scouts und
auf deren Creator). Duerfte er sie selbst setzen, koennte er sich
seine eigene Sichtbarkeit vergeben -- und eine Grenze, die der
Begrenzte selbst verschieben kann, ist keine.
Deshalb istDogFather und NICHT istLeitung. Der Unterschied ist hier
der ganze Punkt. */
personenRouter.put("/workspace/api/verwaltung/scout-zuteilung/:id", gleicheHerkunft, (req, res) => {
try {
if (!istDogFather(req.person)) {
/* 404 und nicht 403: Wer es nicht darf, soll nicht einmal
erfahren, dass es diesen Weg gibt. */
return res.status(404).json({ fehler: "nicht_gefunden" });
}
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
const scout = db().prepare("SELECT id, rolle FROM personen WHERE id = ?").get(id);
if (!scout || scout.rolle !== "scout") {
return res.status(404).json({ fehler: "nicht_gefunden" });
}
const w = req.body?.manager_id;
if (w === null || w === "" || w === undefined) {
scoutZuteilungSetzen(id, null, req.person.id);
protokolliere("scout_zuteilung", req.person, echteIp(req), `${id}: geloest`);
return res.json({ ok: true, manager_id: null });
}
const z = Number(w);
if (!Number.isInteger(z) || z < 1) return res.status(400).json({ fehler: "Ungültige Auswahl." });
const manager = db().prepare(
"SELECT id, name, rolle FROM personen WHERE id = ? AND aktiv = 1").get(z);
/* NUR ein Manager. Ein Scout unter einem Scout waere eine Ordnung,
die es nicht gibt; ein Scout unter DogFather ist ueberfluessig, da
er ohnehin alles sieht -- und ein Eintrag, der nichts bewirkt,
wird beim naechsten Mal fuer eine Wirkung gehalten. */
if (!manager || manager.rolle !== "manager") {
return res.status(400).json({ fehler: "Zuteilen kann man nur an einen aktiven Manager." });
}
scoutZuteilungSetzen(id, z, req.person.id);
protokolliere("scout_zuteilung", req.person, echteIp(req), `${id} -> ${z}`);
res.json({ ok: true, manager_id: z, manager_name: manager.name });
} catch (fehler) {
console.error("[workspace] Scout-Zuteilung:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* ---------- Anlegen ----------------------------------------------------- */
personenRouter.post("/workspace/api/verwaltung/personen", gleicheHerkunft, (req, res) => {
try {
const name = String(req.body?.name ?? "").trim();
const rolle = String(req.body?.rolle ?? "");
if (name.length < 2) return res.status(400).json({ fehler: "Name fehlt." });
if (name.length > NAME_MAX) return res.status(400).json({ fehler: "Name ist zu lang." });
if (!ROLLEN.includes(rolle)) return res.status(400).json({ fehler: "Unbekannte Rolle." });
/* ERSTER VORBEHALT: Eine Leitung anlegen darf nur DogFather.
Duerfte ein Manager das, koennte er sich einen zweiten Zugang mit
vollen Rechten schaffen -- und waere damit nicht mehr begrenzbar.
"Nur DogFather hat alle endgueltigen Rechte" faengt hier an. */
if (!istDogFather(req.person) && (rolle === "admin" || rolle === "manager")) {
return res.status(403).json({
fehler: "DogFather und Manager legt nur DogFather selbst an.",
});
}
const vorhanden = db().prepare(
"SELECT 1 FROM personen WHERE lower(name) = lower(?) AND aktiv = 1").get(name);
if (vorhanden) return res.status(409).json({ fehler: "Diesen Namen gibt es schon." });
const neu = personAnlegen(name, rolle, { ...req.person, ip: echteIp(req) });
/* Der Code steht NUR hier in der Antwort. Danach ist er weg. */
res.status(201).json({ id: neu.id, name: neu.name, rolle: neu.rolle, code: neu.code });
} catch (fehler) {
console.error("[workspace] Person anlegen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* ---------- Neuer Code -------------------------------------------------- */
personenRouter.post("/workspace/api/verwaltung/personen/:id/code", gleicheHerkunft, nurDogFatherBeiLeitung, (req, res) => {
try {
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
if (id === req.person.id) {
/* Sich selbst den Code zu tauschen wirft einen sofort hinaus (alle
Sitzungen werden beendet). Erlaubt, aber nur bewusst. */
if (!req.body?.auch_mich) {
return res.status(400).json({ fehler: "eigener_code", hinweis:
"Das beendet deine eigene Sitzung sofort." });
}
}
const neu = codeNeu(id, { ...req.person, ip: echteIp(req) });
res.json({ id: neu.id, name: neu.name, rolle: neu.rolle, code: neu.code });
} catch (fehler) {
if (/Keine Person/.test(fehler?.message || "")) {
return res.status(404).json({ fehler: "nicht_gefunden" });
}
console.error("[workspace] Code erneuern:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* ---------- Sperren / Entsperren ---------------------------------------- */
personenRouter.patch("/workspace/api/verwaltung/personen/:id", gleicheHerkunft, nurDogFatherBeiLeitung, (req, res) => {
try {
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
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" });
if (req.body?.aktiv !== undefined) {
const aktiv = req.body.aktiv ? 1 : 0;
/* Sich selbst zu sperren würde den letzten Zugang zusperren können.
Deshalb gar nicht erst erlauben. */
if (id === req.person.id && !aktiv) {
return res.status(400).json({ fehler: "Du kannst dich nicht selbst sperren." });
}
/* Und niemals den letzten aktiven DogFather sperren -- sonst kann
niemand mehr eine Leitung anlegen, auch kein Manager.
Bewusst istDogFather und NICHT istLeitung: Manager duerfen
gesperrt werden, es gibt ja noch DogFather. Die Massenumstellung
auf istLeitung hatte das hier faelschlich mitgezogen -- gezaehlt
werden aber nur DogFather-Zugaenge, also blockierte die Regel
plotzlich auch das Sperren eines Managers. */
if (!aktiv && istDogFather(person)) {
const { n } = db().prepare(
"SELECT COUNT(*) AS n FROM personen WHERE rolle = 'admin' AND aktiv = 1").get();
if (n <= 1) return res.status(400).json({ fehler: "Das ist der letzte aktive DogFather-Zugang." });
}
personSperren(id, aktiv, { ...req.person, ip: echteIp(req) });
}
if (req.body?.name !== undefined) {
const name = String(req.body.name).trim();
if (name.length < 2 || name.length > NAME_MAX) {
return res.status(400).json({ fehler: "Name ist ungültig." });
}
db().prepare("UPDATE personen SET name = ? WHERE id = ?").run(name, id);
protokolliere("person_umbenannt", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `${person.name} -> ${name}`,
});
}
res.json({ ok: true });
} catch (fehler) {
console.error("[workspace] Person ändern:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* =====================================================================
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) => {
try {
const anzahl = Math.min(Math.max(Number(req.query.anzahl) || 40, 1), 200);
res.json({
eintraege: db().prepare(`
SELECT k.zeitpunkt, k.aktion, k.rolle, k.detail, k.ip, p.name AS wer
FROM protokoll k LEFT JOIN personen p ON p.id = k.person_id
ORDER BY k.id DESC LIMIT ?`).all(anzahl),
});
} catch {
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});