DogFatherGitandClaude Opus 5
628b99943e
Am 03.10.2026 am laufenden System nachgemessen: 20 aktive Personen, aber nur 8 mit einer Push-Anmeldung. Zwoelf bekommen keine einzige Benachrichtigung -- darunter ein Modi und die linke Hand. Das war fuer niemanden sichtbar. Die Glocke sagt es nur dem, der sie anschaut, und wer etwas Wichtiges schreibt, konnte nicht wissen, wen es erreicht. Die Dringlichkeit, die heute frueh behoben wurde, hilft diesen zwoelf gar nichts: Ohne Anmeldung geht nichts hinaus. Der Hinweis steht jetzt auf der Personenseite, also dort, wo ohnehin ueber Personen entschieden wird -- nicht auf einer eigenen Seite, die niemand aufruft. Aus DERSELBEN Abfrage wie alles andere; eine zweite waere eine zweite Gelegenheit, dass die Liste etwas anderes sagt als die Wirklichkeit. NUR BEIM FEHLEN, UND DAS IST ABSICHT. Stuende bei jeder Person eine Zeile, stuenden bei zwanzig Personen zwanzig Zeilen da, und die, auf die es ankommt, gingen darin unter -- eine Angabe, die immer kommt, wird nicht mehr gelesen. Schweigen heisst hier: erreichbar. Die Zeilen verschwinden eine nach der anderen, sobald jemand die Glocke anschaltet. Nicht bei gesperrten Personen: Dort ist es keine Luecke, sondern richtig so. pruef-personen-liste 33 -> 37, mit der Gegenprobe in beide Richtungen: Eine Person bekommt im Testbestand ein angemeldetes Geraet, und bei genau ihr darf der Hinweis NICHT stehen. Stuende er ueberall, waere "er steht da" wertlos. Gegengemessen, dass die zusaetzliche Zeile nichts verschiebt: pruef-personen-kachel 45, pruef-hand-personen 49, pruef-modi-verborgen 94, pruef-betreuung 18, pruef-scout-zuteilung (liest dieselbe Klasse .person__bezug) -- alle ohne Fehler. Co-Authored-By: Claude Opus 5 <[email protected]>
1427 lines
68 KiB
JavaScript
1427 lines
68 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";
|
||
/* WO SICH DIESE ROLLE ANMELDET -- aus derselben Datei, die auch die
|
||
Weiche steuert. Eine zweite Liste von Adressen waere die, die beim
|
||
naechsten Umzug stehen bleibt. */
|
||
import { anmeldeAdresseFuer } from "./crew-adresse.js";
|
||
import {
|
||
db, protokolliere, echteIp, sitzungLesen, personAnlegen, codeNeu, sitzungToken, personSperren, betreuungSetzen, scoutZuteilungSetzen, istLeitung, istDogFather, siehtModis, siehtAlles, ROLLEN_SORTIERUNG, ROLLEN_REIHE, istSpicy, verborgeneIds, TEAM_DOGI_ROLLEN, darfAnlegen, darfRollenWechseln, darfRolleAendern, rollenZumAendern, hausBedingung, istHand, fuehrtDieZugaenge,
|
||
} 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. */
|
||
/* NUR DogFather -- seit dem 02.09.2026 auch wirklich.
|
||
|
||
Hier stand istLeitung, und damit kam auch jede Managerin an die
|
||
Personenverwaltung: Codes erneuern, sperren, Zuteilungen ändern. Die
|
||
Rollenauswahl im selben Programm versprach dabei die ganze Zeit das
|
||
Gegenteil -- "Manager: dieselben Rechte wie DogFather, AUSSER der
|
||
Personenverwaltung".
|
||
|
||
Eine Beschreibung, die etwas anderes sagt als die Software, ist
|
||
schlimmer als beides einzeln: Man weiss danach nicht mehr, welcher
|
||
von beiden man glauben soll. Jetzt sagen beide dasselbe.
|
||
|
||
Wunsch vom 02.09.2026: "die manager sollen diese kategorien garnicht
|
||
sehen."
|
||
|
||
Weiterhin 404 statt 403: Wer nicht hierher gehört, 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" });
|
||
|
||
/* EINE EINZIGE AUSNAHME: die LISTE fuer Spicy Media (07.09.2026).
|
||
|
||
Filipe: "spicy soll genau das sehen koennen, aber nur nicht die
|
||
rolle dogfather." Bis hierher sah die Rolle auf der Personenseite
|
||
nur das Anlegen-Formular.
|
||
|
||
Die Ausnahme steht HIER und nicht als eigene Schicht davor. Der
|
||
erste Versuch war genau das -- eine Route vor `use(nurAdmin)`, die
|
||
mit `next("route")` weiterreicht. Das tut aber das Gegenteil von
|
||
dem, wonach es klingt: `next("route")` ueberspringt die restlichen
|
||
Handler DIESER Route und geht zur naechsten passenden Schicht --
|
||
also zu nurAdmin. Spicy Media bekam weiter 404, die Oberflaeche
|
||
verstand das als "nicht erlaubt" und schickte sie auf die
|
||
Startseite zurueck. Gemessen: Auf personen.html standen die
|
||
Kategorien der STARTSEITE.
|
||
|
||
Nur LESEN, nur diese eine Adresse, nur diese eine Rolle. Codes,
|
||
Sperren, Loeschen, Zuteilung und Protokoll bleiben bei DogFather --
|
||
Ueberblick ist nicht Verwaltung. Und DogFathers eigene Zeile faellt
|
||
unten aus dem Ergebnis (`req.ohneDogFather`). */
|
||
const nurListe = req.method === "GET"
|
||
&& req.baseUrl + req.path === "/workspace/api/verwaltung/personen";
|
||
if (istSpicy(person) && nurListe) {
|
||
req.person = person;
|
||
req.ohneDogFather = true;
|
||
return next();
|
||
}
|
||
|
||
/* DIE RECHTE HAND LIEST MIT (10.09.2026).
|
||
|
||
Filipe: "ich muss alle kategorien da sehen. und ich will dass die
|
||
rechte hand auch alle sieht."
|
||
|
||
LESEN, NICHT VERWALTEN -- und das ist keine Vorsicht von mir,
|
||
sondern sein eigenes Wort: "sieht". Codes, Sperren, Loeschen,
|
||
Rollen vergeben und das Protokoll bleiben bei DogFather; "Nur
|
||
DogFather hat alle endgueltigen Rechte" gilt unveraendert.
|
||
|
||
DIESELBE BAUWEISE WIE BEI SPICY MEDIA darueber: eine Methode, eine
|
||
Adresse, eine Rolle. Wer hier etwas anderes einbaut, hat zwei
|
||
Fassungen derselben Ausnahme -- und die zweite ist die, die
|
||
irgendwann mehr durchlaesst als gedacht.
|
||
|
||
WELCHE Menschen sie zu sehen bekommt, entscheidet sie nicht: Auf
|
||
ihrer Adresse grenzt `hausBedingung` die Liste ohnehin auf Team
|
||
Dogi ein. */
|
||
/* AUCH DIE LINKE HAND -- ABER NUR DIE LISTE (21.09.2026).
|
||
Sie muss sehen, wem sie eine Aufgabe geben kann. Anlegen darf sie
|
||
niemanden; das entscheidet nicht diese Zeile, sondern ANLEGBAR. */
|
||
if (istHand(person) && nurListe) {
|
||
req.person = person;
|
||
return next();
|
||
}
|
||
|
||
/* SPICY MEDIA DARF ROLLEN WECHSELN (11.09.2026).
|
||
|
||
Filipe: "ich will dass die rolle spicy und dogfather, auch die
|
||
rollen wechseln koennen wenn die personen schon drin sind. von
|
||
alle kategorien, creator, scouts, manager spicy."
|
||
|
||
DRITTE AUSNAHME, GLEICHE BAUWEISE wie die beiden darueber: eine
|
||
Methode, eine Adresse, eine Rolle. Wer hier etwas anderes baut,
|
||
hat drei Fassungen derselben Ausnahme -- und die dritte laesst
|
||
irgendwann mehr durch als gedacht.
|
||
|
||
Codes, Sperren, Loeschen, Zuteilung und Protokoll bleiben bei
|
||
DogFather. Filipe hat das Rollenwechseln genannt, nicht die
|
||
Verwaltung.
|
||
|
||
DER PFAD TRAEGT EINE NUMMER, laesst sich also nicht wie oben
|
||
vergleichen. Das Muster ist absichtlich streng: genau
|
||
/personen/<Ziffern>/rolle, nichts davor und nichts danach.
|
||
|
||
WELCHE Rolle sie vergeben darf, steht NICHT hier -- das entscheidet
|
||
ANLEGBAR in der Route. Diese Zeile oeffnet nur die Tuer. */
|
||
/* DIE RECHTE HAND LEGT PERSONEN AN UND SIEHT IHRE CODES (22.09.2026).
|
||
|
||
Filipe: "damit sie das auch machen kann wenn er live ist."
|
||
|
||
NUR DIE RECHTE, NICHT DIE LINKE. `istHand()` wuerde beide treffen;
|
||
fuer die linke Hand ist "legt niemanden an" eine ausdrueckliche
|
||
Entscheidung vom 21.09. Deshalb steht hier die Rolle und nicht der
|
||
Sammelbegriff -- der haette die Entscheidung stillschweigend
|
||
umgedreht.
|
||
|
||
ZWEI WEGE, NICHT DIE GANZE VERWALTUNG: anlegen und einen Code neu
|
||
erzeugen. Sperren, Loeschen, Betreuung und Protokoll bleiben bei
|
||
DogFather. Und WELCHE Rolle sie anlegen darf, entscheidet nicht
|
||
diese Zeile, sondern ANLEGBAR in der Route -- diese Tuer oeffnet
|
||
nur den Weg.
|
||
|
||
WARUM AUCH "Code neu erzeugen": Ein Code wird genau einmal
|
||
angezeigt. Geht er verloren, ist der Zugang ohne diesen Weg tot --
|
||
und dann muesste doch wieder DogFather ran, also genau das, was
|
||
nicht sein soll. */
|
||
const anlegeWeg = req.method === "POST"
|
||
&& req.baseUrl + req.path === "/workspace/api/verwaltung/personen";
|
||
const codeWeg = req.method === "POST"
|
||
&& /^\/workspace\/api\/verwaltung\/personen\/[0-9]+\/code$/
|
||
.test(req.baseUrl + req.path);
|
||
/* SPERREN UND LOESCHEN KOMMEN DAZU (24.09.2026).
|
||
|
||
Filipe: „die rechte hand soll das auch sehen. und die selben
|
||
rechte da haben wie dogfather. das einzige was sie nicht kann ist
|
||
die dogfather rolle oder leute anfassen. also da kann sie nichts
|
||
verändern."
|
||
|
||
„Das einzige" ist der Punkt. Bis heute blieben Sperren und
|
||
Loeschen ausdruecklich bei DogFather (siehe der Absatz darueber,
|
||
22.09.) -- das ist damit ueberholt.
|
||
|
||
WAS SIE WEITERHIN NICHT KANN, steht nicht hier, sondern in den
|
||
Routen: An DogFather und Managern aendert nur DogFather etwas
|
||
(`ziel.rolle === "admin" || "manager"`), und welche Rollen sie
|
||
ueberhaupt anfassen darf, sagt ANLEGBAR. Diese Tuer oeffnet nur
|
||
den Weg -- wen er trifft, entscheidet die Route dahinter.
|
||
|
||
LOESCHEN IST ENDGUELTIG, und der Hausgrundsatz „Nur DogFather hat
|
||
alle endgueltigen Rechte" stand dem entgegen. Filipes Ansage ist
|
||
juenger und ausdruecklich; die Sicherungen, die wirklich zaehlen
|
||
(nie den letzten DogFather, nie an einem Admin), greifen
|
||
unabhaengig davon. */
|
||
const sperrWeg = req.method === "PATCH"
|
||
&& /^\/workspace\/api\/verwaltung\/personen\/[0-9]+$/
|
||
.test(req.baseUrl + req.path);
|
||
const loeschWeg = req.method === "DELETE"
|
||
&& /^\/workspace\/api\/verwaltung\/personen\/[0-9]+$/
|
||
.test(req.baseUrl + req.path);
|
||
/* DIE VORSCHAU GEHOERT ZUM LOESCHEN. Sie sagt, wie viel an einer
|
||
Person haengt -- wer loeschen darf, muss sie sehen, sonst
|
||
entscheidet er blind. Vergessen beim ersten Anlauf, gefunden von
|
||
pruef-hand-personen ("sie sieht die Loesch-Vorschau: 404"). */
|
||
const vorschauWeg = req.method === "GET"
|
||
&& /^\/workspace\/api\/verwaltung\/personen\/[0-9]+\/loeschbar$/
|
||
.test(req.baseUrl + req.path);
|
||
/* UND DAS PROTOKOLL (25.09.2026).
|
||
|
||
Filipe, mit einem Bildschirmfoto genau dieses Kastens: „die rechte
|
||
hand sieht das immer noch nicht obwohl ich will dass die rechte
|
||
hand das auch sieht."
|
||
|
||
Damit ist auch der letzte Satz von oben ueberholt („Codes,
|
||
Sperren, Loeschen, Zuteilung und Protokoll bleiben bei
|
||
DogFather"). Seine Ansage vom 24.09. -- „die selben rechte da
|
||
haben wie dogfather, das einzige was sie nicht kann ist die
|
||
dogfather rolle oder leute anfassen" -- laesst fuer das Protokoll
|
||
keinen Rest.
|
||
|
||
NUR LESEN: eine Methode (GET), eine Adresse, keine Nummer im Pfad.
|
||
Dieselbe Bauweise wie die fuenf Wege darueber.
|
||
|
||
`fuehrtDieZugaenge` STATT `person.rolle === "hand"` -- hier stand
|
||
der Rollenname, und dieselbe Frage stand in zwei weiteren Dateien
|
||
noch einmal. DogFather kommt weiter unten ohnehin durch; dass er
|
||
hier mitgemeint ist, aendert nichts und macht die Zeile
|
||
wahrheitsfaehig. */
|
||
const protokollWeg = req.method === "GET"
|
||
&& req.baseUrl + req.path === "/workspace/api/verwaltung/protokoll";
|
||
if (fuehrtDieZugaenge(person)
|
||
&& (anlegeWeg || codeWeg || sperrWeg || loeschWeg || vorschauWeg
|
||
|| protokollWeg)) {
|
||
req.person = person;
|
||
return next();
|
||
}
|
||
|
||
const rollenWeg = req.method === "PUT"
|
||
&& /^\/workspace\/api\/verwaltung\/personen\/[0-9]+\/rolle$/
|
||
.test(req.baseUrl + req.path);
|
||
if (darfRollenWechseln(person) && rollenWeg) {
|
||
req.person = person;
|
||
return next();
|
||
}
|
||
|
||
if (!istDogFather(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);
|
||
|
||
/* DIE RECHTE HAND NUR AN DENEN, DIE SIE AUCH ANLEGEN DUERFTE
|
||
(22.09.2026).
|
||
|
||
Ohne diese Zeile koennte sie den Code einer LINKEN HAND neu
|
||
erzeugen -- und haette damit einen Zugang, der fast so viel darf
|
||
wie sie selbst, in der Hand. Das ist nicht gemeint und waere auch
|
||
nicht aufgefallen: Die Schranke darunter kennt nur "admin" und
|
||
"manager".
|
||
|
||
Gefragt wird dieselbe Liste wie beim Anlegen. Eine zweite waere
|
||
die, die beim naechsten Umbau auseinanderlaeuft. */
|
||
if (req.person?.rolle === "hand" && ziel
|
||
&& !darfAnlegen(req.person).includes(ziel.rolle)) {
|
||
return res.status(403).json({
|
||
fehler: "An dieser Rolle ändert die rechte Hand nichts.",
|
||
});
|
||
}
|
||
|
||
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 {
|
||
/* Fuer Spicy Media ohne DogFather -- gefiltert am ERGEBNIS und
|
||
nicht in der Abfrage: Die Abfrage ist lang und wird von mehreren
|
||
Feldern gelesen; eine zusaetzliche Bedingung mittendrin waere die
|
||
Stelle, an der beim naechsten Umbau jemand danebengreift. */
|
||
/* FUER SPICY MEDIA: DOGFATHER JA, DER ZWEITE ADMIN-ZUGANG NEIN.
|
||
|
||
Filipe: "die rolle spicy soll auch die rolle dogfather sehen,
|
||
aber nur dogfather sehen und nicht vanvan."
|
||
|
||
In der Datenbank tragen BEIDE die Rolle `admin` -- nachgemessen
|
||
am laufenden System: id 1 "Dogfather", id 4 "VanVan". Es gibt
|
||
kein Feld, das den einen vom anderen unterscheidet.
|
||
|
||
Der Unterschied, den es WIRKLICH gibt, ist das Alter: DogFather
|
||
ist der erste Zugang des Hauses. Deshalb zaehlt hier die
|
||
kleinste Nummer unter den Admins -- eine Eigenschaft, die
|
||
feststeht und nicht am Namen haengt.
|
||
|
||
DIE SCHWACHSTELLE STEHT HIER, damit sie niemand sucht: Wuerde
|
||
Zugang 1 je geloescht, rueckte der naechste Admin nach. Sollte
|
||
das eintreten, gehoert stattdessen ein ausdrueckliches Merkmal
|
||
in die Tabelle -- ein `haupt`-Feld. Solange es genau zwei
|
||
Admin-Zugaenge gibt und der erste DogFather ist, ist die
|
||
Nummer die ehrlichste Antwort ohne Datenbankumbau. */
|
||
/* SEIT DEM 09.09.2026 GILT DIE REGEL FUER ALLE, NICHT NUR FUER
|
||
SPICY MEDIA.
|
||
|
||
Filipe: "keiner soll vanvan sehen ausser ich, ueberall soll
|
||
keiner vanvan sehen ausser dogfather."
|
||
|
||
Hier stand eine eigene Fassung dieser Regel -- nur fuer Spicy
|
||
Media, nur an dieser Stelle. Sie ist ersetzt durch die zentrale
|
||
`verborgeneIds()` aus workspace.js, die ueberall dieselbe ist.
|
||
Zwei Fassungen derselben Regel waeren zwei Gelegenheiten, dass
|
||
eine nachgezogen wird und die andere nicht -- und bei einer
|
||
Sichtbarkeitsregel heisst das, dass jemand etwas sieht. */
|
||
const weg = new Set(verborgeneIds(req.person));
|
||
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 NOT IN ('erledigt', 'abgebrochen')) 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. */
|
||
/* ERREICHT SIE UEBERHAUPT EINE BENACHRICHTIGUNG? (03.10.2026)
|
||
|
||
Am 03.10. nachgemessen: 20 aktive Personen, aber nur
|
||
8 mit einer Anmeldung. Zwoelf bekommen nichts --
|
||
darunter ein Modi und die linke Hand. Niemand konnte
|
||
das sehen, auch sie selbst nicht: Die Glocke sagt es
|
||
nur dem, der sie anschaut.
|
||
|
||
Wer etwas Wichtiges schreibt, soll nicht raten
|
||
muessen, wen es erreicht. Deshalb steht es dort, wo
|
||
ohnehin ueber Personen entschieden wird, und nicht
|
||
auf einer eigenen Seite, die niemand aufruft.
|
||
|
||
Aus DERSELBEN Abfrage wie alles andere -- eine
|
||
zweite waere eine zweite Gelegenheit, dass die Liste
|
||
etwas anderes sagt als die Wirklichkeit. */
|
||
(SELECT COUNT(*) FROM push_anmeldungen pa
|
||
WHERE pa.person_id = p.id) AS push_geraete,
|
||
(SELECT MAX(pa.zuletzt_ok) FROM push_anmeldungen pa
|
||
WHERE pa.person_id = p.id) AS push_zuletzt,
|
||
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
|
||
WHERE 1=1${hausBedingung(req.person, "p.rolle")}
|
||
ORDER BY ${ROLLEN_SORTIERUNG.replace("rolle", "p.rolle")}, p.aktiv DESC, p.name`)
|
||
.all().filter((z) => !weg.has(z.id)),
|
||
/* 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. */
|
||
/* Auch die Auswahl "wer betreut" -- ein verborgener Zugang darf
|
||
dort nicht als Vorschlag auftauchen. */
|
||
betreuer: db().prepare(
|
||
`SELECT id, name, rolle FROM personen
|
||
WHERE rolle IN ('admin', 'manager', 'scout') AND aktiv = 1
|
||
ORDER BY ${ROLLEN_SORTIERUNG}, name`).all().filter((z) => !weg.has(z.id)),
|
||
|
||
/* =============================================================
|
||
ROLLEN, DIE NICHT IM BROWSER STEHEN DUERFEN (09.09.2026)
|
||
|
||
Die Rollenauswahl im Formular kommt sonst aus einer Liste in
|
||
assets/js/personen.js. Diese Datei bekommt JEDER ausgeliefert,
|
||
der die Seite oeffnet -- auch ein Manager, ein Scout, ein
|
||
Creator. Steht dort `modi: 'Modi'`, genuegt ein Blick in den
|
||
Quelltext, und der ganze verborgene Zugang ist verraten.
|
||
|
||
Deshalb kommt dieser eine Eintrag vom Server und nur an die
|
||
DogFather-Rolle. Wer die Rolle nicht hat, bekommt eine leere
|
||
Liste -- nicht eine gefilterte Liste, sondern gar keine
|
||
Angabe. Ein Feld, das mal Inhalt hat und mal nicht, verraet
|
||
nichts; ein Feld mit einem "darfst du nicht" darin schon.
|
||
|
||
Text und Zeichen stehen deshalb ebenfalls hier und nicht im
|
||
Browser. `schutz` ist das vorhandene Schild-Zeichen -- es passt
|
||
zur Moderation und spart ein neues, das in der Zeichenliste
|
||
wieder fuer alle sichtbar waere. */
|
||
/* SIE GEHEN AN ALLE, DIE DIE LISTE UEBERHAUPT BEKOMMEN -- also
|
||
an DogFather und an die rechte Hand, nicht an Spicy Media oder
|
||
einen Manager.
|
||
|
||
Sie sind nicht nur die Auswahl beim Anlegen, sondern seit
|
||
heute auch die UEBERSCHRIFTEN der Abschnitte: Der Browser
|
||
kennt nur die fuenf Rollen aus bereiche.js, und wer dort nicht
|
||
steht, wurde bis eben nicht gezeichnet. VanVan verschwand
|
||
genau in dem Moment aus der Liste, in dem sie die rechte Hand
|
||
wurde -- ohne Fehler, ohne Luecke, ohne Hinweis. */
|
||
/* DIE COMMUNITY STEHT NICHT IN DERSELBEN BEDINGUNG (11.09.2026).
|
||
|
||
Die beiden Eintraege unten haengen an `siehtModis` -- wer die
|
||
Modis sieht, darf sie auch anlegen. Fuer die Community gilt das
|
||
NICHT: Einen Zugang zum Treff vergibt allein DogFather (Plan
|
||
Teil C, Zeile "Zugang anlegen"). Ein Modi, der einen anlegen
|
||
koennte, koennte sich selbst Verstaerkung holen.
|
||
|
||
GEFRAGT WIRD `darfAnlegen` UND NICHT DIE ROLLE. Dieselbe
|
||
Auskunft, aus der auch die Route ihre Absage holt -- deshalb
|
||
kann hier kein Knopf erscheinen, den der Server ablehnt, und
|
||
keiner fehlen, den er annehmen wuerde. Auf der Team-Adresse
|
||
faellt er dadurch von selbst weg (darfAnlegen filtert dort auf
|
||
die Team-Rollen), und genau das ist richtig: Wer dort jemanden
|
||
anlegt, meint jemanden aus dem Team. */
|
||
/* DIE REIHENFOLGE KOMMT AUS ROLLEN_REIHE, nicht aus dieser Liste
|
||
(14.09.2026).
|
||
|
||
Filipe, mit dem Bildschirmfoto: "rechte hand soll immer ueber
|
||
modi stehen bitte." Hier stand Modi zuerst -- ROLLEN_REIHE
|
||
hatte die Rechte Hand dagegen laengst vor den Modis, und die
|
||
SQL-Sortierung ebenfalls. Eine Aussage, zwei Stellen, und die
|
||
zweite war die falsche: dasselbe Muster wie heute schon dreimal.
|
||
|
||
Sortiert wird deshalb ABGELEITET. Wer die Reihenfolge aendern
|
||
will, aendert ROLLEN_REIHE -- und alles andere zieht nach,
|
||
statt nachgezogen werden zu muessen.
|
||
|
||
Was dort NICHT steht (heute: "gast"), wandert ans Ende statt
|
||
stillschweigend nach vorn. */
|
||
zusatzrollen: [
|
||
...(darfAnlegen(req.person).includes("gast")
|
||
? [{
|
||
wert: "gast", name: "Community", symbol: "leute",
|
||
text: "Zugang zum Rudel. Sieht die sieben Bretter der Community "
|
||
+ "und sonst nichts \u2013 keine Aufgaben, keine Termine, "
|
||
+ "keine Namen aus dem Team.",
|
||
}]
|
||
: []),
|
||
...(siehtModis(req.person)
|
||
? [{
|
||
wert: "modi", name: "Modi",
|
||
/* DIE PFOTE (Filipe, 10.09.2026 mit Bildschirmfoto: "bei
|
||
rechte hand soll der husky sein und bei modis soll die
|
||
pfote sein").
|
||
|
||
Dritte Fassung, und die beiden davor sind lehrreich: Zuerst
|
||
stand hier das Schild -- falsch, es gehoert dem Scout und
|
||
stellte die Modis neben die Agentur. Dann der Husky, "das
|
||
gleiche wie bei dogfather". Beide Male ging es um dieselbe
|
||
Aussage: Die Modis gehoeren zu Dogi.
|
||
|
||
Solange es hier zwei Rollen gab, sagte der Husky das. Seit
|
||
es drei sind, sagt es die GRUPPE: Husky bei den beiden mit
|
||
dem Ueberblick, Pfote bei denen, die taeglich unterwegs
|
||
sind. Die Aussage ist dieselbe geblieben, das Zeichen dafuer
|
||
nicht. */
|
||
symbol: "pfote",
|
||
/* ECHTE UMLAUTE. In Kommentaren schreibt das Haus ASCII, in
|
||
TEXT, den jemand liest, nicht -- auf dem Bildschirmfoto
|
||
stand "Sichtbar nur fuer die DogFather-Rolle", und das sieht
|
||
aus wie ein Fehler, weil es einer ist. */
|
||
text: "Moderation und Team-Aufgaben. Sichtbar nur für die "
|
||
+ "DogFather-Rolle und für die Modis untereinander.",
|
||
}, {
|
||
/* DIE STELLVERTRETUNG (10.09.2026). Filipe: "3 rollen.
|
||
dogfather. rechte hand und modis."
|
||
|
||
Blueprint V3.0, Kapitel 3.1: "1 (austauschbar)" -- gedacht
|
||
ist EINE Person. Erzwungen wird das hier bewusst NICHT:
|
||
Beim Wechsel braucht es einen Moment, in dem die alte noch
|
||
da und die neue schon angelegt ist. Eine Sperre haette
|
||
genau diesen Moment unmoeglich gemacht.
|
||
|
||
DER HUSKY, wie bei DogFather: Sie vertritt ihn, und das
|
||
Zeichen sagt das -- ohne sie ueber jemanden zu stellen,
|
||
denn dasselbe Zeichen heisst "gleiche Sicht", nicht
|
||
"hoeher". Die Pfote, die hier zuerst stand, ist zu den
|
||
Modis gewandert. */
|
||
wert: "hand", name: "Rechte Hand", symbol: "husky",
|
||
text: "Vertritt dich im Alltag und koordiniert das Team. Sieht "
|
||
+ "dieselben Aufgaben, Ideen und Angebote wie du – aber keine "
|
||
+ "privaten Kalender und keine Einzelchats.",
|
||
}, {
|
||
/* DIE LINKE HAND (21.09.2026). Filipe: "Die linke Hand
|
||
erhaelt grundsaetzlich dieselben Rechte wie die rechte Hand
|
||
in allen Bereichen, die die Modis, Aufgaben,
|
||
Aufgabenzuweisungen, Uebersichten, Kommunikation und
|
||
Auswertungen betreffen."
|
||
|
||
DERSELBE HUSKY wie bei der rechten Hand -- sie tun
|
||
dasselbe, und ein eigenes Zeichen wuerde einen Unterschied
|
||
behaupten, den es im Alltag nicht gibt. Was sie
|
||
unterscheidet, steht im Text darunter, und zwar
|
||
vollstaendig: Wer nur "wie die rechte Hand" liest, legt
|
||
sie an und wundert sich spaeter. */
|
||
wert: "linke", name: "Linke Hand", symbol: "husky",
|
||
text: "Dieselben Team- und Aufgabenrechte wie die rechte Hand – "
|
||
+ "verteilt Aufgaben, sieht alle Auswertungen und den ganzen "
|
||
+ "Rudel. Kann aber keine Personen anlegen, keine Rollen "
|
||
+ "ändern und sieht weder Bewerbungen noch den vertraulichen "
|
||
+ "Meldeweg.",
|
||
}]
|
||
: []),
|
||
].sort((a, b) => {
|
||
const platz = (r) => {
|
||
const i = ROLLEN_REIHE.indexOf(r);
|
||
return i < 0 ? ROLLEN_REIHE.length : i;
|
||
};
|
||
return platz(a.wert) - platz(b.wert);
|
||
}),
|
||
});
|
||
} 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" });
|
||
}
|
||
});
|
||
|
||
/* =======================================================================
|
||
EIN MANAGER LEGT EINEN CREATOR AN (07.09.2026)
|
||
|
||
Wunsch Filipe: "ich will auch dass manager ab jetzt creator und auch
|
||
wirklich nur creator hinzufuegen koennen auf die seite. die creator
|
||
sollen ... auch nur der person hinzugefuegt werden wo dan diesen
|
||
creator hinzufuegt oder den scouts von diesem manager."
|
||
|
||
-----------------------------------------------------------------------
|
||
WARUM DAS EIN EIGENER WEG IST UND NICHT DIE ALTE TUER
|
||
|
||
Alles unter `/workspace/api/verwaltung` haengt an EINER Schranke:
|
||
`nurAdmin`. Dahinter liegen acht Wege -- Rollen aendern, Codes neu
|
||
setzen, sperren, loeschen, das Protokoll lesen. Einen Manager dort
|
||
hineinzulassen und danach in jedem der acht Wege einzeln zu pruefen,
|
||
was er darf, ist genau die Bauweise, durch die am 31.08.2026 schon
|
||
einmal ein Loch entstanden ist: Zwei von drei Stellen waren
|
||
abgesichert, die dritte vergessen.
|
||
|
||
Deshalb bleibt die Tuer zu, und daneben steht eine neue mit genau
|
||
EINEM Zweck. Sie kann nichts anderes, als einen Creator anzulegen --
|
||
nicht weil eine Abfrage es verbietet, sondern weil es hier gar keinen
|
||
anderen Weg gibt. Das ist der Unterschied zwischen "darf nicht" und
|
||
"kann nicht".
|
||
|
||
DIE ROLLE STEHT NICHT IM AUFRUF. Sie wird hier gesetzt. Ein Feld
|
||
`rolle` im Koerper waere die naheliegende Loesung und die falsche:
|
||
Dann muesste eine Abfrage sie pruefen, und eine vergessene Abfrage
|
||
ist ein zweiter Zugang mit vollen Rechten.
|
||
|
||
DIE ZUTEILUNG PASSIERT SOFORT UND HIER. Ein Creator ohne Betreuung
|
||
ist fuer alle ausser DogFather unsichtbar -- der Manager haette ihn
|
||
angelegt und danach nicht mehr gesehen. Wer anlegt, betreut; ein Scout
|
||
des Managers kann gleich mitgegeben werden ("oder den scouts von
|
||
diesem manager").
|
||
======================================================================= */
|
||
function nurLeitung(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();
|
||
}
|
||
|
||
personenRouter.post("/workspace/api/creator-anlegen", gleicheHerkunft, nurLeitung, (req, res) => {
|
||
try {
|
||
const name = String(req.body?.name ?? "").trim();
|
||
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." });
|
||
|
||
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." });
|
||
|
||
/* Wem der neue Creator gehoert. Vorgabe: dem, der ihn anlegt.
|
||
Ein Manager darf stattdessen einen SEINER Scouts angeben -- und
|
||
nur einen seiner eigenen. Wer eine fremde Nummer hineinschreibt,
|
||
bekommt sie nicht, sondern eine Absage: Stillschweigend auf die
|
||
Vorgabe zurueckzufallen waere schlimmer, weil der Manager dann
|
||
glaubt, er haette zugeteilt. */
|
||
let betreuerId = req.person.id;
|
||
const gewuenscht = req.body?.betreuer_id;
|
||
if (gewuenscht !== undefined && gewuenscht !== null && gewuenscht !== "") {
|
||
const z = Number(gewuenscht);
|
||
if (!Number.isInteger(z) || z < 1) return res.status(400).json({ fehler: "Ungültige Zuordnung." });
|
||
if (z !== req.person.id) {
|
||
const erlaubt = istDogFather(req.person)
|
||
? db().prepare("SELECT 1 FROM personen WHERE id = ? AND aktiv = 1 AND rolle IN ('admin','manager','scout')").get(z)
|
||
: db().prepare(`SELECT 1 FROM personen p
|
||
JOIN scout_zuteilung s ON s.scout_id = p.id
|
||
WHERE p.id = ? AND p.aktiv = 1 AND p.rolle = 'scout'
|
||
AND s.manager_id = ?`).get(z, req.person.id);
|
||
if (!erlaubt) {
|
||
return res.status(403).json({
|
||
fehler: "Diesen Scout betreust du nicht – zuteilen kannst du nur deine eigenen.",
|
||
});
|
||
}
|
||
}
|
||
betreuerId = z;
|
||
}
|
||
|
||
const neu = personAnlegen(name, "creator", { ...req.person, ip: echteIp(req) });
|
||
betreuungSetzen(neu.id, betreuerId, { ...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,
|
||
adresse: anmeldeAdresseFuer(neu.rolle),
|
||
betreuer_id: betreuerId });
|
||
} catch (fehler) {
|
||
console.error("[workspace] Creator anlegen:", fehler?.message);
|
||
res.status(503).json({ fehler: "nicht_verfuegbar" });
|
||
}
|
||
});
|
||
|
||
/* ZWEITE TUER: EINEN MANAGER ANLEGEN -- nur Spicy Media und DogFather
|
||
(07.09.2026).
|
||
|
||
Filipe: "die agentur manager und creator und die dan auch einteilen."
|
||
|
||
Warum nicht einfach ein Feld `rolle` an der Tuer daneben? Weil damit
|
||
genau die Eigenschaft verloren ginge, die sie sicher macht: Sie KANN
|
||
nichts anderes, als einen Creator anzulegen. Sobald eine Abfrage
|
||
entscheidet, welche Rolle erlaubt ist, ist eine vergessene Abfrage ein
|
||
zweiter Zugang mit vollen Rechten.
|
||
|
||
Also zwei Tueren, jede mit genau einer Aufgabe. Die Rolle steht auch
|
||
hier nicht im Aufruf.
|
||
|
||
EINEN MANAGER LEGT MAN NICHT NEBENBEI AN: Er sieht danach jeden
|
||
Creator, den er betreut, und legt selbst welche an. Deshalb bleibt
|
||
diese Tuer Spicy Media und DogFather vorbehalten -- ein Manager kann
|
||
keinen zweiten Manager schaffen.
|
||
|
||
NACHTRAG 10.09.2026 — JETZT AUCH SCOUTS, UND TROTZDEM ZWEI TUEREN.
|
||
|
||
Filipe: "die spicy rolle soll auch manager und scouts hinzufuegen
|
||
koennen." Fuer Scouts gab es bis heute ueberhaupt keinen Weg ausser
|
||
ueber DogFather.
|
||
|
||
Der naheliegende Griff waere gewesen, hier ein Feld `rolle`
|
||
anzunehmen. Genau davon raet der Absatz oben ab, und der Rat gilt
|
||
weiter: Eine Tuer, die NICHTS anderes kann, als eine bestimmte Rolle
|
||
anzulegen, ist sicherer als eine, die vorher nachfragt. Eine
|
||
vergessene Abfrage waere ein zweiter Zugang mit allen Rechten; eine
|
||
vergessene Abfrage an einer Tuer, die nur "scout" kennt, ist ein
|
||
Aergernis, aber keine Luecke.
|
||
|
||
Also weiterhin zwei Tueren mit je einer festen Rolle — nur nicht mehr
|
||
zweimal derselbe Text. `teamTuer(rolle)` baut den Griff, die Rolle
|
||
wird beim EINHAENGEN festgelegt und kommt nie aus dem Aufruf.
|
||
|
||
Und die Frage "darf diese Person das ueberhaupt" beantwortet nicht
|
||
mehr diese Datei, sondern `darfAnlegen` in workspace.js — dieselbe
|
||
Auskunft, aus der auch die Oberflaeche ihre Knoepfe baut. Zwei Listen
|
||
fuer dieselbe Aussage waren der Grund, warum Spicy Media den
|
||
Manager-Knopf nie zu sehen bekam. */
|
||
function teamTuer(rolle) {
|
||
return (req, res) => {
|
||
try {
|
||
const person = sitzungLesen(req);
|
||
if (!person) return res.status(401).json({ fehler: "nicht_angemeldet" });
|
||
/* ZWEI SCHLOESSER, ABSICHTLICH. `siehtAlles` sagt, wer diese Tuer
|
||
ueberhaupt sieht; `darfAnlegen` sagt, ob sie fuer genau diese
|
||
Rolle offen ist. Faellt eines der beiden weg, haelt das andere. */
|
||
if (!siehtAlles(person)) return res.status(404).json({ fehler: "nicht_gefunden" });
|
||
if (!darfAnlegen(person).includes(rolle)) {
|
||
return res.status(403).json({ fehler: "Diese Rolle legst du nicht an." });
|
||
}
|
||
|
||
const name = String(req.body?.name ?? "").trim();
|
||
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." });
|
||
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, { ...person, ip: echteIp(req) });
|
||
res.status(201).json({ id: neu.id, name: neu.name, rolle: neu.rolle, code: neu.code,
|
||
adresse: anmeldeAdresseFuer(neu.rolle) });
|
||
} catch (fehler) {
|
||
console.error(`[workspace] ${rolle} anlegen:`, fehler?.message);
|
||
res.status(503).json({ fehler: "nicht_verfuegbar" });
|
||
}
|
||
};
|
||
}
|
||
personenRouter.post("/workspace/api/manager-anlegen", gleicheHerkunft, teamTuer("manager"));
|
||
personenRouter.post("/workspace/api/scout-anlegen", gleicheHerkunft, teamTuer("scout"));
|
||
|
||
/* Welche Scouts kann ich einem neuen Creator gleich mitgeben?
|
||
Dieselbe Regel wie oben, nur lesend -- damit die Oberflaeche genau
|
||
die Liste anbietet, die der Server auch annimmt. Zwei getrennte
|
||
Listen waeren die naechste Stelle, an der beide auseinanderlaufen. */
|
||
personenRouter.get("/workspace/api/creator-anlegen/scouts", nurLeitung, (req, res) => {
|
||
try {
|
||
const zeilen = istDogFather(req.person)
|
||
? db().prepare("SELECT id, name FROM personen WHERE aktiv = 1 AND rolle = 'scout' ORDER BY name").all()
|
||
: db().prepare(`SELECT p.id, p.name FROM personen p
|
||
JOIN scout_zuteilung s ON s.scout_id = p.id
|
||
WHERE p.aktiv = 1 AND p.rolle = 'scout' AND s.manager_id = ?
|
||
ORDER BY p.name`).all(req.person.id);
|
||
res.json({ scouts: zeilen });
|
||
} catch {
|
||
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." });
|
||
/* 'MODI' IST FUER ALLE AUSSER DOGFATHER KEINE BEKANNTE ROLLE
|
||
(09.09.2026).
|
||
|
||
EHRLICHERWEISE: Diese Zeile schliesst heute keine Luecke. Der
|
||
ganze Zweig /workspace/api/verwaltung haengt an nurAdmin, und
|
||
nurAdmin laesst nur die DogFather-Rolle durch -- weiter kommt
|
||
ohnehin niemand. Sie steht hier fuer den Tag, an dem jemand
|
||
nurAdmin lockert, etwa damit Manager Leute verwalten duerfen.
|
||
Dann waere sonst genau hier der stille Weg zu einem Modi-Zugang.
|
||
|
||
WARUM DIESELBE ANTWORT WIE BEI EINER ERFUNDENEN ROLLE: Ein
|
||
"das darfst du nicht" waere schlimmer als das Recht selbst -- es
|
||
verriete, dass es die Rolle gibt. Deshalb wortgleich, mit
|
||
demselben Statuscode. */
|
||
/* Die verborgenen Rollen vergibt nur DogFather. Aus der Menge
|
||
gelesen und nicht als `rolle === "modi"` hingeschrieben: Seit dem
|
||
10.09.2026 sind es zwei, und die zweite waere hier sonst still
|
||
durchgerutscht -- ein Manager haette eine rechte Hand anlegen
|
||
koennen, ohne dass irgendwo etwas rot wird. */
|
||
/* GEFRAGT WIRD `darfAnlegen`, NICHT `ROLLEN` (17.09.2026).
|
||
|
||
HIER STAND `!ROLLEN.includes(rolle)`, und `ROLLEN` ist
|
||
`ROLLEN_REIHE` -- die SORTIERREIHENFOLGE. Dort fehlt "gast" mit
|
||
Absicht (der Kommentar in workspace.js sagt es woertlich: "steht
|
||
mit Absicht NICHT in der Liste, sie faellt ans Ende").
|
||
|
||
Folge: Die Oberflaeche bot "Community" an -- sie holt ihre
|
||
Knoepfe aus `darfAnlegen` --, und der Server antwortete beim
|
||
Anlegen "Unbekannte Rolle." Filipe, am 17.09.: "und wieso kann
|
||
ich immer noch keine community rolle erstellen?"
|
||
|
||
Das ist die Falle, vor der in diesem Haus an zehn Stellen
|
||
gewarnt wird: EINE Liste, zwei Fragen. `ROLLEN_REIHE` beantwortet
|
||
"in welcher Reihenfolge", nicht "welche gibt es".
|
||
|
||
`darfAnlegen` beantwortet genau die Frage, die hier zaehlt --
|
||
und es ist dieselbe Auskunft, aus der die Oberflaeche ihre
|
||
Knoepfe baut. Damit koennen die beiden nicht mehr auseinander-
|
||
laufen. Die Team-Dogi-Regel steckt schon darin (ANLEGBAR gibt
|
||
"hand" und "modi" nur DogFather), ebenso die Regel, dass sich
|
||
kein zweiter DogFather anlegen laesst -- die das alte `ROLLEN`
|
||
uebrigens NICHT abgedeckt hat. */
|
||
if (!darfAnlegen(req.person).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.
|
||
|
||
SEIT DEM 10.09.2026 STEHT DIE ANTWORT NICHT MEHR HIER, sondern in
|
||
`darfAnlegen` (workspace.js) — derselben Auskunft, aus der auch
|
||
die beiden Team-Tueren und die Oberflaeche ihre Knoepfe bauen.
|
||
Vorher stand die Regel an vier Stellen in drei Dateien, und genau
|
||
daran ist sie zerbrochen: Zwei davon widersprachen einander, und
|
||
Spicy Media bekam den Manager-Knopf nie zu sehen.
|
||
|
||
Am Ergebnis aendert sich nichts — die Liste sagt fuer DogFather
|
||
"alles" und fuer einen Manager "nur Creator", also genau das, was
|
||
hier vorher ausgeschrieben stand. Es steht nur noch an einer
|
||
Stelle. */
|
||
if (!darfAnlegen(req.person).includes(rolle)) {
|
||
return res.status(403).json({
|
||
fehler: "Diese Rolle legst du nicht 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,
|
||
adresse: anmeldeAdresseFuer(neu.rolle) });
|
||
} 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, adresse: anmeldeAdresseFuer(neu.rolle) });
|
||
} 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" });
|
||
}
|
||
});
|
||
|
||
/* =====================================================================
|
||
DIE ROLLE EINES MENSCHEN AENDERN (10.09.2026)
|
||
|
||
Filipe wollte VanVan die Rolle "Rechte Hand" geben -- und konnte
|
||
nicht. Beim Nachsehen: Es gibt im ganzen Server KEINE einzige Stelle,
|
||
die `personen.rolle` aendert. Anlegen ja, sperren ja, loeschen ja;
|
||
die Rolle war ab dem ersten Tag in Stein.
|
||
|
||
Das ist kein Schoenheitsfehler. Ohne diese Funktion bleibt nur, den
|
||
Menschen zu loeschen und neu anzulegen -- und daran haengen seine
|
||
Aufgaben, seine Nachrichten, seine Eintraege, sein ganzer Verlauf.
|
||
Kapitel 4 des Pflichtenhefts verlangt ausdruecklich das Gegenteil:
|
||
"Rolle/Kategorie zuweisen".
|
||
|
||
---------------------------------------------------------------------
|
||
FUENF SICHERUNGEN, UND JEDE HAT IHREN GRUND
|
||
|
||
1. NUR DOGFATHER. Wie beim Anlegen. Wer Rollen vergeben kann, kann
|
||
sich selbst zum DogFather machen -- deshalb haengt die ganze
|
||
Verwaltung an `nurAdmin`, und diese Route erst recht.
|
||
|
||
2. NIE DIE EIGENE. Wer sich selbst herabstuft, sperrt sich aus dem
|
||
Haus aus, und niemand kann es rueckgaengig machen -- die Funktion
|
||
dafuer haengt ja an der Rolle, die er gerade abgegeben hat. Das
|
||
ist keine Warnung wert, das ist eine Tuer, die zubleibt.
|
||
|
||
3. NIE DEN LETZTEN DOGFATHER. Dieselbe Ueberlegung eine Ebene weiter,
|
||
und dieselbe wie beim Sperren darunter: Ohne einen aktiven
|
||
DogFather gibt es niemanden mehr, der Zugaenge vergibt.
|
||
|
||
4. ALLE SITZUNGEN DIESER PERSON ENDEN. Eine Sitzung gehoert seit dem
|
||
10.09.2026 zu einer ADRESSE, und welche das ist, entscheidet die
|
||
Rolle (sitzungPasstZurAdresse). Wer eben noch DogFather war und
|
||
jetzt rechte Hand ist, sitzt sonst mit einer Sitzung da, die auf
|
||
der Agenturadresse laeuft und dort nicht mehr hingehoert. Das
|
||
faellt beim naechsten Klick auf, nicht sofort -- und ein halb
|
||
gueltiger Zustand ist das Unangenehmste, was eine Rechteaenderung
|
||
hinterlassen kann.
|
||
|
||
5. DER CODE BLEIBT. Er haengt am Menschen, nicht an der Rolle. Ihn
|
||
hier mitzutauschen waere bequem und falsch: Dann muesste jede
|
||
Rollenaenderung von einem Gespraech begleitet sein ("dein Zugang
|
||
ist ein anderer"), und wer das vergisst, sperrt jemanden aus,
|
||
ohne es zu merken. Wer einen neuen Code will, hat den Knopf
|
||
daneben.
|
||
===================================================================== */
|
||
/* `nurDogFatherBeiLeitung` FEHLTE HIER (ergaenzt 24.09.2026, gefunden
|
||
von pruef-hand-personen).
|
||
|
||
Bis heute war das ohne Folgen: Die Route hat eigene Pruefungen, und
|
||
wer sie ueberhaupt erreichte, war DogFather oder jemand mit
|
||
`darfRollenWechseln`. Gemessen hat die neue Pruefung aber, dass die
|
||
rechte Hand darueber die Rolle eines MANAGERS aendern konnte --
|
||
waehrend derselbe Manager fuer DogFather auf dieser Adresse gar
|
||
nicht existiert. Zwei Wege, zwei Antworten, und der laxere war der
|
||
fuer die Rolle mit weniger Rechten. */
|
||
personenRouter.put("/workspace/api/verwaltung/personen/:id/rolle", gleicheHerkunft,
|
||
nurDogFatherBeiLeitung, (req, res) => {
|
||
try {
|
||
const id = Number(req.params.id);
|
||
const rolle = String(req.body?.rolle ?? "");
|
||
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" });
|
||
|
||
/* ==== DARF ICH DIESEN MENSCHEN ANFASSEN? (20.09.2026) =========
|
||
|
||
Seit die rechte Hand Rollen aendern darf, genuegt "ist
|
||
angemeldet und kam durch die Schranke" nicht mehr. Die Regel
|
||
steht in darfRolleAendern() -- an EINER Stelle, damit die
|
||
Oberflaeche und der Server nicht auseinanderlaufen.
|
||
|
||
Sie beantwortet drei Fragen auf einmal: nicht die eigene Rolle,
|
||
nicht DogFather, und fuer die rechte Hand auch keine zweite
|
||
rechte Hand. */
|
||
/* DIE EIGENE ZEILE ZUERST -- und mit 400, nicht 403.
|
||
|
||
Sie ist keine Rechtefrage, sondern eine unsinnige Bitte: Es
|
||
gibt niemanden, der sie duerfte. Eine 403 haette hier
|
||
ausserdem den Fall "der letzte DogFather tritt zurueck"
|
||
verschluckt, den die Sicherung weiter unten mit einem
|
||
verstaendlichen Satz beantwortet. */
|
||
if (person.id === req.person.id) {
|
||
return res.status(400).json({
|
||
fehler: "Deine eigene Rolle kannst du nicht ändern. Das muss jemand anderes tun.",
|
||
});
|
||
}
|
||
if (!darfRolleAendern(req.person, person)) {
|
||
return res.status(403).json({ fehler: "Diese Rolle darfst du nicht ändern." });
|
||
}
|
||
|
||
/* Dieselbe Auskunft wie beim Anlegen: Wer eine Rolle nicht
|
||
vergeben darf, darf sie auch nicht zuweisen. Sonst waere das
|
||
Zuweisen der bequemere Weg an der Regel vorbei. */
|
||
/* EINE FRAGE, EINE ANTWORT (17.09.2026).
|
||
|
||
Hier standen ZWEI Pruefungen untereinander. Die erste las
|
||
`ROLLEN` -- die Sortierreihenfolge, in der "gast" mit Absicht
|
||
fehlt -- und lehnte deshalb ab, BEVOR die zweite, richtige
|
||
ueberhaupt drankam. Eine bestehende Person liess sich damit
|
||
nicht zu "Community" machen, aus demselben Grund wie beim
|
||
Anlegen.
|
||
|
||
Gefunden hat das nicht das Lesen, sondern pruef-rollen-anlegen:
|
||
Die Suche nach der alten Zeile reichte noch in diese Route
|
||
hinein, und dort stand sie ein zweites Mal.
|
||
|
||
DIE ZWEITE ANTWORT WAR AUSSERDEM GESPRAECHIGER als die erste
|
||
("Diese Rolle vergibst du nicht." mit 403 gegen "Unbekannte
|
||
Rolle." mit 400). Wer durchprobiert, haette daran ablesen
|
||
koennen, welche Rollen es gibt. Jetzt beide Faelle wortgleich
|
||
-- wie beim Anlegen. */
|
||
/* WELCHE ROLLE DARF DIESE PERSON VERGEBEN.
|
||
|
||
Hier stand `darfAnlegen`. Das war richtig, solange Vergeben und
|
||
Anlegen dasselbe waren -- seit dem 20.09. sind sie es nicht
|
||
mehr: Die rechte Hand darf NIEMANDEN anlegen und trotzdem
|
||
'modi' und 'gast' vergeben, ein Manager darf einen Creator
|
||
anlegen und gar keine Rolle vergeben. Gemessen:
|
||
|
||
admin anlegen = aendern (sieben Rollen)
|
||
spicy anlegen = aendern (vier)
|
||
hand anlegen = — aendern = modi, gast
|
||
manager anlegen = creator aendern = —
|
||
|
||
WORTGLEICH MIT DEM FALL DARUEBER, und das ist Absicht: Zwei
|
||
verschiedene Antworten -- "Unbekannte Rolle" gegen "die darfst
|
||
du nicht vergeben" -- verraten beim Durchprobieren, WELCHE
|
||
Rollen es gibt. Genau davor warnt der Kommentar von 17.09., und
|
||
eine 403 an dieser Stelle hatte die Luecke am 20.09. kurz
|
||
wieder aufgemacht. */
|
||
if (!rollenZumAendern(req.person).includes(rolle)) {
|
||
return res.status(400).json({ fehler: "Unbekannte Rolle." });
|
||
}
|
||
if (person.rolle === rolle) {
|
||
return res.status(400).json({ fehler: "Diese Rolle hat sie schon." });
|
||
}
|
||
|
||
/* SICHERUNG 6 -- NEU AM 11.09.2026, WEIL SICH DIE TUER GEOEFFNET HAT.
|
||
|
||
Seit Spicy Media Rollen wechseln darf, gibt es einen Fall, den
|
||
es vorher nicht geben konnte: jemand ohne DogFather-Rolle, der
|
||
an einer DogFather-Zeile steht.
|
||
|
||
DIE PRUEFUNGEN DARUEBER FANGEN DAS NICHT. Sie sehen auf die
|
||
ZIEL-Rolle ("darfst du 'manager' vergeben?") -- und 'manager'
|
||
darf Spicy Media vergeben. Dass die Person, die da herabgestuft
|
||
wird, DogFather ist, steht in der AUSGANGS-Rolle, und die kam
|
||
bis heute nirgends vor.
|
||
|
||
Sicherung 3 (nie den letzten DogFather) haette es heute
|
||
zufaellig abgefangen, weil es genau einen gibt. Eine Sperre,
|
||
die nur wegen einer Zahl im Bestand haelt, ist keine.
|
||
|
||
Zusaetzlich sieht Spicy Media DogFather gar nicht in der Liste
|
||
(`req.ohneDogFather`). Das ist eine Sicht, keine Schranke -- wer
|
||
die Nummer kennt, ruft den Weg direkt auf. */
|
||
if (person.rolle === "admin" && !istDogFather(req.person)) {
|
||
return res.status(403).json({ fehler: "An der DogFather-Rolle ändert nur DogFather." });
|
||
}
|
||
|
||
/* SICHERUNG 2 */
|
||
if (id === req.person.id) {
|
||
return res.status(400).json({ fehler: "Die eigene Rolle lässt sich nicht ändern.",
|
||
hinweis: "Sonst könntest du dich selbst aussperren, ohne es rückgängig machen zu können." });
|
||
}
|
||
|
||
/* SICHERUNG 3 -- gezaehlt werden die AKTIVEN. Ein gesperrter
|
||
DogFather kann niemanden hereinlassen; ihn mitzuzaehlen waere
|
||
eine Sicherung, die sich selbst belügt. */
|
||
if (person.rolle === "admin" && rolle !== "admin") {
|
||
const uebrig = db().prepare(
|
||
"SELECT COUNT(*) AS n FROM personen WHERE rolle = 'admin' AND aktiv = 1 AND id <> ?")
|
||
.get(id).n;
|
||
if (uebrig < 1) {
|
||
return res.status(400).json({ fehler: "Das ist der letzte DogFather-Zugang." });
|
||
}
|
||
}
|
||
|
||
const vorher = person.rolle;
|
||
db().prepare("UPDATE personen SET rolle = ? WHERE id = ?").run(rolle, id);
|
||
|
||
/* SICHERUNG 4 */
|
||
const raus = db().prepare("DELETE FROM sitzungen WHERE person_id = ?").run(id);
|
||
|
||
protokolliere("rolle_geaendert", {
|
||
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
|
||
detail: `#${id} ${person.name}: ${vorher} -> ${rolle}`.slice(0, 120),
|
||
});
|
||
res.json({ id, name: person.name, vorher, rolle,
|
||
abgemeldet: Number(raus.changes || 0) });
|
||
} catch (fehler) {
|
||
console.error("[workspace] Rolle aendern:", 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) {
|
||
/* DIE RECHTE HAND DARF SEIT DEM 24.09.2026 AUCH LOESCHEN.
|
||
Filipe: „die selben rechte da haben wie dogfather. das einzige
|
||
was sie nicht kann ist die dogfather rolle oder leute anfassen."
|
||
WEN sie nicht anfassen darf, entscheidet `nurDogFatherBeiLeitung`
|
||
vor dieser Funktion -- DogFather, Manager und alles ausserhalb
|
||
von ANLEGBAR. Hier bleiben die Sicherungen, die fuer JEDEN
|
||
gelten. */
|
||
if (!istDogFather(akteur) && akteur?.rolle !== "hand") {
|
||
return "Löschen darf nur DogFather und die rechte Hand.";
|
||
}
|
||
if (person.id === akteur.id) return "Dich selbst kannst du nicht löschen.";
|
||
if (istDogFather(person)) {
|
||
/* DOPPELT, UND DAS IST ABSICHT: `nurDogFatherBeiLeitung` haelt die
|
||
rechte Hand schon vorher auf. Diese Zeile gilt DogFather selbst
|
||
-- der letzte Zugang bleibt, auch wenn er es selbst versucht. */
|
||
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",
|
||
nurDogFatherBeiLeitung, (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. Seit dem 24.09.2026
|
||
gehoert die rechte Hand dazu; WEN sie sehen darf, regelt
|
||
`nurDogFatherBeiLeitung` auf dieser Route. */
|
||
if (!istDogFather(req.person) && req.person?.rolle !== "hand") {
|
||
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" });
|
||
}
|
||
});
|
||
|
||
/* `nurDogFatherBeiLeitung` STAND HIER NICHT -- und das war bis heute
|
||
harmlos, weil die Route eine Zeile weiter unten ohnehin nur
|
||
DogFather durchliess. Seit die rechte Hand loeschen darf, ist es
|
||
die Stelle, an der DogFather und die Manager geschuetzt werden.
|
||
Ohne diese Middleware koennte sie DogFather loeschen. */
|
||
personenRouter.delete("/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" });
|
||
if (!istDogFather(req.person) && req.person?.rolle !== "hand") {
|
||
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" });
|
||
}
|
||
});
|