DogFatherGitandClaude Opus 5
7eec2edf3f
Aus dem Plan im Vault. Eine Wunschliste ohne sichtbare Erfuellung ist
ein Briefkasten ohne Postbote -- nach dem dritten unbeantworteten
Wunsch schreibt niemand mehr.
ZWEIMAL LAG MEIN PLAN DANEBEN, beide Male zu pessimistisch:
- Die Sortierung nach Stimmen GAB es schon, seit dem 11.09.
- Die Datenbank erlaubte 'angenommen' und 'abgelehnt' laengst in ihrer
CHECK-Regel; nur die Pruefung im Server liess sie nicht durch. Die
Tabelle war der Logik voraus.
Auch ein Plan von gestern Nacht ist eine Bestandsliste und altert.
WAS DAZUGEKOMMEN IST
- Vier Zustaende JE BEREICH statt zwei global: Offen -> Wird gemacht
-> Gemacht, dazu "Diesmal nicht". Eine gemeinsame Liste haette
"Diesmal nicht" auch an einem Schutzvorfall erlaubt, und dort
bedeutet es nichts.
- Ein geplanter Tag dazu: "Wird gemacht" allein ist ein Versprechen,
"Wird gemacht -- am 24.09." ist ein Termin.
- Der Rangbalken. Eine Rangfolge sieht man erst, wenn der ABSTAND
sichtbar ist: 12 Stimmen neben 14 sehen sonst aus wie 1 neben 40.
Fuer ein Vorleseprogramm spricht er in Worten.
- Entschiedenes rutscht nach unten, wird aber NICHT geloescht. Gerade
der erfuellte Wunsch ist der Beweis, dass sich Schreiben lohnt.
"DIESMAL NICHT" IST DER WICHTIGSTE DER VIER, und es ist bewusst nicht
rot. Ein Nein ist eine Antwort, Schweigen ist keine -- aber wer ein
rotes Schild an seinem Wunsch sieht, schreibt keinen zweiten.
UND AUF DEM BILDSCHIRMFOTO STAND "WAS IHR EUCH WUENSCHT".
Die Umlaut-Pruefung von gestern Nacht sah es nicht: Sie kannte die
Kataloge und die festen Seitentexte, aber nicht die
Bereichseinstellungen, aus denen JEDE Ueberschrift und jede
Art-Beschriftung kommt. Sechs Stellen ("Fuer den Stream", "Wie es hier
laeuft", "Haeufige Frage", "Ich haette Lust" ...).
Gefunden hat sie kein Gedankengang, sondern ein Blick auf das fertige
Bild. Die Wortliste hatte ausserdem Loecher -- "wuensch" fehlte
schlicht; 23 Stuecke nachgetragen. pruef-deutsche-texte deckt jetzt
auch die 120 Beschriftungen der Bereiche ab (9 -> 12 Pruefungen), mit
einer Gegenprobe auf genau den Satz, der heute Morgen durchrutschte.
NEU: pruef-wunschliste (30 Pruefungen)
Der aelteste Wunsch bekommt die meisten Stimmen -- genau der Fall, der
eine Sortierung nach Datum entlarvt. Dazu: alle vier Zustaende setzen,
ein erfundener nicht, "abgelehnt" am Anschlagbrett ABGELEHNT, der
geplante Tag, die Balkenbreiten (100/33/0 %), und dass der gemachte
Wunsch weiter in der Liste steht -- nur nicht mehr oben.
pruef-countdown 22, pruef-treff 66, pruef-bereiche-lesend,
pruef-deutsche-texte 12: gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
1668 lines
73 KiB
JavaScript
1668 lines
73 KiB
JavaScript
/* =====================================================================
|
||
workspace-bereiche.js — LIVE, Content, Technik, Community und Schutz.
|
||
|
||
Diese fuenf Bereiche aus Phase 2 haben im Konzept dieselbe Grundform:
|
||
Eintraege zu einem Creator, mit Art, Datum, Titel, Text und Status.
|
||
Sie unterscheiden sich nur darin, WELCHE Arten es gibt und ob eine
|
||
Bewertung oder eine Dringlichkeit dazugehoert.
|
||
|
||
Deshalb ein gemeinsamer Unterbau statt fuenf fast gleicher Module:
|
||
eine Tabelle, eine Sichtbarkeitsregel, eine Pruefung. Ein Fehler laesst
|
||
sich damit an einer Stelle beheben statt an fuenf, und ein neuer
|
||
Bereich ist ein Eintrag in BEREICHE -- kein neues Modul.
|
||
|
||
Die Feldnamen und Arten stammen woertlich aus dem Deck (Seiten 7-12).
|
||
===================================================================== */
|
||
|
||
import express from "express";
|
||
import {
|
||
db, protokolliere, echteIp, sitzungLesen, betreutWo, darfCreator, betreuteIds, istLeitung, istDogFather, siehtAlles, istSpicy, ohneDogFather,
|
||
externPruefen, externSql,
|
||
ohneTeamDogi, ohneAgentur, siehtModis, fuehrtTeamDogi, MODI_BEREICHE_ERLAUBT, TEAM_DOGI_ROLLEN,
|
||
TREFF_BRETTER, TREFF_ROLLEN, AUSSEN_ROLLEN,
|
||
} from "./workspace.js";
|
||
import { nachrichtSchicken } from "./workspace-chat.js";
|
||
import {
|
||
darfSchreiben, freigabeBedingung, entfernenVorbereiten, TREFF_TEAM_ROLLEN,
|
||
mitRollenname,
|
||
} from "./workspace-treff.js";
|
||
|
||
export const bereicheRouter = express.Router();
|
||
|
||
/* Die Bereiche und ihre Arten. Bewusst hier und nicht in der Datenbank:
|
||
Es sind Festlegungen aus dem Konzept, keine Nutzdaten. */
|
||
export const BEREICHE = {
|
||
/* =====================================================================
|
||
DIE SIEBEN BRETTER DES TREFFS (11.09.2026)
|
||
|
||
Der Raum fuer die Zuschauer. Sie laufen ueber dieselbe Maschinerie
|
||
wie Ideen-Board und Angebote -- ein Bereich, seine Arten, dieselbe
|
||
Seite. Eine eigene Bauart daneben waere eine zweite
|
||
Sichtbarkeitsregel, und genau deren Vervielfaeltigung hat am
|
||
10.09. ein Leck verursacht.
|
||
|
||
ALLE SIEBEN HABEN `fuerAlle`: Im Treff sieht jeder jeden Beitrag.
|
||
Ein Raum, in dem man nur sieht, was man selbst geschrieben hat,
|
||
waere kein Raum. Die Grenze nach aussen zieht nicht `fuerAlle`,
|
||
sondern der Riegel in sichtbarEintrag() -- die Agentur sieht kein
|
||
einziges dieser Bretter.
|
||
|
||
ALLE SIEBEN HABEN `ohneCreatorBezug`: Hier geht es um niemanden aus
|
||
der Agentur. Das Feld waere nicht nur ueberfluessig, es waere die
|
||
Einladung, versehentlich einen Creator mit einem Zuschauer zu
|
||
verknuepfen.
|
||
===================================================================== */
|
||
|
||
anschlag: {
|
||
name: "Anschlagbrett",
|
||
ober: "Vom Team",
|
||
arten: {
|
||
ansage: "Ansage",
|
||
regel: "Neue Regel",
|
||
hinweis: "Hinweis",
|
||
danke: "Danke an euch",
|
||
},
|
||
bewertung: false,
|
||
dringlichkeit: false,
|
||
ohneCreatorBezug: true,
|
||
fuerAlle: true,
|
||
},
|
||
|
||
ansteht: {
|
||
name: "Was ansteht",
|
||
ober: "Termine",
|
||
/* AUSDRUECKLICH NICHT AN DEN ECHTEN KALENDER GEKOPPELT.
|
||
|
||
Ein Termin traegt Titel, Ort und Gegenueber -- und die Regel im
|
||
Haus lautet seit dem 07.09., dass ein Kalender als Ganzes privat
|
||
ist. Eine Filterung waere eine Einstellung, die man falsch setzen
|
||
kann; ein Eintrag hier ist eine Entscheidung, die jemand trifft.
|
||
Der Preis ist, dass das Team es zweimal schreibt. Das ist der
|
||
guenstigere von beiden. */
|
||
arten: {
|
||
stream: "Stream",
|
||
event: "Event",
|
||
turnier: "Turnier",
|
||
pause: "Keine Sendung",
|
||
},
|
||
bewertung: false,
|
||
dringlichkeit: false,
|
||
ohneCreatorBezug: true,
|
||
fuerAlle: true,
|
||
},
|
||
|
||
treff: {
|
||
name: "Der Treff",
|
||
ober: "Euer Raum",
|
||
/* DIE REIHENFOLGE IST ABSICHT. Das erste Feld bestimmt, was
|
||
geschrieben wird -- wer ein Formular oeffnet, dessen erste
|
||
Auswahl "Problem" heisst, schreibt Probleme auf.
|
||
|
||
"Hallo, ich bin neu" steht vorn, weil die ersten sieben Tage
|
||
darueber entscheiden, ob jemand bleibt: Wer in dieser Zeit
|
||
erlebt, dass er hier einen Platz hat, kommt deutlich haeufiger
|
||
wieder. Jede Vorstellung bekommt eine Antwort -- das ist der
|
||
ganze Trick, und er steht in keinem Code. */
|
||
arten: {
|
||
hallo: "Hallo, ich bin neu",
|
||
frage: "Frage",
|
||
lob: "Das war gut",
|
||
problem: "Etwas stimmt nicht",
|
||
},
|
||
bewertung: false,
|
||
dringlichkeit: false,
|
||
ohneCreatorBezug: true,
|
||
fuerAlle: true,
|
||
},
|
||
|
||
wunsch: {
|
||
name: "Wunschliste",
|
||
ober: "Was ihr euch wünscht",
|
||
/* DER WEG EINES WUNSCHES (17.09.2026).
|
||
|
||
Bis heute kannte ein Eintrag zwei Zustaende: offen und erledigt.
|
||
Fuer eine Wunschliste ist das zu wenig -- und der Mangel ist
|
||
kein Schoenheitsfehler, sondern der Grund, warum solche Listen
|
||
sterben:
|
||
|
||
Eine Wunschliste ohne sichtbare Erfuellung ist ein Briefkasten
|
||
ohne Postbote. Nach dem dritten unbeantworteten Wunsch
|
||
schreibt niemand mehr.
|
||
|
||
"Diesmal nicht" gehoert ausdruecklich dazu. Ein Nein ist eine
|
||
Antwort; Schweigen ist keine. Wer sieht, dass entschieden wurde,
|
||
schreibt beim naechsten Mal wieder -- auch wenn die Entscheidung
|
||
gegen ihn ausfiel.
|
||
|
||
DIE DATENBANK KONNTE DAS SCHON. Ihre CHECK-Regel erlaubt seit
|
||
laengerem 'angenommen' und 'abgelehnt'; nur die Pruefung im
|
||
Server liess sie nicht durch. Die Tabelle war der Logik voraus. */
|
||
zustaende: {
|
||
offen: "Offen",
|
||
angenommen: "Wird gemacht",
|
||
erledigt: "Gemacht",
|
||
abgelehnt: "Diesmal nicht",
|
||
},
|
||
/* Dazu ein Datum: "Wird gemacht" allein ist ein Versprechen,
|
||
"Wird gemacht -- am 24.09." ist ein Termin. */
|
||
mitGeplant: true,
|
||
arten: {
|
||
stream: "Für den Stream",
|
||
technik: "Technik",
|
||
gemeinsam: "Für die Community",
|
||
sonstiges: "Sonstiges",
|
||
},
|
||
bewertung: false,
|
||
/* KEINE DRINGLICHKEIT VON EINEM EINZELNEN. Was wichtig ist,
|
||
entscheidet hier nicht der Schreiber, sondern wie viele
|
||
mitwollen -- "Will ich auch" kommt als naechster Schritt. Eine
|
||
Dringlichkeit daneben waere eine zweite Rangordnung, und die
|
||
beiden wuerden einander widersprechen. */
|
||
dringlichkeit: false,
|
||
ohneCreatorBezug: true,
|
||
fuerAlle: true,
|
||
},
|
||
|
||
highlight: {
|
||
name: "Highlights",
|
||
ober: "Von euch",
|
||
arten: {
|
||
clip: "Clip",
|
||
bild: "Bild",
|
||
fanart: "Fanart",
|
||
moment: "Moment",
|
||
},
|
||
bewertung: false,
|
||
dringlichkeit: false,
|
||
ohneCreatorBezug: true,
|
||
fuerAlle: true,
|
||
},
|
||
|
||
regeln: {
|
||
name: "Regeln & Hilfe",
|
||
ober: "Wie es hier läuft",
|
||
/* REGELN IN EINFACHER SPRACHE UND AN ECHTEN FAELLEN. Vage Regeln
|
||
erzeugen Grenzfaelle, und die muss dann jeder Modi einzeln
|
||
entscheiden -- das ist der Weg, auf dem ein Team uneinheitlich
|
||
wird und die Community es merkt. */
|
||
arten: {
|
||
regel: "Regel",
|
||
frage: "Häufige Frage",
|
||
hilfe: "Hilfe",
|
||
folge: "Was passiert, wenn",
|
||
},
|
||
bewertung: false,
|
||
dringlichkeit: false,
|
||
ohneCreatorBezug: true,
|
||
fuerAlle: true,
|
||
},
|
||
|
||
mitmachen: {
|
||
name: "Mitmachen",
|
||
ober: "Nachwuchs",
|
||
/* DIE BRUECKE ZU DEN TALENTEN. Wer sich hier meldet, ist ein
|
||
Kandidat -- und Kandidaten gehoeren in die Kategorie, die es
|
||
dafuer schon gibt, nicht in eine zweite Liste daneben.
|
||
|
||
Daneben gehoert der ehrliche Satz, dass eine Bewerbung nicht der
|
||
Hauptweg ist: Der treffsicherste Weg ist, dass jemandem aus dem
|
||
Team auffaellt, wie du dich verhaeltst. Das steht so im Brett,
|
||
weil es stimmt -- und weil es die richtige Erwartung setzt. */
|
||
arten: {
|
||
gesucht: "Wir suchen",
|
||
lust: "Ich hätte Lust",
|
||
frage: "Frage dazu",
|
||
},
|
||
bewertung: false,
|
||
dringlichkeit: false,
|
||
ohneCreatorBezug: true,
|
||
fuerAlle: true,
|
||
},
|
||
|
||
live: {
|
||
name: "LIVE-Analyse",
|
||
arten: { vorbereitung: "Vorbereitung", mitschrift: "Während LIVE", auswertung: "Auswertung" },
|
||
bewertung: true, // Review-Score aus dem Konzept, Seite 7
|
||
dringlichkeit: false,
|
||
},
|
||
/* Content ist der einzige Bereich mit einer STRECKE statt einer Liste:
|
||
Die Arten sind hier Stufen, die ein Video der Reihe nach durchlaeuft.
|
||
Grundlage ist der Satz aus dem Konzept ("Hook bis Upload") und die
|
||
Recherche vom 31.08.2026: Eine Redaktionsplanung ist eine Strecke,
|
||
kein Kalender -- ein Kalender voller Termine verbirgt genau die drei
|
||
Stellen, an denen es klemmt.
|
||
|
||
Fuenf Stufen, nicht drei: Zwischen "Idee" und "Veroeffentlicht" lag
|
||
vorher alles, was den Unterschied macht. Und nicht mehr als fuenf --
|
||
jede weitere Spalte ist eine, die auf dem Handy nicht mehr passt. */
|
||
content: {
|
||
/* Umbenannt am 01.09.2026: "Planung" klang nach Terminen und
|
||
Tabellen. Was hier wirklich passiert, ist das Sammeln und
|
||
Weiterentwickeln von IDEEN -- der Kalender daneben plant. */
|
||
name: "Content-Ideen",
|
||
arten: {
|
||
idee: "Idee",
|
||
skript: "Hook & Skript",
|
||
gedreht: "Gedreht",
|
||
fertig: "Fertig & geplant",
|
||
veroeffentlicht: "Veröffentlicht",
|
||
},
|
||
bewertung: false,
|
||
dringlichkeit: false,
|
||
strecke: true, // hat eine Reihenfolge, nicht nur Kategorien
|
||
},
|
||
technik: {
|
||
name: "Technik",
|
||
arten: { setup: "Setup", problem: "Problem", loesung: "Lösung", anleitung: "Anleitung" },
|
||
bewertung: false,
|
||
dringlichkeit: true,
|
||
},
|
||
community: {
|
||
name: "Community",
|
||
arten: { moderation: "Moderation", aktion: "Aktion", konflikt: "Konflikt" },
|
||
bewertung: false,
|
||
dringlichkeit: true,
|
||
},
|
||
schutz: {
|
||
name: "Schutz & Regeln",
|
||
arten: { richtlinie: "Richtlinie", vorfall: "Vorfall", eskalation: "Eskalation", gelernt: "Gelernt" },
|
||
bewertung: false,
|
||
dringlichkeit: true,
|
||
},
|
||
/* DER SECHSTE BEREICH (06.09.2026).
|
||
|
||
Kernprinzip 04 des Konzepts: "Die Agentur bleibt angebunden." Fuenf
|
||
Bereiche standen, dieser fehlte -- und damit fehlte der einzige
|
||
Ort, an dem steht, welche Kampagne laeuft, welche Schulung ansteht
|
||
und wie ein Anliegen an die Agentur ausgegangen ist. Das lief
|
||
ueber private Nachrichten: nicht auffindbar, nicht nachvollziehbar,
|
||
und beim naechsten Mal fing man wieder von vorn an.
|
||
|
||
VIER ARTEN, und die vierte ist der Punkt:
|
||
kampagne was laeuft, bis wann, unter welcher Bedingung
|
||
schulung Termine und Inhalte, verweist auf die Bibliothek
|
||
anliegen der OFFIZIELLE Weg hin -- mit Stand
|
||
zustaendig wer wofuer zustaendig ist: wir oder die Agentur
|
||
|
||
Die letzte Art ist keine Verlegenheit, sondern das, was das Konzept
|
||
ausdruecklich fordert ("Betreuung & Umsetzung ist unsere Seite,
|
||
offizielle Wege und Plattformthemen sind Agenturseite"). Solange
|
||
das nur im Kopf steht, wird bei jedem Streitfall neu verhandelt,
|
||
wer eigentlich haette handeln muessen.
|
||
|
||
Dringlichkeit: ja. Ein Anliegen an die Agentur, das drei Wochen
|
||
liegt, ist etwas anderes als eines von gestern -- und ohne Stufe
|
||
sieht man den Unterschied in einer Liste nicht.
|
||
Bewertung: nein. Hier wird nichts benotet; es ist ein
|
||
Zusammenarbeits-Bereich, kein Analysebereich. */
|
||
/* FUER ALLE, NICHT FUER EINEN (07.09.2026).
|
||
|
||
Die anderen fuenf Bereiche sind Betreuungsakten: Dort steht etwas
|
||
UEBER einen Creator, und nur er und seine Betreuung sehen es. Die
|
||
Agentur ist das Gegenteil -- ein Event, eine Schulung, eine
|
||
Zustaendigkeit gilt fuer alle gleichzeitig.
|
||
|
||
Bis heute lief sie trotzdem unter der Akten-Regel, und das hatte
|
||
eine Folge, die niemandem auffiel: Ein Event ohne Creator-Zuordnung
|
||
traf weder `creator_id = ich` noch `erstellt_von = ich` -- fuer
|
||
jeden Creator war die Agentur-Seite schlicht LEER. Nicht "kaputt",
|
||
nicht "Fehler": leer, so wie eine Seite aussieht, auf der noch
|
||
nichts steht. Gemessen am 07.09.2026: Von drei Eintraegen sah die
|
||
Creatorin genau den einen, der ihr zugeordnet war.
|
||
|
||
Zwei Schalter, weil es zwei verschiedene Fragen sind:
|
||
fuerAlle -- jeder sieht jeden Eintrag dieses Bereichs
|
||
ohneCreatorBezug -- ein Eintrag gehoert hier NIEMANDEM einzeln */
|
||
/* =====================================================================
|
||
DAS IDEEN-BOARD (10.09.2026, Kapitel 5.6 des Anforderungsdokuments)
|
||
|
||
"Sammelstelle fuer Content-, Live- und Community-Ideen mit
|
||
Priorisierung." Genau das steht hier -- und fast nichts davon
|
||
musste neu gebaut werden: `eintraege` hat Titel, Text, Status und
|
||
`dringlichkeit` (hoch/mittel/niedrig), und das IST die
|
||
Priorisierung. Eine eigene Tabelle daneben waere eine VIERTE
|
||
Sichtbarkeitsregel gewesen; genau deren Vervielfaeltigung hat heute
|
||
schon ein Leck verursacht.
|
||
|
||
`ohneCreatorBezug`: Eine Idee gehoert der Runde, nicht einer
|
||
Person. Stuende ein Name daneben, laese sich der Eintrag wie ein
|
||
Auftrag an diese Person -- und niemand faende ihn spaeter wieder,
|
||
wenn sie nicht mehr da ist.
|
||
|
||
KEIN `fuerAlle`. Das waere der naheliegende Griff gewesen (die
|
||
Agentur-Ablage darueber macht es so) und der falsche: `fuerAlle`
|
||
heisst woertlich JEDER, auch Manager, Scouts und Creator. Wer die
|
||
Sammlung sehen darf, entscheidet stattdessen dieselbe Regel wie
|
||
ueberall -- sichtbar() haengt die Modi-Bedingung an, und der Zugang
|
||
zur Seite haengt an siehtModis(). Zwei Wege, eine Antwort.
|
||
|
||
DIE ARTEN SIND DIE DREI AUS DEM DOKUMENT, dazu "Sonstiges": Eine
|
||
Idee, die in keine der drei passt, soll nicht ungeschrieben
|
||
bleiben, weil das Formular sie nicht kennt. */
|
||
/* =====================================================================
|
||
DIE RUECKMELDUNG (10.09.2026, Kapitel 5 und 6 des Pflichtenhefts)
|
||
|
||
Filipe: "Nicht nur ich soll meine Modis bewerten oder ihnen Feedback
|
||
geben koennen. Auch die Modis sollen mir Feedback geben koennen."
|
||
Und: "Es soll nicht nur dazu dienen, Leistungen zu kontrollieren. Es
|
||
soll vor allem dabei helfen, als Team besser zu werden."
|
||
|
||
EIN BEREICH FUER BEIDE KAPITEL, NICHT ZWEI. Kapitel 5 (gegenseitiges
|
||
Feedback) und Kapitel 6 (gemeinsame Reflexion) stellen dieselben
|
||
Fragen -- "Was laeuft gut? Was laeuft schlecht? Was fehlt?" --, nur
|
||
einmal an eine Person und einmal an das Team. Zwei Bretter dafuer
|
||
haetten bedeutet, dass man beim Schreiben zuerst entscheiden muss,
|
||
an WEN es geht, bevor man weiss, WAS man sagen will. Hier ist es
|
||
umgekehrt: erst die Sache, dann die Richtung (siehe nur_leitung).
|
||
|
||
DIE NEUN FRAGEN SIND SEINE, wortwoertlich aus dem Pflichtenheft
|
||
zusammengezogen. Sie stehen als "Arten" da und nicht als freies
|
||
Textfeld, weil genau das der Unterschied zwischen einer Sammlung
|
||
und einem Haufen ist: Neun Faecher kann man auswerten, tausend
|
||
Formulierungen nicht.
|
||
|
||
KEINE ANONYMITAET, und das ist eine Entscheidung, keine Luecke. In
|
||
einem Team dieser Groesse waere sie ohnehin keine -- an drei
|
||
Saetzen erkennt jeder jeden. Ein Versprechen, das nicht haelt, ist
|
||
schlimmer als keines. Was es stattdessen gibt, ist die Wahl
|
||
zwischen "fuers Team" und "nur an DogFather". */
|
||
/* =====================================================================
|
||
ENTWICKLUNG (11.09.2026)
|
||
|
||
Filipe: "wo wir aufgaben oder bewertungen ueber modis eingeben
|
||
koennen."
|
||
|
||
ES IST KEINE NOTE, UND DAS IST KEINE ZIMPERLICHKEIT, SONDERN DAS
|
||
ERGEBNIS DER RECHERCHE. Die groesste Untersuchung dazu (Schoepke-
|
||
Gonzalez u. a., New Media & Society 2024, ueber 500 befragte
|
||
Freiwillige) nennt zwei Hauptgruende, warum Moderatoren aufhoeren:
|
||
zu wenig Zeit -- und Konflikte im Team beziehungsweise schaedliches
|
||
Verhalten der Leitung. Eine Bewertungsfunktion ist damit genau das
|
||
Werkzeug, mit dem man ein Team verliert, wenn sie als Ueberwachung
|
||
gebaut ist.
|
||
|
||
Was HAELT, ist ebenso gut belegt: Anerkennung. Dank und
|
||
Rueckmeldung erhoehen die Verweildauer messbar; Rollenklarheit
|
||
senkt Burnout.
|
||
|
||
DARAUS FOLGEN DIE FUENF ARTEN, und ihre Reihenfolge ist Absicht:
|
||
Das Erste, was man sieht, ist "Das laeuft gut". Wer ein Formular
|
||
oeffnet, dessen erstes Feld "Problem" heisst, schreibt Probleme
|
||
auf.
|
||
|
||
"ZU VIEL GERADE" IST DIE WICHTIGSTE ART und die, die es sonst
|
||
nirgends gibt. Der haeufigste Grund zu gehen ist Zeitmangel, und
|
||
der zeigt sich frueh -- nur schreibt ihn niemand auf, weil es
|
||
kein Feld dafuer gibt. Jetzt gibt es eins.
|
||
|
||
DIE PERSON SIEHT DEN BEREICH NICHT. Eine halb sichtbare Akte ist
|
||
schlimmer als eine geschlossene: Niemand weiss mehr, was der
|
||
andere gerade liest. Damit Anerkennung trotzdem ankommt, laesst
|
||
sich jeder Eintrag als Nachricht an die Person schicken -- ein
|
||
ausdruecklicher Schritt, und im Eintrag steht danach, wann er
|
||
getan wurde.
|
||
===================================================================== */
|
||
entwicklung: {
|
||
name: "Entwicklung",
|
||
ober: "Über die Zeit",
|
||
arten: {
|
||
staerke: "Das läuft gut",
|
||
dank: "Danke dafür",
|
||
wachsen: "Daran arbeiten wir",
|
||
last: "Zu viel gerade",
|
||
absprache: "So haben wir es vereinbart",
|
||
},
|
||
bewertung: false,
|
||
dringlichkeit: true,
|
||
dringlichkeitName: "Wie dringend",
|
||
/* Der Personenbezug ist hier der SINN des Eintrags und nicht eine
|
||
Nebenangabe -- deshalb ausdruecklich KEIN `ohneCreatorBezug`. */
|
||
einsatzFeld: true,
|
||
einsatzName: "Was daraus folgen soll",
|
||
},
|
||
|
||
/* =====================================================================
|
||
TALENTE (11.09.2026)
|
||
|
||
Filipe: "auch fuer zuschauer die vielleicht modis werden koennten
|
||
waere auch geil."
|
||
|
||
DIE VIER MERKMALE SIND NICHT AUSGEDACHT. Sie sind das, was sich in
|
||
der Literatur zu Moderatorenauswahl immer wieder findet (ModSquad,
|
||
Kitfox Games, Discord-Leitfaeden): ruhig bleiben, wenn es hitzig
|
||
wird; von selbst helfen; die Regeln UND die Leute kennen; und
|
||
regelmaessig da sein. Ausdruecklich NICHT dabei: "schreibt viel"
|
||
-- angenehm im Chat zu sein ist nachweislich etwas anderes, als
|
||
ein guter Moderator zu sein.
|
||
|
||
Und der treffsicherste Weg ueberhaupt ist der fuenfte: die
|
||
EMPFEHLUNG aus dem Team. Wer schon dabei ist, hat den Menschen im
|
||
Alltag erlebt, nicht in einem Bewerbungsformular.
|
||
|
||
DER STATUS IST DIE PROBEZEIT. `offen` heisst beobachtet,
|
||
`angenommen` heisst angesprochen -- und was daraus wird,
|
||
entscheidet sich in "Personen & Zugaenge" mit einem Zugang auf
|
||
Stufe "Probe". Eine eigene Kandidatentabelle waere ein zweiter Ort
|
||
fuer dieselbe Frage.
|
||
===================================================================== */
|
||
talente: {
|
||
name: "Talente",
|
||
ober: "Nachwuchs",
|
||
arten: {
|
||
ruhig: "Bleibt ruhig, wenn es hitzig wird",
|
||
hilft: "Hilft anderen von selbst",
|
||
kennt: "Kennt die Regeln und die Leute",
|
||
da: "Ist regelmäßig da",
|
||
empfohlen: "Aus dem Team empfohlen",
|
||
},
|
||
bewertung: true,
|
||
bewertungName: "Wie sicher bin ich",
|
||
dringlichkeit: true,
|
||
dringlichkeitName: "Wie eilig",
|
||
ohneCreatorBezug: true,
|
||
einsatzFeld: true,
|
||
einsatzName: "Wo ich ihn oder sie gesehen habe",
|
||
},
|
||
|
||
rueckmeldung: {
|
||
name: "Rückmeldung",
|
||
/* Wie beim Ideen-Board: Das hier ist keine Akte ueber jemanden,
|
||
sondern etwas, das allen gehoert. */
|
||
ober: "Gemeinsam besser werden",
|
||
arten: {
|
||
gut: "Läuft gut",
|
||
haken: "Läuft nicht gut",
|
||
behalten: "Unbedingt behalten",
|
||
dogfather: "An DogFather",
|
||
team: "Was dem Team fehlt",
|
||
regeln: "Regel ändern",
|
||
ablauf: "Besser organisieren",
|
||
idee: "Idee",
|
||
zukunft: "Wunsch für später",
|
||
},
|
||
bewertung: false,
|
||
/* Dringlichkeit ja: "Der Ton war gestern kaputt" ist etwas anderes
|
||
als "waere schoen, irgendwann". Eine Sammlung ohne Rangfolge
|
||
wird nach vier Wochen nicht mehr gelesen. */
|
||
dringlichkeit: true,
|
||
ohneCreatorBezug: true,
|
||
/* Schaltet das Feld "nur an DogFather" frei -- siehe pruefe() und
|
||
sichtbarEintrag(). Ohne dieses Merkmal wird es in jedem anderen
|
||
Bereich stillschweigend verworfen, wie Bewertung und
|
||
Dringlichkeit auch. */
|
||
vertraulich: true,
|
||
},
|
||
|
||
ideen: {
|
||
name: "Ideen-Board",
|
||
/* DAS WORT UEBER DEM TITEL. Ueberall sonst steht dort "Betreuung",
|
||
weil die Bereichsseiten Betreuungsakten sind -- ueber jemanden
|
||
gefuehrt, von seinen Betreuern. Eine Ideensammlung ist das
|
||
Gegenteil: Sie gehoert niemandem und wird von allen gefuellt.
|
||
|
||
Es stand fest in bereich.html und wurde nie gesetzt; aufgefallen
|
||
ist es auf dem Bildschirmfoto. Das Feld ist ab jetzt Teil der
|
||
Bereichsangaben, damit der naechste Bereich es einfach mitbringen
|
||
kann statt es zu erben. */
|
||
ober: "Sammelstelle",
|
||
arten: {
|
||
content: "Content-Idee",
|
||
live: "Live-Idee",
|
||
community: "Community-Idee",
|
||
sonstiges: "Sonstiges",
|
||
},
|
||
bewertung: false,
|
||
dringlichkeit: true,
|
||
ohneCreatorBezug: true,
|
||
},
|
||
|
||
/* =====================================================================
|
||
DIE ANGEBOTE (10.09.2026, Wunsch Filipe)
|
||
|
||
*"ich brauch auch noch kategorien wie, angebote, wo die modis
|
||
sachen planen und auch entscheiden was ich machen muss wenn das und
|
||
das erledigt wird."*
|
||
|
||
Ein Modi schlaegt etwas vor -- eine Aktion, ein Format, eine Regel
|
||
-- und schreibt dazu, was DogFather dafuer tun muesste. DogFather
|
||
oder VanVan nimmt an oder lehnt ab; bei Annahme entstehen die
|
||
Aufgaben. Entschieden wird im Eingang, an derselben Stelle
|
||
wie die uebrigen Rueckmeldungen: EIN Eingang, nicht zwei.
|
||
|
||
DIE ZWEI ZAHLEN SIND UMBENANNT, nicht neu erfunden: `bewertung`
|
||
(1-5) heisst hier NUTZEN, `dringlichkeit` heisst AUFWAND. Beide
|
||
Felder gibt es laengst; sie mit neuen Namen zu belegen ist besser,
|
||
als zwei weitere Spalten anzulegen, die dasselbe koennen. Damit
|
||
die Oberflaeche nicht "Dringlichkeit" ueber den Aufwand schreibt,
|
||
stehen die Namen hier.
|
||
|
||
KEIN `fuerAlle`, wie beim Ideen-Board: Wer die Angebote sieht,
|
||
entscheidet dieselbe Regel wie ueberall. */
|
||
angebote: {
|
||
name: "Angebote",
|
||
arten: {
|
||
aktion: "Aktion",
|
||
format: "Format",
|
||
regel: "Regel",
|
||
technik: "Technik",
|
||
sonstiges: "Sonstiges",
|
||
},
|
||
ober: "Vorschläge",
|
||
bewertung: true,
|
||
bewertungName: "Nutzen",
|
||
dringlichkeit: true,
|
||
dringlichkeitName: "Aufwand",
|
||
einsatzFeld: true,
|
||
einsatzName: "Was DogFather dafür tun müsste",
|
||
ohneCreatorBezug: true,
|
||
},
|
||
|
||
agentur: {
|
||
name: "Agentur",
|
||
arten: {
|
||
kampagne: "Agentur-Events",
|
||
schulung: "Schulung",
|
||
anliegen: "Anliegen an die Agentur",
|
||
zustaendig: "Zuständigkeit",
|
||
},
|
||
bewertung: false,
|
||
dringlichkeit: true,
|
||
fuerAlle: true,
|
||
ohneCreatorBezug: true,
|
||
},
|
||
};
|
||
|
||
/* Aus den Bereichseinstellungen abgeleitet, nicht danebengeschrieben.
|
||
Eine zweite Liste waere beim naechsten Bereich auseinandergelaufen --
|
||
und zwar still. */
|
||
const BEREICHE_FUER_ALLE = Object.entries(BEREICHE)
|
||
.filter(([, e]) => e.fuerAlle).map(([k]) => k);
|
||
|
||
const DRINGLICHKEITEN = ["hoch", "mittel", "niedrig"];
|
||
const STATUS = ["offen", "erledigt"];
|
||
const TITEL_MAX = 160;
|
||
const TEXT_MAX = 6000;
|
||
|
||
const jetzt = () => new Date().toISOString();
|
||
|
||
function angemeldet(req, res, next) {
|
||
const person = sitzungLesen(req);
|
||
if (!person) return res.status(401).json({ fehler: "nicht_angemeldet" });
|
||
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();
|
||
}
|
||
|
||
bereicheRouter.use("/workspace/api/bereich", angemeldet);
|
||
|
||
/* =====================================================================
|
||
DAS IDEEN-BOARD GIBT ES NUR FUER DIE, DIE ES SEHEN DUERFEN
|
||
(10.09.2026)
|
||
|
||
404 und nicht 403: "Kein Zugriff" waere die Auskunft, dass es den
|
||
Bereich gibt -- und wer nach "warum darf ich das nicht" fragt, fragt
|
||
als naechstes "wer denn dann". Ein Bereich, den es fuer mich nicht
|
||
gibt, wirft keine Fragen auf. Wortgleich mit der Antwort auf einen
|
||
erfundenen Bereichsnamen (siehe `if (!BEREICHE[bereich])` weiter
|
||
unten).
|
||
|
||
ALS EIGENE HUERDE UND NICHT ALS ABFRAGE IN DEN VIER HANDLERN: Es gibt
|
||
Lesen, Anlegen, Aendern und Loeschen. Vier Abfragen sind vier
|
||
Gelegenheiten, eine zu vergessen -- und die vergessene faellt nicht
|
||
auf, weil an ihrer Stelle nichts steht. Der Pfad-Praefix greift auch
|
||
fuer die Wege mit einer Nummer dahinter.
|
||
|
||
ZWEI SCHLOESSER, ABSICHTLICH: Hier haengt der ZUGANG zur Seite,
|
||
sichtbar() haengt die Bedingung an die ZEILEN. Faellt eines weg,
|
||
haelt das andere. */
|
||
for (const geschuetzt of ["ideen", "angebote", "rueckmeldung"]) {
|
||
bereicheRouter.use(`/workspace/api/bereich/${geschuetzt}`, (req, res, next) => {
|
||
if (siehtModis(req.person)) return next();
|
||
return res.status(404).json({ fehler: "nicht_gefunden" });
|
||
});
|
||
}
|
||
|
||
/* ---------------------------------------------------------------------
|
||
ZWEI BEREICHE GEHEN NUR DOGFATHER UND DIE RECHTE HAND AN (11.09.2026)
|
||
|
||
Filipe: "wo WIR aufgaben oder bewertungen ueber modis eingeben
|
||
koennen." Wir heisst hier: die beiden.
|
||
|
||
`siehtModis` waere zu weit -- darin sind die Modis selbst enthalten,
|
||
und in "Entwicklung" steht, was ueber sie aufgeschrieben wird.
|
||
`fuehrtTeamDogi` ist die engere Menge und dieselbe, die schon den
|
||
Eingang und die Kanaele traegt.
|
||
|
||
404 UND NICHT 403: Ein Modi soll nicht erfahren, dass es diese
|
||
Bereiche gibt. Ein "das darfst du nicht" waere die Auskunft, die
|
||
genau die Frage aufwirft, die niemand stellen soll.
|
||
|
||
ZWEI SCHLOESSER WIE OBEN: Hier haengt der ZUGANG, die Sichtbarkeit
|
||
der Zeilen haengt an sichtbarEintrag(). Faellt eines weg, haelt das
|
||
andere. */
|
||
for (const nurLeitung of ["entwicklung", "talente"]) {
|
||
bereicheRouter.use(`/workspace/api/bereich/${nurLeitung}`, (req, res, next) => {
|
||
if (fuehrtTeamDogi(req.person)) return next();
|
||
return res.status(404).json({ fehler: "nicht_gefunden" });
|
||
});
|
||
}
|
||
|
||
/* ---------------------------------------------------------------------
|
||
UND UMGEKEHRT: Ein Modi kommt nur in SEINE Bereiche.
|
||
|
||
Seit dem 10.09.2026 darf er bereich.html oeffnen -- ohne diese Huerde
|
||
auch `?b=agentur`, die Ablage der Agentur, die ihn nichts angeht. Die
|
||
Kacheln bieten sie ihm nicht an; eine Regel, die nur im Formular
|
||
gilt, ist aber keine.
|
||
|
||
Welche erlaubt sind, steht nicht hier, sondern wird aus seinen
|
||
Kacheln abgeleitet (MODI_BEREICHE_ERLAUBT). Zwei Listen waeren die
|
||
Stelle, an der es auseinanderlaeuft.
|
||
|
||
404 wie ueberall: Ein Bereich, den es fuer mich nicht gibt, wirft
|
||
keine Fragen auf. */
|
||
bereicheRouter.use("/workspace/api/bereich/:bereich", (req, res, next) => {
|
||
/* Auch die Stellvertretung. Sie hat dieselben Kacheln wie ein Modi
|
||
und damit dieselben erlaubten Bereiche -- ohne diese Zeile kaeme
|
||
sie ueber die Adresszeile in die Agentur-Ablage, die sie nichts
|
||
angeht. Genau die Luecke, gegen die diese Schranke gebaut wurde,
|
||
nur eine Rolle spaeter. */
|
||
const b = String(req.params.bereich);
|
||
const nein = () => res.status(404).json({ fehler: "nicht_gefunden" });
|
||
|
||
/* EINE AUSSENROLLE KOMMT NUR IN DEN TREFF (11.09.2026).
|
||
|
||
Und zwar als ERSTER Zweig, nicht als letzter. Die Zeile darunter
|
||
hiess bis heute "wer nicht zum Team gehoert, darf weiter" -- fuer
|
||
einen Gast waere das ein Freifahrtschein durch alle achtzehn
|
||
Bereiche gewesen, obwohl die Kacheln ihm nur sieben anbieten. Eine
|
||
Regel, die nur im Formular gilt, ist keine Regel. */
|
||
if (AUSSEN_ROLLEN.has(req.person?.rolle)) {
|
||
return TREFF_BRETTER.includes(b) ? next() : nein();
|
||
}
|
||
|
||
/* UND UMGEKEHRT: Wer nicht zum Treff gehoert, kommt nicht hinein.
|
||
Das ist derselbe Riegel wie in sichtbarEintrag(), nur eine Ebene
|
||
frueher -- dort entscheidet er, welche ZEILEN jemand sieht, hier,
|
||
ob die Seite ueberhaupt antwortet. Zwei Schloesser, absichtlich:
|
||
Faellt eines weg, haelt das andere. */
|
||
if (TREFF_BRETTER.includes(b) && !TREFF_ROLLEN.has(req.person?.rolle)) return nein();
|
||
|
||
if (!TEAM_DOGI_ROLLEN.has(req.person?.rolle)) return next();
|
||
if (MODI_BEREICHE_ERLAUBT.has(b)) return next();
|
||
return nein();
|
||
});
|
||
|
||
/* ---------- Die Bereiche sind fuer Creator zum LESEN da ----------------
|
||
|
||
Wunsch Filipe, 31.08.2026: "die creator sollen da nur die sehen die wir
|
||
ihnen eintragen, also dogfather manager und scout."
|
||
|
||
Vorher durfte ein Creator hier selbst Eintraege anlegen, aendern und
|
||
die eigenen wieder loeschen. Das klingt harmlos, hebelt aber den Zweck
|
||
dieser Bereiche aus: Sie sind die Betreuungsakte -- LIVE-Auswertungen,
|
||
Technikbefunde, Konfliktverlaeufe, Schutzvorfaelle. Was dort steht,
|
||
muss der Stand der Betreuung sein und nicht das, was jemand ueber sich
|
||
selbst notiert hat. Ein Creator, der eine Auswertung umschreiben oder
|
||
eine unbequeme Notiz loeschen kann, macht die Akte wertlos.
|
||
|
||
Der Creator SIEHT weiterhin alles, was zu ihm gehoert -- vollstaendig,
|
||
nichts wird ihm vorenthalten. Er kann es nur nicht veraendern.
|
||
|
||
Bewusst 403 mit klarem Text und nicht 404: Der Bereich existiert fuer
|
||
ihn ja, er steht sogar davor. Ein 404 wuerde hier luegen. (Bei etwas,
|
||
das er gar nicht sehen darf, bleibt es weiterhin 404.)
|
||
|
||
Steht als EINE Schranke vor allen schreibenden Wegen. Die Alternative
|
||
-- in jeder der drei Stellen einzeln pruefen -- 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. */
|
||
/* Ein Creator schreibt hier nicht -- MIT EINER AUSNAHME, die am
|
||
01.09.2026 dazukam: Was er SELBST angelegt hat, darf er auch
|
||
aendern und loeschen.
|
||
|
||
Die urspruengliche Regel ("hier tragen deine Betreuer ein") bleibt
|
||
damit unangetastet: Er kann weiterhin nichts an dem aendern, was
|
||
ueber ihn geschrieben wurde -- keine Bewertung, keine Notiz, keinen
|
||
Eintrag seines Managers.
|
||
|
||
Noetig wurde die Ausnahme durch die fertigen Vorlagen: Wenn ein
|
||
Creator sich eine Content-Idee uebernimmt, ist das SEINE Idee. Sie
|
||
danach nicht umbenennen zu duerfen waere absurd -- er haette einen
|
||
Eintrag erzeugt, den nur ein anderer bearbeiten kann.
|
||
|
||
Entscheidend ist erstellt_von, nicht creator_id: Ein Eintrag, den
|
||
sein Betreuer ueber ihn angelegt hat, traegt zwar seine creator_id,
|
||
gehoert ihm aber nicht. */
|
||
function nichtSchreibendFuerCreator(req, res, next) {
|
||
if (req.person?.rolle !== "creator") return next();
|
||
|
||
/* Neu anlegen bleibt gesperrt -- der Weg dafuer ist "Vorlage
|
||
uebernehmen", und der prueft eigene Regeln. */
|
||
/* NUR im Bereich content. Das ist der Bereich, in dem der Creator
|
||
selbst arbeitet -- seine Ideen, sein Material. LIVE, Technik,
|
||
Community und Schutz sind die BETREUUNGSAKTE: Dort schreiben die
|
||
Betreuer ueber ihn, und daran aendert er nichts, auch nicht an
|
||
etwas, das frueher einmal von ihm stammte. Das war am 31.08.2026
|
||
ausdruecklich so entschieden und bleibt so.
|
||
|
||
Ein erster Anlauf hatte die Ausnahme fuer ALLE Bereiche erlaubt --
|
||
die Pruefung pruef-bereiche-lesend hat das sofort gemeldet. */
|
||
const bereich = String(req.path).split("/")[4] || "";
|
||
if (bereich !== "content") {
|
||
return res.status(403).json({
|
||
fehler: "Hier tragen deine Betreuer ein. Du siehst alles, was zu dir gehört.",
|
||
});
|
||
}
|
||
|
||
const id = Number(String(req.path).split("/").pop());
|
||
if (Number.isInteger(id) && id > 0) {
|
||
try {
|
||
const e = db().prepare("SELECT erstellt_von FROM eintraege WHERE id = ?").get(id);
|
||
if (e && e.erstellt_von === req.person.id) return next();
|
||
} catch { /* faellt unten auf die Sperre zurueck */ }
|
||
}
|
||
|
||
return res.status(403).json({
|
||
fehler: "Das hat deine Betreuung eingetragen – ändern können sie es. "
|
||
+ "Was du selbst angelegt hast, kannst du bearbeiten.",
|
||
});
|
||
}
|
||
|
||
/* Express 4 -- dort ist der Platzhalter `*`, nicht `*name` wie in
|
||
Fassung 5. Mit der Fassung-5-Schreibweise haette der Pfad wortwoertlich
|
||
gepasst werden muessen und die Schranke waere NIE gegriffen: kein
|
||
Fehler, keine Warnung, nur eine Sperre, die stumm nichts tut. */
|
||
for (const weg of ["post", "patch", "delete", "put"]) {
|
||
bereicheRouter[weg]("/workspace/api/bereich/*", nichtSchreibendFuerCreator);
|
||
}
|
||
|
||
/* =====================================================================
|
||
DIE UMHUELLUNG: was einem Modi gehoert, faellt hier heraus.
|
||
|
||
Sie sitzt UM die eigentliche Regel und nicht darin -- damit sie auch
|
||
fuer Regeln gilt, die es heute noch nicht gibt. Beim ersten Anlauf
|
||
war nur der eine bekannte Fall geflickt (Spicy Media); das haette den
|
||
naechsten Rollenzweig wieder offen gelassen, und niemand haette es
|
||
gemerkt, weil an der geaenderten Stelle nichts davon steht.
|
||
|
||
DogFather und die Modis gehen unveraendert durch. Fuer alle anderen
|
||
kommt die Bedingung dazu -- auch fuer die, deren Regel ohnehin nichts
|
||
Fremdes trifft. Das kostet eine Unterabfrage und spart die Frage,
|
||
ob es diesmal wirklich niemand treffen kann.
|
||
===================================================================== */
|
||
export function sichtbar(person) {
|
||
const regel = sichtbarRoh(person);
|
||
if (!regel) return regel;
|
||
/* AUF DER ADRESSE VON TEAM DOGI NUR TEAM DOGI (10.09.2026).
|
||
|
||
Filipe: "die daten von dieser seite sollen nichts mit den daten am
|
||
hut haben von der workspace seite ... komplett von der anderen
|
||
getrennt sein."
|
||
|
||
Die Bedingung steht VOR der Regel fuer das andere Haus und nicht
|
||
danach: Beide schliessen sich aus, und wer sie hintereinander
|
||
haengt, bekommt auf der Team-Adresse eine Bedingung, die sich
|
||
selbst widerspricht -- und damit eine leere Seite, die aussieht
|
||
wie ein Fehler.
|
||
|
||
`person.haus` setzt sitzungLesen() aus der Adresse. Es aendert
|
||
keine Rechte, nur den Ausschnitt. */
|
||
if (person.haus === "crew") {
|
||
return {
|
||
wo: `(${regel.wo}) AND ${ohneAgentur("e", ["creator_id", "erstellt_von"])}`,
|
||
werte: regel.werte,
|
||
};
|
||
}
|
||
if (siehtModis(person)) return regel;
|
||
return {
|
||
wo: `(${regel.wo}) AND ${ohneTeamDogi("e", ["creator_id", "erstellt_von"])}`,
|
||
werte: regel.werte,
|
||
};
|
||
}
|
||
|
||
/* Scouts haben mit der Creator-Betreuung nichts zu tun -- sie sehen hier
|
||
nichts. Creator sehen ihren eigenen Bereich, das Management alles. */
|
||
function sichtbarRoh(person) {
|
||
/* NUR DogFather sieht alles (01.09.2026). Vorher stand hier
|
||
istLeitung() -- damit sah auch jeder Manager jeden Creator. Ein
|
||
Manager faellt jetzt in dieselbe Regel wie ein Scout: nur die
|
||
Creator, die ihm zugeteilt sind. Ausdruecklicher Wunsch:
|
||
"NUR DIE ROLLE DOGFATHER SOLL WIRKLICH ALLEINE ALLES SEHEN."
|
||
|
||
Geaendert wird ausschliesslich, wer was SIEHT. Was ein Manager
|
||
darf (freigeben, aendern, Personen verwalten), haengt weiterhin an
|
||
istLeitung und bleibt unveraendert -- sonst haette dieser eine
|
||
Wunsch stillschweigend seine halben Rechte mitgenommen. */
|
||
if (istSpicy(person)) return { wo: ohneDogFather("e"), werte: [] };
|
||
if (siehtAlles(person)) return { wo: "1=1", werte: [] };
|
||
|
||
/* "ODER ich habe ihn selbst angelegt" kam am 02.09.2026 dazu -- aus
|
||
demselben Grund wie bei den Aufgaben: Ein Eintrag ohne creator_id
|
||
(Feld auf "—" gelassen oder seit heute ein freier Name) traf keine
|
||
der Bedingungen und war fuer den, der ihn gerade geschrieben hatte,
|
||
sofort unsichtbar. Nur DogFather sah ihn noch.
|
||
|
||
Es sieht weiterhin niemand etwas Fremdes -- nur das Eigene. */
|
||
if (person.rolle === "creator") {
|
||
return { wo: "(e.creator_id = ? OR e.erstellt_von = ?)", werte: [person.id, person.id] };
|
||
}
|
||
/* Ein Scout sieht die Bereiche der Creator, die er betreut -- dazu,
|
||
was er selbst eingetragen hat. */
|
||
/* DAS MODI-TEAM TEILT SICH SEINE EINTRAEGE -- wie die Aufgaben
|
||
(Entscheidung Filipe, 09.09.2026: "sie sind untereinander ein
|
||
Team"). Ohne diesen Zweig saehe jeder Modi nur, was er selbst
|
||
geschrieben hat, und eine gemeinsame Ideensammlung waere keine. */
|
||
/* NACHTRAG 10.09.2026: Die Stellvertretung gehoert in denselben
|
||
Zweig. Ohne sie faellt sie unten durch und landet bei der
|
||
Betreuungsregel -- die fuer sie nichts findet. Ergebnis waere ein
|
||
LEERES Ideen-Board und ein leeres Angebote-Brett, und das meldet
|
||
niemand: Ein leeres Brett sieht nicht nach Fehler aus. Genau so ist
|
||
es am 01.09. dem Manager und am 09.09. dem Modi ergangen. */
|
||
if (TEAM_DOGI_ROLLEN.has(person.rolle)) {
|
||
const liste = [...TEAM_DOGI_ROLLEN].map((r) => `'${r}'`).join(", ");
|
||
return { wo: `(e.erstellt_von IN (SELECT id FROM personen WHERE rolle IN (${liste}))`
|
||
+ ` OR e.creator_id IN (SELECT id FROM personen WHERE rolle IN (${liste})))`, werte: [] };
|
||
}
|
||
const b = betreutWo(person, "e.creator_id");
|
||
return b
|
||
? { wo: `(e.erstellt_von = ? OR ${b.wo})`, werte: [person.id, ...b.werte] }
|
||
: { wo: "e.erstellt_von = ?", werte: [person.id] };
|
||
}
|
||
|
||
/* Dieselbe Regel, aber mit der Ausnahme fuer Bereiche, die allen
|
||
gehoeren.
|
||
|
||
BEWUSST EINE EIGENE FUNKTION, NICHT EINE AENDERUNG AN sichtbar():
|
||
sichtbar() beantwortet auch Fragen zu Aufgaben, Dateien, Terminen und
|
||
Calls (siehe die Aufrufe in workspace-aufgaben.js,
|
||
workspace-dateien.js, workspace-kalender.js, workspace-calls.js). Wer
|
||
dort "1=1" einschleust, weil er an Agentur-Eintraege dachte, oeffnet
|
||
nebenbei fremde Dateien und fremde Termine -- ein Loch, das man dem
|
||
Code nicht ansieht, weil an der geaenderten Stelle nichts davon
|
||
steht.
|
||
|
||
Nur Eintraege gehen hier durch, und nur die aus einem Bereich mit
|
||
`fuerAlle`. Der Rest faellt woertlich auf die alte Regel zurueck.
|
||
|
||
`praefix` ist da, weil die Suche dieselbe Tabelle unter demselben
|
||
Kuerzel "e" fuehrt -- geht das eines Tages auseinander, faellt es
|
||
beim Aufruf auf, nicht erst im Betrieb. */
|
||
/* VERTRAULICHE RUECKMELDUNGEN SIEHT NUR DOGFATHER -- UND DER SCHREIBER
|
||
(10.09.2026).
|
||
|
||
Wer beim Schreiben "nur an DogFather" waehlt, muss sich darauf
|
||
verlassen koennen. Deshalb steht die Bedingung HIER, in derselben
|
||
Funktion, durch die auch das Lesen einer einzelnen Zeile, das Aendern
|
||
und das Loeschen gehen -- nicht in der Listenabfrage. Eine Regel, die
|
||
nur die Liste filtert, laesst die Zeile ueber ihre Nummer trotzdem
|
||
heraus.
|
||
|
||
"NUR DOGFATHER" HEISST AUCH NICHT DIE RECHTE HAND. Sie sieht sonst
|
||
ueberall dasselbe wie er. Hier nicht, und zwar deshalb, weil das
|
||
Etikett sonst nicht stimmte: Eine Zusage mit einer Ausnahme im
|
||
Kleingedruckten ist keine. Sie kann selbst genauso schreiben -- auch
|
||
ueber ihn, und dann sieht er es nicht anders als jeder andere.
|
||
|
||
`COALESCE(..., 0)`: Alle Zeilen, die es vor heute gab, haben in
|
||
dieser Spalte NULL. Ohne den Ersatzwert waere `nur_leitung = 0`
|
||
fuer sie UNBEKANNT statt wahr -- und der gesamte alte Bestand waere
|
||
von einer Minute auf die andere unsichtbar gewesen. Ein Loch, das
|
||
niemand meldet: Ein leeres Brett sieht nicht nach Fehler aus. */
|
||
function ohneVertrauliche(regel, person, praefix) {
|
||
if (!regel || istDogFather(person)) return regel;
|
||
return {
|
||
wo: `(${regel.wo}) AND (COALESCE(${praefix}.nur_leitung, 0) = 0`
|
||
+ ` OR ${praefix}.erstellt_von = ?)`,
|
||
werte: [...regel.werte, person.id],
|
||
};
|
||
}
|
||
|
||
/* =====================================================================
|
||
DER TREFF HAT ZWEI RIEGEL, UND SIE ZEIGEN IN ENTGEGENGESETZTE
|
||
RICHTUNGEN (11.09.2026)
|
||
|
||
Filipe: "wo die community auch dan nur die sieht und die modis
|
||
rechte hand und ich also dogfather sehen die aber auch. die
|
||
community aber nur die dann."
|
||
|
||
Daraus folgen zwei Saetze, und beide muessen gelten:
|
||
|
||
1. EINE AUSSENROLLE SIEHT NUR DEN TREFF. Nicht "den Treff und was
|
||
sonst noch durchfaellt" -- nur ihn. Deshalb steht dieser Zweig
|
||
GANZ VORN und baut seine Regel selbst, statt auf der
|
||
allgemeinen aufzusetzen. Wer auf einer bestehenden Regel
|
||
aufsetzt, erbt jeden Zweig, den sie hat, auch die, die es
|
||
morgen erst gibt.
|
||
|
||
2. DIE AGENTUR SIEHT DEN TREFF NICHT. Creator, Scouts, Manager und
|
||
Spicy Media haben mit den Zuschauern dieses Streams nichts zu
|
||
tun. Ohne diesen zweiten Riegel haette `fuerAlle` sie
|
||
hereingelassen -- genau das Loch, das am 10.09. schon einmal
|
||
entstanden ist, nur andersherum.
|
||
|
||
BEIDE STEHEN HIER UND NICHT IN sichtbar(). Diese Funktion beantwortet
|
||
auch Fragen zu Aufgaben, Dateien und Terminen; ein Bereichsname hat
|
||
dort nichts zu suchen. Der Kommentar eine Bildschirmseite weiter oben
|
||
warnt woertlich davor. */
|
||
export function sichtbarEintrag(person, praefix = "e") {
|
||
/* RIEGEL 1 -- die Aussenrolle. Eine eigene, vollstaendige Regel:
|
||
genau die Bretter des Treffs, sonst nichts. */
|
||
if (AUSSEN_ROLLEN.has(person?.rolle)) {
|
||
const platz = TREFF_BRETTER.map(() => "?").join(", ");
|
||
const grund = { wo: `${praefix}.bereich IN (${platz})`, werte: [...TREFF_BRETTER] };
|
||
/* RIEGEL 1b -- WAS NOCH NICHT FREIGEGEBEN IST, GIBT ES NICHT
|
||
(11.09.2026). Termine und Highlights erscheinen der Community
|
||
erst, wenn jemand aus dem Team sie freigegeben hat.
|
||
|
||
DIE BEDINGUNG HAENGT HIER UND NICHT AM LESE-WEG, weil sie sonst
|
||
nur dort gaelte: Suche, Ausfuhr und jeder kuenftige Weg, der
|
||
sichtbarEintrag benutzt, haetten die unfreigegebenen Zeilen
|
||
weiterhin geliefert. Genau so ist am 10.09. ein Modi-Eintrag
|
||
durch die Suche gekommen, obwohl das Brett zu war. */
|
||
const frei = freigabeBedingung(person, praefix);
|
||
if (!frei) return grund;
|
||
return { wo: `(${grund.wo}) AND ${frei.wo}`, werte: [...grund.werte, ...frei.werte] };
|
||
}
|
||
const regel = sichtbarRoh2(person, praefix);
|
||
/* RIEGEL 2 -- wer nicht zum Treff gehoert, sieht seine Bretter nicht.
|
||
Auch DogFather geht hier durch; er steht in TREFF_ROLLEN und faellt
|
||
deshalb nicht heraus. */
|
||
if (!regel || TREFF_ROLLEN.has(person?.rolle)) return regel;
|
||
const platz = TREFF_BRETTER.map(() => "?").join(", ");
|
||
return {
|
||
wo: `(${regel.wo}) AND ${praefix}.bereich NOT IN (${platz})`,
|
||
werte: [...regel.werte, ...TREFF_BRETTER],
|
||
};
|
||
}
|
||
|
||
function sichtbarRoh2(person, praefix = "e") {
|
||
const regel = sichtbar(person);
|
||
if (!regel) return regel;
|
||
if (regel.wo === "1=1") return regel; // DogFather sieht ohnehin alles
|
||
if (!BEREICHE_FUER_ALLE.length) return ohneVertrauliche(regel, person, praefix);
|
||
const liste = BEREICHE_FUER_ALLE.map(() => "?").join(", ");
|
||
const mitAllen = {
|
||
wo: `(${praefix}.bereich IN (${liste}) OR ${regel.wo})`,
|
||
werte: [...BEREICHE_FUER_ALLE, ...regel.werte],
|
||
};
|
||
/* UND DANACH NOCH EINMAL ZU (10.09.2026).
|
||
|
||
sichtbar() haengt die Modi-Bedingung bereits an -- aber das ODER
|
||
hier oeffnet sie wieder: Ein Eintrag in einem `fuerAlle`-Bereich
|
||
kaeme durch, egal wem er gehoert. Heute hat kein Modi eine Kachel
|
||
dorthin; ein Aufruf an der Oberflaeche vorbei braucht sie aber
|
||
nicht. Eine Regel, die nur im Formular gilt, ist keine Regel. */
|
||
if (siehtModis(person)) return ohneVertrauliche(mitAllen, person, praefix);
|
||
return ohneVertrauliche({
|
||
wo: `(${mitAllen.wo}) AND ${ohneTeamDogi(praefix)}`,
|
||
werte: mitAllen.werte,
|
||
}, person, praefix);
|
||
}
|
||
|
||
const SPALTEN = `
|
||
e.id, e.bereich, e.art, e.titel, e.text, e.datum, e.uhrzeit, e.bewertung,
|
||
e.dringlichkeit, e.status, e.creator_id, e.erstellt, e.erstellt_von, e.geaendert,
|
||
e.hook, e.format, e.saeule_id, e.geplant,
|
||
e.event_ende, e.event_aufgaben, e.event_regeln,
|
||
e.creator_extern,
|
||
/* Was DogFather dafuer tun muesste -- nur bei den Angeboten
|
||
gefuellt, siehe BEREICHE.angebote. */
|
||
e.einsatz,
|
||
/* 1 = nur DogFather darf das lesen. Die Spalte MUSS mitkommen, auch
|
||
wenn die Regel unten schon dafuer sorgt, dass niemand Fremdes die
|
||
Zeile bekommt: Der Schreibende soll an seiner eigenen Zeile sehen,
|
||
dass sie vertraulich ist. Ohne diese Angabe saehe sie aus wie jede
|
||
andere -- und beim naechsten Mal schriebe er offen, was er
|
||
vertraulich meinte. */
|
||
e.nur_leitung,
|
||
/* Wann der Eintrag der Person geschickt wurde -- oder NULL. Die
|
||
Oberflaeche baut daraus entweder einen Knopf oder einen Satz; ohne
|
||
diese Angabe koennte sie nur einen Knopf zeigen, der beim zweiten
|
||
Druecken eine Absage bringt. */
|
||
e.gesendet_am,
|
||
${externSql("pc.name", "e.creator_extern")} AS creator_name,
|
||
pe.name AS erstellt_name,
|
||
(SELECT name FROM content_saeulen s WHERE s.id = e.saeule_id) AS saeule_name,
|
||
(SELECT slot FROM content_saeulen s WHERE s.id = e.saeule_id) AS saeule_slot`;
|
||
|
||
/* Passt die gewaehlte Saeule zu dem Creator, um den es geht? Gibt einen
|
||
Fehlertext zurueck oder null, wenn alles stimmt. */
|
||
function saeulePasst(saeuleId, creatorId) {
|
||
if (!saeuleId) return null;
|
||
const s = db().prepare("SELECT creator_id FROM content_saeulen WHERE id = ?").get(saeuleId);
|
||
if (!s) return "Diese Säule gibt es nicht.";
|
||
if (creatorId && s.creator_id !== creatorId) return "Diese Säule gehört zu einem anderen Creator.";
|
||
return null;
|
||
}
|
||
|
||
/* =====================================================================
|
||
WAS EIN TREFF-BRETT ZUSAETZLICH MITBRINGT (11.09.2026)
|
||
|
||
Drei Angaben, die es nur dort gibt: wie viele "Will ich auch" ein
|
||
Wunsch hat, ob meine Stimme dabei ist, ob die Ansage angeheftet und
|
||
ob der Eintrag freigegeben ist.
|
||
|
||
SIE HAENGEN NICHT AN SPALTEN, sondern werden nur fuer die sieben
|
||
Bretter angehaengt. Drei Unterabfragen je Zeile sind hier
|
||
bedeutungslos (die Tabellen haben eine Handvoll Zeilen), auf den
|
||
Betreuungsbrettern waeren sie es nicht -- und vor allem waeren sie
|
||
dort eine Auskunft ueber etwas, das es in diesem Bereich gar nicht
|
||
gibt.
|
||
|
||
DER ROLLENNAME KOMMT MIT (Entscheidung Filipe, 11.09.2026: "voller
|
||
Rollenname zeigen"). Er kommt als ROLLE, der Klartext wird erst in
|
||
der Antwort gebildet -- eine Zuordnung Rolle -> Name im
|
||
ausgelieferten JavaScript waere eine Liste aller Rollen dieses
|
||
Hauses auf jedem Rechner der Community.
|
||
===================================================================== */
|
||
const TREFF_SPALTEN = `,
|
||
(SELECT COUNT(*) FROM treff_stimmen ts WHERE ts.eintrag_id = e.id) AS stimmen,
|
||
(SELECT COUNT(*) FROM treff_stimmen ts
|
||
WHERE ts.eintrag_id = e.id AND ts.person_id = ?) AS meine_stimme,
|
||
(SELECT COUNT(*) FROM treff_angeheftet ta WHERE ta.eintrag_id = e.id) AS angeheftet,
|
||
(SELECT COUNT(*) FROM treff_freigaben tf WHERE tf.eintrag_id = e.id) AS freigegeben,
|
||
pe.rolle AS erstellt_rolle`;
|
||
|
||
const VERBUND = `
|
||
FROM eintraege e
|
||
LEFT JOIN personen pc ON pc.id = e.creator_id
|
||
LEFT JOIN personen pe ON pe.id = e.erstellt_von`;
|
||
|
||
/* ---------- Lesen ------------------------------------------------------- */
|
||
|
||
bereicheRouter.get("/workspace/api/bereich/:bereich", (req, res) => {
|
||
try {
|
||
const bereich = String(req.params.bereich);
|
||
const einstellung = BEREICHE[bereich];
|
||
if (!einstellung) return res.status(404).json({ fehler: "nicht_gefunden" });
|
||
|
||
const regel = sichtbarEintrag(req.sicht || req.person);
|
||
if (!regel) return res.status(404).json({ fehler: "nicht_gefunden" });
|
||
|
||
const treffBrett = TREFF_BRETTER.includes(bereich);
|
||
|
||
/* DIE REIHENFOLGE GEHOERT ZUM BRETT (11.09.2026).
|
||
|
||
Am Anschlagbrett steht oben, was angeheftet ist -- sonst waere
|
||
das Anheften eine Zierde. Auf der Wunschliste steht oben, was die
|
||
meisten wollen; genau das ist der Sinn von "Will ich auch", und
|
||
eine Liste nach Datum haette die Abstimmung unsichtbar gemacht.
|
||
Ueberall sonst bleibt es, wie es war. */
|
||
const reihenfolge = bereich === "anschlag"
|
||
? "angeheftet DESC, e.datum DESC, e.id DESC"
|
||
: bereich === "wunsch"
|
||
/* ENTSCHIEDENES NACH UNTEN -- ABER NICHT WEG (17.09.2026).
|
||
|
||
Die Sortierung nach Stimmen gibt es seit dem 11.09. Seit es
|
||
vier Zustaende gibt, reicht sie nicht mehr: Ein gemachter
|
||
Wunsch mit vielen Stimmen stuende dauerhaft ganz oben und
|
||
verdraengte die offenen, ueber die noch zu entscheiden ist.
|
||
|
||
Loeschen waere die falsche Antwort. Gerade der ERFUELLTE
|
||
Wunsch ist der Beweis, dass sich Schreiben lohnt -- er
|
||
gehoert gesehen, nur nicht an der ersten Stelle. */
|
||
? `CASE e.status WHEN 'offen' THEN 0 WHEN 'angenommen' THEN 0 ELSE 1 END,
|
||
stimmen DESC, e.datum DESC, e.id DESC`
|
||
: `CASE e.status WHEN 'offen' THEN 0 ELSE 1 END,
|
||
CASE e.dringlichkeit WHEN 'hoch' THEN 0 WHEN 'mittel' THEN 1 ELSE 2 END,
|
||
e.datum DESC, e.id DESC`;
|
||
|
||
const wer = (req.sicht || req.person)?.id ?? 0;
|
||
const eintraege = db().prepare(`
|
||
SELECT ${SPALTEN}${treffBrett ? TREFF_SPALTEN : ""} ${VERBUND}
|
||
WHERE ${regel.wo} AND e.bereich = ?
|
||
ORDER BY ${reihenfolge}`)
|
||
.all(...(treffBrett ? [wer] : []), ...regel.werte, bereich);
|
||
|
||
/* DASS DIES EIN BRETT DES TREFFS IST, SAGT DER SERVER (11.09.2026).
|
||
|
||
Die Oberflaeche braucht die Auskunft, um ihre Knoepfe zu bauen
|
||
("Will ich auch", anheften, freigeben, melden). Sie koennte den
|
||
Bereichsnamen gegen eine Liste im Browser halten -- dann stuenden
|
||
die Namen aller sieben Bretter in einer ausgelieferten Datei, und
|
||
es gaebe eine zweite Wahrheit darueber, welche es sind. So gibt
|
||
es weiterhin genau eine (TREFF_BRETTER), und der Browser fragt
|
||
sie, statt sie zu kennen. */
|
||
/* WEM GEHOERT EIN EINTRAG AUF DIESEM BRETT? (11.09.2026)
|
||
|
||
Filipe, mit Bildschirmfoto des Feldes "Gilt für: Agentur":
|
||
"auf dieser seite soll nichts stehen von agentur, diese seite
|
||
hier ist nur für mich meine modis und meine community."
|
||
|
||
Er hatte recht, und der Fehler war ein fest eingetragenes Wort:
|
||
In bereich.js stand woertlich "Agentur" -- richtig auf der
|
||
Agenturadresse, falsch auf jeder anderen. Ein Wort in der
|
||
Oberflaeche, das eine Tatsache ueber den Server behauptet, ist
|
||
genau die Sorte Zweitschrift, die auseinanderlaeuft.
|
||
|
||
Jetzt sagt der Server es. Er weiss beides: welches Brett es ist
|
||
und in welchem Haus die Person gerade steht. */
|
||
const gehoert = treffBrett ? "Der Treff"
|
||
: (req.sicht || req.person)?.haus === "crew" ? "Team Dogi"
|
||
: "Agentur";
|
||
|
||
res.json({
|
||
bereich, einstellung, treff: treffBrett, gehoert,
|
||
eintraege: treffBrett ? eintraege.map(mitRollenname) : eintraege,
|
||
});
|
||
} catch (fehler) {
|
||
console.error("[workspace] Bereich lesen:", fehler?.message);
|
||
res.status(503).json({ fehler: "nicht_verfuegbar" });
|
||
}
|
||
});
|
||
|
||
/* =====================================================================
|
||
EINEN EINTRAG AN DIE PERSON SCHICKEN (11.09.2026)
|
||
|
||
Der Entwicklungs-Bereich ist eine Aufzeichnung fuer DogFather und die
|
||
rechte Hand; die Person selbst sieht ihn nicht. Diese Route ist die
|
||
einzige Bruecke -- und sie geht nur in EINE Richtung, ausdruecklich
|
||
und einzeln.
|
||
|
||
WARUM NICHT EINFACH ALLES SICHTBAR MACHEN: Eine halb sichtbare Akte
|
||
ist schlimmer als eine geschlossene. Niemand weiss mehr, was der
|
||
andere gerade liest, und man schreibt anders -- vorsichtiger,
|
||
weniger, oder gar nicht mehr.
|
||
|
||
WARUM ES DIESE BRUECKE TROTZDEM BRAUCHT: Die Forschung zu
|
||
freiwilligen Moderatoren ist an dieser Stelle eindeutig. Was Menschen
|
||
haelt, ist Anerkennung -- Dank und Rueckmeldung erhoehen die
|
||
Verweildauer messbar. Ein "Das laeuft gut", das nur in einer Akte
|
||
steht, hat niemandem geholfen.
|
||
|
||
DER WEG IST DER CHAT und keine neue Benachrichtigungsart: Die Person
|
||
findet die Nachricht dort, wo sie alles andere auch findet, kann
|
||
antworten, und sie steht in ihrem Verlauf. Ein eigener Kanal dafuer
|
||
waere ein zweiter Ort mit einer roten Zahl.
|
||
|
||
EINMAL IST EINMAL. `gesendet_am` haelt fest, wann es geschehen ist --
|
||
die Route schickt danach nicht noch einmal. Zweimal dasselbe Lob ist
|
||
kein doppeltes Lob, sondern ein Versehen, das jeder bemerkt.
|
||
===================================================================== */
|
||
bereicheRouter.post("/workspace/api/bereich/entwicklung/:id/senden",
|
||
gleicheHerkunft, (req, res) => {
|
||
try {
|
||
if (!fuehrtTeamDogi(req.person)) 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 e = db().prepare(
|
||
`SELECT id, bereich, art, titel, text, einsatz, creator_id, gesendet_am
|
||
FROM eintraege WHERE id = ?`).get(id);
|
||
if (!e || e.bereich !== "entwicklung") {
|
||
return res.status(404).json({ fehler: "nicht_gefunden" });
|
||
}
|
||
if (!e.creator_id) {
|
||
return res.status(400).json({
|
||
fehler: "Dieser Eintrag gehört zu niemandem – trag zuerst ein, um wen es geht.",
|
||
});
|
||
}
|
||
if (e.gesendet_am) {
|
||
return res.status(409).json({ fehler: "Das ist schon geschickt.", am: e.gesendet_am });
|
||
}
|
||
|
||
/* DER TEXT WIRD GEBAUT UND NICHT ROH GESCHICKT. Im Bereich steht
|
||
eine Notiz ("Ruhig geblieben, als es kippte"); als Nachricht
|
||
ohne Zusammenhang liest sich das wie ein Fetzen. Die Art davor
|
||
sagt, was gemeint ist, und der Einsatz dahinter, was daraus
|
||
folgen soll -- beides steht ohnehin schon da. */
|
||
const art = BEREICHE.entwicklung.arten[e.art] || "";
|
||
const stuecke = [
|
||
art ? `${art}: ${e.titel}` : e.titel,
|
||
e.text || "",
|
||
e.einsatz ? `Was daraus folgen soll: ${e.einsatz}` : "",
|
||
].filter(Boolean);
|
||
|
||
const geschickt = nachrichtSchicken(req.person, e.creator_id, stuecke.join("\n\n"));
|
||
if (!geschickt) {
|
||
return res.status(400).json({
|
||
fehler: "Die Nachricht ging nicht raus – ist die Person noch aktiv?",
|
||
});
|
||
}
|
||
|
||
const am = jetzt();
|
||
db().prepare("UPDATE eintraege SET gesendet_am = ? WHERE id = ?").run(am, id);
|
||
protokolliere("entwicklung_geschickt", {
|
||
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
|
||
detail: `#${id} an #${e.creator_id}`,
|
||
});
|
||
res.json({ ok: true, am, raum_id: geschickt.raum_id });
|
||
} catch (fehler) {
|
||
console.error("[workspace] Entwicklung schicken:", fehler?.message);
|
||
res.status(503).json({ fehler: "nicht_verfuegbar" });
|
||
}
|
||
});
|
||
|
||
/* ---------- Prüfen ------------------------------------------------------- */
|
||
|
||
function pruefe(bereich, körper, { neu }) {
|
||
const einstellung = BEREICHE[bereich];
|
||
const fehler = [];
|
||
const aus = {};
|
||
|
||
if (neu || körper.titel !== undefined) {
|
||
const t = String(körper.titel ?? "").trim();
|
||
if (t.length < 2) fehler.push("Titel fehlt.");
|
||
else if (t.length > TITEL_MAX) fehler.push("Titel ist zu lang.");
|
||
else aus.titel = t;
|
||
}
|
||
if (neu || körper.art !== undefined) {
|
||
const a = String(körper.art ?? "");
|
||
if (!Object.hasOwn(einstellung.arten, a)) fehler.push("Unbekannte Art.");
|
||
else aus.art = a;
|
||
}
|
||
if (körper.text !== undefined) {
|
||
const t = String(körper.text ?? "").trim();
|
||
if (t.length > TEXT_MAX) fehler.push("Text ist zu lang.");
|
||
else aus.text = t || null;
|
||
}
|
||
if (neu || körper.datum !== undefined) {
|
||
const d = String(körper.datum ?? "").trim();
|
||
if (!d) aus.datum = jetzt().slice(0, 10);
|
||
else if (!/^\d{4}-\d{2}-\d{2}$/.test(d) || Number.isNaN(Date.parse(d))) {
|
||
fehler.push("Datum ist ungültig.");
|
||
} else aus.datum = d;
|
||
}
|
||
/* DIE UHRZEIT (17.09.2026) -- optional, und leer heisst ausdruecklich
|
||
"ohne Uhrzeit" und nicht "unveraendert". Sonst liesse sich eine
|
||
einmal gesetzte Zeit nie wieder entfernen, und das faellt erst auf,
|
||
wenn ein Termin verschoben wird. */
|
||
if (körper.uhrzeit !== undefined) {
|
||
const u = String(körper.uhrzeit ?? "").trim();
|
||
if (!u) aus.uhrzeit = null;
|
||
else if (!/^([01]\d|2[0-3]):[0-5]\d$/.test(u)) fehler.push("Uhrzeit ist ungültig.");
|
||
else aus.uhrzeit = u;
|
||
}
|
||
if (körper.status !== undefined) {
|
||
/* JE BEREICH, NICHT GLOBAL (17.09.2026). Die Wunschliste kennt
|
||
vier Zustaende, alle anderen zwei. Eine gemeinsame Liste haette
|
||
"Diesmal nicht" auch an einem Schutzvorfall erlaubt -- und dort
|
||
bedeutet es nichts. */
|
||
const erlaubt = einstellung.zustaende
|
||
? Object.keys(einstellung.zustaende) : STATUS;
|
||
if (!erlaubt.includes(körper.status)) fehler.push("Unbekannter Status.");
|
||
else aus.status = körper.status;
|
||
}
|
||
/* DER GEPLANTE TERMIN eines Wunsches. Bisher gab es das Feld nur in
|
||
der Content-Planung; hier traegt es dieselbe Bedeutung und darf
|
||
deshalb dasselbe Format haben. Leer heisst "noch kein Termin" und
|
||
nicht "unveraendert". */
|
||
if (einstellung.mitGeplant && körper.geplant !== undefined) {
|
||
const g = String(körper.geplant ?? "").trim();
|
||
if (!g) aus.geplant = null;
|
||
else if (!/^\d{4}-\d{2}-\d{2}$/.test(g) || Number.isNaN(Date.parse(g))) {
|
||
fehler.push("Der geplante Tag ist ungültig.");
|
||
} else aus.geplant = g;
|
||
}
|
||
/* Bewertung und Dringlichkeit gibt es nur dort, wo der Bereich sie
|
||
vorsieht -- sonst werden sie stillschweigend verworfen. */
|
||
if (einstellung.bewertung && körper.bewertung !== undefined) {
|
||
if (körper.bewertung === null || körper.bewertung === "") aus.bewertung = null;
|
||
else {
|
||
const b = Number(körper.bewertung);
|
||
if (!Number.isInteger(b) || b < 1 || b > 5) fehler.push("Bewertung muss 1 bis 5 sein.");
|
||
else aus.bewertung = b;
|
||
}
|
||
}
|
||
if (einstellung.dringlichkeit && körper.dringlichkeit !== undefined) {
|
||
if (!DRINGLICHKEITEN.includes(körper.dringlichkeit)) fehler.push("Unbekannte Dringlichkeit.");
|
||
else aus.dringlichkeit = körper.dringlichkeit;
|
||
}
|
||
/* Nur dort, wo der Bereich es vorsieht -- sonst koennte man einen
|
||
Schutzvorfall oder eine Content-Idee als "vertraulich" markieren
|
||
und damit vor den eigenen Leuten verstecken. */
|
||
if (einstellung.vertraulich && körper.nur_leitung !== undefined) {
|
||
aus.nur_leitung = (körper.nur_leitung === true || körper.nur_leitung === 1
|
||
|| körper.nur_leitung === "1") ? 1 : 0;
|
||
}
|
||
|
||
/* Die vier Content-Felder gibt es nur in der Content-Planung. In jedem
|
||
anderen Bereich werden sie stillschweigend verworfen -- wie Bewertung
|
||
und Dringlichkeit auch. Sonst stuende irgendwann ein Aufhaenger an
|
||
einem Schutzvorfall. */
|
||
if (bereich === "content") {
|
||
if (körper.hook !== undefined) {
|
||
const h = String(körper.hook ?? "").trim();
|
||
if (h.length > 300) fehler.push("Der Hook ist zu lang.");
|
||
else aus.hook = h || null;
|
||
}
|
||
if (körper.format !== undefined) {
|
||
const f = String(körper.format ?? "").trim();
|
||
if (f.length > 60) fehler.push("Das Format ist zu lang.");
|
||
else aus.format = f || null;
|
||
}
|
||
if (körper.saeule_id !== undefined) {
|
||
if (körper.saeule_id === null || körper.saeule_id === "") aus.saeule_id = null;
|
||
else {
|
||
const s = Number(körper.saeule_id);
|
||
if (!Number.isInteger(s) || s < 1) fehler.push("Unbekannte Säule.");
|
||
else aus.saeule_id = s;
|
||
}
|
||
}
|
||
if (körper.geplant !== undefined) {
|
||
const g = String(körper.geplant ?? "").trim();
|
||
if (!g) aus.geplant = null;
|
||
/* Datum ODER Datum mit Uhrzeit -- wer nur den Tag weiss, soll nicht
|
||
zu einer erfundenen Uhrzeit gezwungen werden. */
|
||
else if (!/^\d{4}-\d{2}-\d{2}(T\d{2}:\d{2})?$/.test(g) || Number.isNaN(Date.parse(g))) {
|
||
fehler.push("Der geplante Zeitpunkt ist ungültig.");
|
||
} else aus.geplant = g;
|
||
}
|
||
}
|
||
/* ---- Agentur-Events: Zeitraum, Aufgaben, Regeln -------------------
|
||
Nur im Agentur-Bereich, nach demselben Muster wie die vier
|
||
Content-Felder darueber: anderswo werden sie stillschweigend
|
||
verworfen. Sonst haenge eines Tages ein Preisausschreiben an einem
|
||
Schutzvorfall. */
|
||
if (bereich === "agentur") {
|
||
if (körper.event_ende !== undefined) {
|
||
const e = String(körper.event_ende ?? "").trim();
|
||
if (!e) aus.event_ende = null;
|
||
else if (!/^\d{4}-\d{2}-\d{2}$/.test(e) || Number.isNaN(Date.parse(e))) {
|
||
fehler.push("Das Ende des Zeitraums ist ungültig.");
|
||
} else aus.event_ende = e;
|
||
}
|
||
for (const [feld, name] of [["event_aufgaben", "Die Aufgaben"], ["event_regeln", "Die Regeln"]]) {
|
||
if (körper[feld] === undefined) continue;
|
||
const t = String(körper[feld] ?? "").trim();
|
||
if (t.length > TEXT_MAX) fehler.push(`${name} sind zu lang.`);
|
||
else aus[feld] = t || null;
|
||
}
|
||
/* "Bis" vor "von" ist kein Zeitraum, sondern ein Tippfehler -- und
|
||
einer, den man einer Liste nicht ansieht: Der Eintrag stuende da,
|
||
liefe aber schon abgelaufen ein. Geprueft wird gegen das Datum,
|
||
das GERADE gesetzt wird; beim Aendern nur einer der beiden Seiten
|
||
ergaenzt der Aufrufer die andere mit (siehe PATCH). */
|
||
if (aus.event_ende && aus.datum && aus.event_ende < aus.datum) {
|
||
fehler.push("Das Ende liegt vor dem Beginn.");
|
||
}
|
||
}
|
||
|
||
if (körper.creator_id !== undefined) {
|
||
const w = körper.creator_id;
|
||
if (w === null || w === "") aus.creator_id = null;
|
||
else {
|
||
const z = Number(w);
|
||
if (!Number.isInteger(z) || z < 1) fehler.push("Ungültige Zuordnung.");
|
||
else aus.creator_id = z;
|
||
}
|
||
}
|
||
|
||
/* Ein frei eingetragener Name statt eines Creators -- eine Marke, ein
|
||
Partner, jemand ohne Konto im Workspace. Er schlaegt die Auswahl:
|
||
Wer tippt, meint das Getippte. Der Eintrag gehoert dann zu keinem
|
||
Konto; sichtbar bleibt er ueber erstellt_von (siehe sichtbar()). */
|
||
externPruefen(körper, aus, "creator", fehler);
|
||
|
||
/* Das Einsatz-Feld gibt es nur in Bereichen, die es kennen. Ein
|
||
Aufruf an der Oberflaeche vorbei soll nicht in jedem Bereich eine
|
||
Spalte fuellen koennen, die dort nichts bedeutet. */
|
||
if (einstellung.einsatzFeld && körper.einsatz !== undefined) {
|
||
const t = String(körper.einsatz ?? "").trim();
|
||
if (t.length > TEXT_MAX) fehler.push("Der Einsatz ist zu lang.");
|
||
else aus.einsatz = t || null;
|
||
}
|
||
|
||
/* Ein Agentur-Eintrag gehoert NIEMANDEM einzeln (07.09.2026).
|
||
|
||
Er gilt fuer alle, und genau deshalb sieht ihn auch jeder (siehe
|
||
`fuerAlle` oben). Eine Zuordnung waere hier nicht bloss unnoetig,
|
||
sie waere irrefuehrend: Ein Event mit dem Namen einer Creatorin
|
||
daneben liest sich, als sei es ihres. Die Oberflaeche bietet
|
||
deshalb nur noch "Agentur" an -- und diese Zeilen sorgen dafuer,
|
||
dass ein Aufruf an der Oberflaeche vorbei zum selben Ergebnis
|
||
kommt. Eine Regel, die nur im Formular steht, ist keine Regel.
|
||
|
||
GANZ ZUM SCHLUSS, und das ist der Punkt: Der freie Name wird eine
|
||
Zeile darueber gesetzt. Stuende dieser Riegel vorher -- der
|
||
naheliegende Ort, gleich bei der Creator-Zuordnung --, haette
|
||
externPruefen ihn danach wieder aufgemacht, und ein getippter Name
|
||
stuende trotz allem am Event. Zwei richtige Regeln, falsche
|
||
Reihenfolge, kein Fehler zu sehen. */
|
||
if (einstellung.ohneCreatorBezug) {
|
||
aus.creator_id = null;
|
||
aus.creator_extern = null;
|
||
}
|
||
|
||
return { aus, fehler };
|
||
}
|
||
|
||
/* ---------- Anlegen ------------------------------------------------------ */
|
||
|
||
bereicheRouter.post("/workspace/api/bereich/:bereich", gleicheHerkunft, (req, res) => {
|
||
try {
|
||
const bereich = String(req.params.bereich);
|
||
if (!BEREICHE[bereich]) return res.status(404).json({ fehler: "nicht_gefunden" });
|
||
const regel = sichtbar(req.person);
|
||
if (!regel) return res.status(404).json({ fehler: "nicht_gefunden" });
|
||
|
||
/* DIE SCHREIBTAFEL DES TREFFS (11.09.2026).
|
||
|
||
Auf welches der sieben Bretter jemand von aussen schreiben darf,
|
||
steht in TREFF_SCHREIBEN -- an einer Stelle, aus der auch die
|
||
Oberflaeche ihre Knoepfe holt (/api/treff/lage). Waeren es zwei
|
||
Stellen, koennte ein Knopf erscheinen, den der Server ablehnt --
|
||
oder, schlimmer, umgekehrt.
|
||
|
||
DER TEXT WIRD DURCHGEREICHT, nicht durch "nicht_erlaubt" ersetzt:
|
||
"Ab Dabei kannst du hier schreiben" beantwortet die Frage, die
|
||
der Mensch davor gerade hat. */
|
||
const warum = darfSchreiben(req.person, bereich);
|
||
if (warum) return res.status(403).json({ fehler: warum });
|
||
|
||
const { aus, fehler } = pruefe(bereich, req.body || {}, { neu: true });
|
||
if (fehler.length) return res.status(400).json({ fehler: fehler.join(" ") });
|
||
|
||
/* Ein Creator schreibt immer in den eigenen Bereich, egal was im
|
||
Aufruf steht. Ein Scout in den eines Creators, den er betreut --
|
||
niemals in einen fremden und niemals "auf sich selbst", denn ein
|
||
Scout hat gar keinen eigenen Betreuungsbereich. */
|
||
if (req.person.rolle === "creator") {
|
||
aus.creator_id = req.person.id;
|
||
aus.creator_extern = null; // der eigene Bereich gehört ihm, nicht einem Namen
|
||
} else if (req.person.rolle === "scout" && !aus.creator_extern) {
|
||
/* Der freie Name nimmt diesen Zweig ausdrücklich aus: Wer "Marke
|
||
XY" eintippt, will keinen seiner Creator zugeordnet bekommen.
|
||
Ohne diese Ausnahme hätte die Notlösung darunter den getippten
|
||
Namen stillschweigend durch den erstbesten Creator ersetzt --
|
||
der Eintrag stünde dann bei jemandem, der nichts damit zu tun
|
||
hat. Sichtbar bleibt er über erstellt_von. */
|
||
const w = Number(aus.creator_id);
|
||
if (!darfCreator(req.person, w)) {
|
||
const erster = betreuteIds(req.person)[0];
|
||
if (!erster) return res.status(403).json({ fehler: "Dir ist kein Creator zugeteilt." });
|
||
aus.creator_id = erster;
|
||
}
|
||
}
|
||
/* WEM GEHOERT DER EINTRAG? DAS HAENGT AM BEREICH (11.09.2026).
|
||
|
||
Ueberall sonst zeigt `creator_id` auf einen Creator -- die
|
||
Bereichsseiten sind Betreuungsakten. Im Entwicklungs-Bereich
|
||
zeigt sie auf ein Mitglied von Team Dogi: Dort steht, was ueber
|
||
die Zeit an einem Menschen aus dem Team auffaellt.
|
||
|
||
Die Spalte heisst weiterhin creator_id. Das ist Geschichte, kein
|
||
Inhalt -- sie haelt eine Personennummer, und dieselbe
|
||
Ueberlegung steht schon in workspace-checkliste.js.
|
||
|
||
BEIM ERSTEN ANLAUF FEHLTE DAS, und die Meldung war irrefuehrend
|
||
("Zugeordneter Creator existiert nicht" -- die Person existiert
|
||
sehr wohl, sie ist nur kein Creator). Gefunden von der Pruefung,
|
||
nicht vom Auge. */
|
||
const zielRollen = bereich === "entwicklung"
|
||
? "rolle IN ('hand','modi')"
|
||
: "rolle = 'creator'";
|
||
if (aus.creator_id
|
||
&& !db().prepare(`SELECT 1 FROM personen WHERE id = ? AND ${zielRollen}`)
|
||
.get(aus.creator_id)) {
|
||
return res.status(400).json({
|
||
fehler: bereich === "entwicklung"
|
||
? "Diese Person gehört nicht zum Team."
|
||
: "Zugeordneter Creator existiert nicht.",
|
||
});
|
||
}
|
||
|
||
/* Eine Saeule gehoert immer GENAU EINEM Creator. Ohne diese Pruefung
|
||
koennte man ein Video an die Saeule eines fremden Creators haengen
|
||
-- und darueber in der Balance-Auswertung Namen sehen, die einen
|
||
nichts angehen. Die Sichtbarkeitsregel oben schuetzt die Eintraege,
|
||
nicht die Verweise zwischen ihnen. */
|
||
const saeuleFehler = saeulePasst(aus.saeule_id, aus.creator_id);
|
||
if (saeuleFehler) return res.status(400).json({ fehler: saeuleFehler });
|
||
|
||
const { lastInsertRowid } = db().prepare(`
|
||
INSERT INTO eintraege
|
||
(bereich, art, titel, text, datum, uhrzeit, bewertung, dringlichkeit, status,
|
||
creator_id, creator_extern, erstellt, erstellt_von, hook, format, saeule_id, geplant,
|
||
event_ende, event_aufgaben, event_regeln, einsatz, nur_leitung)
|
||
VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)`).run(
|
||
bereich, aus.art, aus.titel, aus.text ?? null, aus.datum, aus.uhrzeit ?? null,
|
||
aus.bewertung ?? null, aus.dringlichkeit ?? "mittel", aus.status ?? "offen",
|
||
aus.creator_id ?? null, aus.creator_extern ?? null, jetzt(), req.person.id,
|
||
aus.hook ?? null, aus.format ?? null, aus.saeule_id ?? null, aus.geplant ?? null,
|
||
aus.event_ende ?? null, aus.event_aufgaben ?? null, aus.event_regeln ?? null,
|
||
aus.einsatz ?? null,
|
||
/* 0 und nicht NULL als Vorgabe: NULL hiesse "unbekannt", und
|
||
unbekannt ist bei einer Vertraulichkeit die falsche Antwort.
|
||
Wer nichts waehlt, schreibt fuers Team -- das ist der offene
|
||
Fall, und der soll der Normalfall sein. */
|
||
aus.nur_leitung ?? 0);
|
||
|
||
protokolliere("eintrag_angelegt", {
|
||
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
|
||
detail: `${bereich} #${lastInsertRowid} ${aus.titel}`.slice(0, 120),
|
||
});
|
||
res.status(201).json({ id: Number(lastInsertRowid) });
|
||
} catch (fehler) {
|
||
console.error("[workspace] Eintrag anlegen:", fehler?.message);
|
||
res.status(503).json({ fehler: "nicht_verfuegbar" });
|
||
}
|
||
});
|
||
|
||
/* ---------- Ändern und Löschen ------------------------------------------- */
|
||
|
||
function holen(req, id) {
|
||
const regel = sichtbarEintrag(req.person);
|
||
if (!regel) return null;
|
||
return db().prepare(`SELECT e.* ${VERBUND} WHERE ${regel.wo} AND e.id = ?`)
|
||
.get(...regel.werte, id);
|
||
}
|
||
|
||
bereicheRouter.patch("/workspace/api/bereich/:bereich/:id", gleicheHerkunft, (req, res) => {
|
||
try {
|
||
const bereich = String(req.params.bereich);
|
||
const id = Number(req.params.id);
|
||
if (!BEREICHE[bereich] || !Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
|
||
|
||
const eintrag = holen(req, id);
|
||
if (!eintrag || eintrag.bereich !== bereich) return res.status(404).json({ fehler: "nicht_gefunden" });
|
||
|
||
const { aus, fehler } = pruefe(bereich, req.body || {}, { neu: false });
|
||
if (fehler.length) return res.status(400).json({ fehler: fehler.join(" ") });
|
||
if (!istLeitung(req.person)) delete aus.creator_id;
|
||
|
||
/* Zeitraum beim AENDERN -- genauso wichtig wie beim Anlegen und
|
||
leichter zu uebersehen: pruefe() sieht nur die Felder, die im
|
||
Aufruf stehen. Wer nur das Ende verschiebt, schickt kein `datum`
|
||
mit; die Pruefung dort haette nichts zu vergleichen und liesse
|
||
jedes Ende durch. Deshalb hier gegen den GESPEICHERTEN Wert, und
|
||
zwar in beide Richtungen -- man kann den Zeitraum auch dadurch
|
||
verdrehen, dass man den Beginn nach hinten schiebt. */
|
||
if (bereich === "agentur" && (aus.event_ende !== undefined || aus.datum !== undefined)) {
|
||
const von = aus.datum !== undefined ? aus.datum : eintrag.datum;
|
||
const bis = aus.event_ende !== undefined ? aus.event_ende : eintrag.event_ende;
|
||
if (von && bis && bis < von) {
|
||
return res.status(400).json({ fehler: "Das Ende liegt vor dem Beginn." });
|
||
}
|
||
}
|
||
|
||
/* Beim Aendern gilt dieselbe Regel -- sonst waere die Pruefung beim
|
||
Anlegen wertlos: Man legt ohne Saeule an und haengt sie danach an. */
|
||
if (aus.saeule_id !== undefined) {
|
||
const zuWem = aus.creator_id !== undefined ? aus.creator_id : eintrag.creator_id;
|
||
const saeuleFehler = saeulePasst(aus.saeule_id, zuWem);
|
||
if (saeuleFehler) return res.status(400).json({ fehler: saeuleFehler });
|
||
}
|
||
|
||
const felder = Object.keys(aus);
|
||
if (!felder.length) return res.status(400).json({ fehler: "nichts_zu_aendern" });
|
||
|
||
db().prepare(
|
||
`UPDATE eintraege SET ${felder.map((f) => `${f} = ?`).join(", ")}, geaendert = ? WHERE id = ?`
|
||
).run(...felder.map((f) => aus[f]), jetzt(), id);
|
||
|
||
protokolliere("eintrag_geaendert", {
|
||
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
|
||
detail: `${bereich} #${id} ${felder.join(",")}`.slice(0, 120),
|
||
});
|
||
res.json({ ok: true });
|
||
} catch (fehler) {
|
||
console.error("[workspace] Eintrag ändern:", fehler?.message);
|
||
res.status(503).json({ fehler: "nicht_verfuegbar" });
|
||
}
|
||
});
|
||
|
||
bereicheRouter.delete("/workspace/api/bereich/:bereich/:id", gleicheHerkunft, (req, res) => {
|
||
try {
|
||
const bereich = String(req.params.bereich);
|
||
const id = Number(req.params.id);
|
||
if (!BEREICHE[bereich] || !Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
|
||
|
||
const eintrag = holen(req, id);
|
||
if (!eintrag || eintrag.bereich !== bereich) return res.status(404).json({ fehler: "nicht_gefunden" });
|
||
|
||
/* Löschen darf das Management und wer den Eintrag selbst geschrieben
|
||
hat -- sonst könnte ein Creator eine Notiz des Managements über
|
||
seinen eigenen Bereich verschwinden lassen. */
|
||
/* IM TREFF RAEUMT AUCH EIN MODI AUF (11.09.2026). Er ist dort die
|
||
Moderation; waere Aufraeumen der Leitung vorbehalten, bliebe ein
|
||
Beitrag stehen, bis jemand Zeit hat -- und genau in dieser Zeit
|
||
liest ihn die Community. */
|
||
const treffBrett = TREFF_BRETTER.includes(bereich);
|
||
const darfWeg = treffBrett
|
||
? TREFF_TEAM_ROLLEN.has(req.person.rolle) || eintrag.erstellt_von === req.person.id
|
||
: istLeitung(req.person) || eintrag.erstellt_von === req.person.id;
|
||
if (!darfWeg) return res.status(403).json({ fehler: "nicht_erlaubt" });
|
||
|
||
/* DER GRUND WIRD FESTGEHALTEN, BEVOR DER BEITRAG VERSCHWINDET
|
||
(DSA Art. 17). Danach waere es zu spaet: Titel und Verfasser
|
||
stuenden nirgends mehr, und eine Begruendung ohne den Beitrag,
|
||
den sie begruendet, ist keine.
|
||
|
||
DER GRUND KOMMT AUS DER ADRESSE, und das ist keine Vorliebe,
|
||
sondern gemessen (11.09.2026): Nodes HTTP-Parser weist ein
|
||
DELETE MIT KOERPER mit einem leeren 400 ab, bevor Express die
|
||
Anfrage ueberhaupt sieht -- eine Antwort mit genau einem
|
||
Kopffeld ("connection: close") und ohne Text. Wer den Fehler
|
||
sucht, sucht ihn in dieser Route, und hier ist keiner.
|
||
|
||
Der Koerper bleibt als zweite Moeglichkeit stehen: Er schadet
|
||
nicht, und wenn ein anderer Weg (ein Werkzeug, eine kuenftige
|
||
Fassung von Node) doch einen mitschickt, wird er gelesen. Zwei
|
||
Quellen fuer denselben Wert sind hier keine zwei Wahrheiten --
|
||
es ist derselbe Wert, nur zwei Briefkaesten. */
|
||
const nein = entfernenVorbereiten(req.person, eintrag,
|
||
req.body?.grund ?? req.query?.grund);
|
||
if (nein) return res.status(400).json({ fehler: nein });
|
||
|
||
db().prepare("DELETE FROM eintraege WHERE id = ?").run(id);
|
||
protokolliere("eintrag_geloescht", {
|
||
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
|
||
detail: `${bereich} #${id} ${eintrag.titel}`.slice(0, 120),
|
||
});
|
||
res.json({ ok: true });
|
||
} catch (fehler) {
|
||
console.error("[workspace] Eintrag löschen:", fehler?.message);
|
||
res.status(503).json({ fehler: "nicht_verfuegbar" });
|
||
}
|
||
});
|