Gemeldet: "ich hab einen neuen code fuer mich gemacht aber ich wurde raus
gekickt bevor ich den neuen code kopieren konnte jetzt komm ich nicht mehr
rein."
DER FEHLER
Ein neuer Code beendete ALLE Sitzungen der Person -- auch die, in der der
Code gerade auf dem Bildschirm stand. Der naechste Aufruf der Seite lief in
ein "nicht angemeldet", die Umleitung zur Anmeldung nahm den Kasten samt
Code mit, und der Code ist nirgends noch einmal abrufbar (in der Datenbank
steht nur seine Pruefsumme). Ergebnis: ausgesperrt, Rueckweg nur ueber
einen Eingriff auf dem Server.
Bitter daran: Die Rueckfrage sagte das sogar an ("Deine aktuelle Sitzung
wird sofort beendet") -- als Warnung formuliert, nicht als Fehler erkannt.
Ein Ablauf, den man nur mit gutem Timing ueberlebt, ist keiner.
DREI RIEGEL, NICHT EINER
1. DIE EIGENE SITZUNG BLEIBT. codeNeu() beendet weiterhin alle Sitzungen
der Person -- ausser der einen, aus der heraus der Code gerade erneuert
wird. Sicherheitlich kostet das nichts: Wer den Code tauscht, hat sich
mit genau dieser Sitzung soeben ausgewiesen und haelt sie in Haenden.
Alle ANDEREN Geraete fliegen weiterhin hinaus -- das ist der Sinn der
Uebung und wird eigens geprueft.
2. DER KASTEN BLEIBT STEHEN. Solange ein frischer Code angezeigt wird,
springt die Personenseite nicht mehr von selbst zur Anmeldung. Selbst
wenn eine Sitzung aus einem anderen Grund endet (Zeitablauf, Neustart),
bleibt der Code lesbar, bis er weggeklickt ist -- mit einem Hinweis,
ihn jetzt abzuschreiben. Ein Code, den man nicht mehr lesen kann, ist
schlimmer als gar keiner.
3. EINE TUER VON AUSSEN: tools/notfall-code.sh. Setzt auf dem Server einen
neuen Code, zeigt ihn an und loescht die Sperre nach acht Fehlversuchen
gleich mit. Weigert sich, als root zu laufen (sonst gehoerten die
Hilfsdateien der Datenbank danach root und der Dienst koennte nicht
mehr schreiben). Dokumentiert als "Fall 0" in WIEDERHERSTELLUNG.md --
dem ersten Fall, den man aufschlaegt, wenn nichts kaputt ist ausser
dem Zugang.
KEIN fest hinterlegter Notfall-Code in der Anwendung: Der waere eine
Hintertuer, die dauerhaft offensteht, fuer jeden der sie findet, ohne
dass es auffiele. Dieser Weg verlangt Zugang zum Server, hinterlaesst
einen Protokolleintrag, und es gibt nichts zu erraten.
Die Rueckfrage sagt jetzt, was wirklich passiert, statt vor etwas zu
warnen, das nicht mehr eintritt.
GEPRUEFT: server/pruef-code.mjs, 17 Pruefungen -- darunter die Gegenprobe,
dass das ZWEITE Geraet derselben Person sehr wohl abgemeldet wird (ohne sie
waere die Reparatur auf dem Weg, einen neuen Code zur Formalie zu machen),
dass der alte Code nicht mehr gilt, dass beim Erneuern eines FREMDEN Codes
weiterhin alles hinausfliegt, und dass die Seite nach dem Erzeugen nicht
zur Anmeldung springt. Das Notfall-Skript ist mit beiden Wegen getestet
(Treffer und unbekannter Name). Bestehende Laeufe gruen: Rollen 97,
Personen-Liste 33, Sicht 48.
Co-Authored-By: Claude Opus 5 <[email protected]>
545 lines
25 KiB
JavaScript
545 lines
25 KiB
JavaScript
/* =====================================================================
|
||
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, sitzungToken, 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);
|
||
/* MANAGER ODER DOGFATHER -- wie bei den Creatorn (02.09.2026:
|
||
"ich will die Rollen, welcher Scout welchem Manager oder DogFather
|
||
gehoert, wie es bei den Creator ist").
|
||
|
||
Ein Scout unter einem Scout bleibt ausgeschlossen: Das waere eine
|
||
Ordnung, die es nicht gibt. Ein Creator kann ohnehin niemanden
|
||
fuehren.
|
||
|
||
WICHTIG ZUM VERSTAENDNIS -- die beiden Faelle bewirken
|
||
Verschiedenes, und das ist Absicht:
|
||
MANAGER Der Eintrag entscheidet ueber SICHTBARKEIT. Er sieht
|
||
danach die Leads dieses Scouts und dessen Creator.
|
||
DOGFATHER Der Eintrag sagt nur, WER zustaendig ist. An den
|
||
Rechten aendert er nichts -- DogFather sieht ohnehin
|
||
alles.
|
||
Genau so ist es bei "Betreut von" der Creator auch. Ein Eintrag,
|
||
der die Zustaendigkeit festhaelt, ist kein Eintrag ohne Wirkung:
|
||
Er beantwortet die Frage "wen frage ich?". */
|
||
if (!manager || !["manager", "admin"].includes(manager.rolle)) {
|
||
return res.status(400).json({
|
||
fehler: "Zuteilen kann man nur an einen aktiven Manager oder DogFather.",
|
||
});
|
||
}
|
||
|
||
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" });
|
||
const eigener = id === req.person.id;
|
||
if (eigener) {
|
||
/* Den eigenen Code zu tauschen bleibt eine bewusste Entscheidung --
|
||
alle anderen Geräte werden abgemeldet, und der alte Code gilt
|
||
nicht mehr. Seit dem 02.09.2026 wirft es einen aber NICHT mehr
|
||
selbst hinaus: Diese eine Sitzung bleibt, damit man den neuen
|
||
Code in Ruhe abschreiben kann (siehe codeNeu). */
|
||
if (!req.body?.auch_mich) {
|
||
return res.status(400).json({ fehler: "eigener_code", hinweis:
|
||
"Der alte Code gilt danach nicht mehr, und alle anderen Geräte "
|
||
+ "werden abgemeldet. Hier bleibst du angemeldet." });
|
||
}
|
||
}
|
||
const neu = codeNeu(id, { ...req.person, ip: echteIp(req) },
|
||
eigener ? sitzungToken(req) : null);
|
||
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" });
|
||
}
|
||
});
|