Files
dogfather-universe/server/workspace-aufgaben.js
T
DogFatherGitandClaude Opus 5 ad47fc2b00 Team Dogi: Sternenfeld auf jeder Kachel, und die Sicht zeigt endlich, was sie verspricht
DER GRUND JEDER KACHEL IM HAUS VON TEAM DOGI

Filipe: "ich will dass die hintergrunde von den kacheln immer unviersum
artig ist, es muss richtig geil sein aber immer so dass man alles noch
gut erkkent. und das IN DER GANZEN WEBSITE VON TEAM DOGI. nur die
kacheln. [...] wichtig ist die form der kacheln soll gleich bleiben."

module.css hat eine kanonische KACHELLISTE -- 48 Klassen, siebenmal in
der Datei, von pruef-css-klassen gegeneinander gehalten. Eine achte
Abschrift in crew-haus.css waere die Sorte Fehler, die nicht auffaellt:
heute vollstaendig, bei der naechsten neuen Kachel lautlos nicht mehr.
Deshalb faerbt crew-haus.css keine einzige Kachel. module.css baut den
Grund jetzt aus vier Werten (--sternenfeld, -mass, -lage,
--modul-schleier), und das zweite Haus setzt nur diese vier um. Damit
hat jede Kachel der ganzen Adresse den Himmel -- auch die, die es noch
nicht gibt. Im Agenturhaus steht `none`: kein Pixel aendert sich.

ZWEI DINGE HAT ERST DIE MESSUNG GEFUNDEN, NICHT DAS NACHDENKEN:

1. Die Nebel standen zuerst oben links. Dort ist aber JEDE Kachel dieses
   Hauses schon von sich aus am hellsten -- ihr eigener Lichtverlauf
   laeuft bei allen aus derselben Richtung (155/150/158 Grad) --, und
   genau dort stehen ueberall die Ueberschriften. Hinter der leisesten
   Textzeile lagen dadurch 2,09 % der Bildpunkte unter 4,5:1; im
   Agenturhaus sind es an derselben Stelle 0,115 %. Nach dem Umzug in
   die beiden gegenueberliegenden Ecken: 0,22 % -- und der Nebel durfte
   dabei KRAEFTIGER werden (.80 statt .62), weil er nicht mehr auf dem
   hellsten Punkt liegt. Besser lesbar und deutlicher zu sehen; das ist
   selten und war hier umsonst zu haben.

2. Kleinere, dafuer hellere Sternkerne waren der falsche Weg: Der
   hellste Punkt blieb fast gleich, der Stern wurde nur unschaerfer.
   Entschieden hat die Deckkraft, nicht die Groesse.

Form unangetastet: Fase, Silhouette und die drei Eckwinkel werden vor
und nach dem Hauswechsel Zeichen fuer Zeichen verglichen.

pruef-kachel-universum.mjs (NEU, 37 Pruefungen, Port 4391) misst an
echten Bildpunkten und fragt nicht nach Durchschnitt allein, sondern
nach dem ANTEIL der Punkte unter 4,5:1 -- das unterscheidet einen Punkt
von einer Flaeche. Zwei Gegenproben: ein zu dunkler Text UND ein zu
heller Nebel muessen durchfallen.

MEINE SICHT -- "GENAU SO WIE SIE ES SEHEN"

Filipe: "oben bei meine sicht soll ich auch die sicht von allen jeden
moment sehen koennen und das genau genau so wie sie es sehen alles.
ausser die kalender daten oder chat daten wo ich nicht mit drin bin.."

Gemessen wurde nicht "mit Umschalter gegen ohne" -- das ist bei duenner
Datenlage ueberall gleich und beweist nichts. Gemessen wurde die
Antwort mit Umschalter gegen die Antwort, die die Person SELBST bekommt.
Das hat sechs Stellen gefunden:

* workspace-zentrale.js las `req.person.sicht` -- ein Feld, das es nicht
  gibt. Der Ausdruck war immer `undefined || req.person`, daneben ein
  ausfuehrlicher Kommentar, der genau das Richtige beschrieb. Die grosse
  Kachel zeigte verlaesslich die eigene Lage, waehrend die Zahlen
  darunter der fremden folgten -- zwei Wahrheiten in einer Kachel. Ein
  Tippfehler in einem Variablennamen macht nichts kaputt; er tut nur
  nichts, und genau deshalb faellt so etwas nie von selbst auf. Die
  Route hatte ausserdem ZWEI Personenvariablen; jetzt hat sie eine.
* sichtPerson() gab die angesehene Person ohne Feld `haus` zurueck --
  und nurHaus()/hausBedingung() fangen beide mit `haus !== "crew"` an.
  Jede fremde Sicht war damit eine Agentursicht: In der Sicht auf einen
  Modi kamen die Dateien, Personen und Berichte des anderen Hauses.
  Das Haus haengt jetzt an der ROLLE, nicht an der Adresse.
* leistung, profil, schulung, fruehwarnung, report und teamlage lasen
  weiterhin den Angemeldeten. Nur LESEN ist umgestellt, nie ein Recht --
  und weil DogFather ohnehin alles sehen darf, kann das nichts oeffnen,
  nur weniger zeigen.

Der Sicht-Umschalter zeichnete ausserdem nur die fuenf Rollen aus
bereiche.js; wer eine sechste hat, stand nicht darin. Dieselbe Luecke
wie in der Chat-Auswahl und der Personenliste, zum dritten Mal. Die
Ueberschrift kommt jetzt vom Server (`gruppe`), der Browser zeichnet,
was ankommt -- auch eine Rolle, deren Namen er nicht kennen darf.

DREI STELLEN FOLGEN BEWUSST NICHT: die Personenliste (aus ihr wird der
Umschalter gebaut -- folgte sie der Sicht, kaeme man aus einer fremden
nicht mehr heraus), die Auswahllisten beim Anlegen (Kategorien,
Empfaenger) und steckbrief/mein (ein Formular, das fremd liest und
eigen speichert, zerstoert Daten).

KALENDER UND CHAT BLEIBEN PRIVAT, auch mit Umschalter -- Termine,
Calls und Wiederholungen lesen ab jetzt immer die eigene Person. Eine
Pruefung musste dafuer umgedreht werden: pruef-sicht verlangte bis
heute das Gegenteil ("dafuer gibt es den Umschalter"). Die Gegenprobe
bleibt dieselbe Frage, nur andersherum -- Patrick selbst MUSS seine
Termine sehen, sonst hiesse "DogFather sieht sie nicht" nur, dass sie
niemand sieht. Dabei fiel auf, dass die Managerin gar keinen Call
hatte: Die Pruefung "bleibt privat" war nicht bestanden, sondern nicht
durchfuehrbar. Antwort darauf sind Daten, keine weichere Bedingung.

Gruen: pruef-sicht 84 (vorher 53), pruef-kachel-universum 37 (neu),
pruef-rollen 282, pruef-crew-adresse 129, pruef-start-ansicht 143,
pruef-kalender 104, pruef-haus-trennung 62, pruef-team-ampel 32,
pruef-team-stufen 26, pruef-css-klassen. Stempel 202609110209.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-11 02:10:15 +02:00

889 lines
40 KiB
JavaScript

/* =====================================================================
workspace-aufgaben.js — Aufgaben und Dashboard-Zahlen für /workspace.
Kernpunkt dieses Moduls ist die Datentrennung aus dem Konzept:
"Creator sehen ihren Bereich. Scouts sehen nur ihre Pipeline."
Sie wird AUSSCHLIESSLICH serverseitig durchgesetzt -- in jeder Abfrage,
nicht im Browser. Ein manipulierter Aufruf bekommt dadurch keine
fremden Daten, egal was er behauptet.
===================================================================== */
import express from "express";
import {
db, protokolliere, echteIp, sitzungLesen, betreutWo, istLeitung, ohneDogFather, heuteLokal, ROLLEN_SORTIERUNG, ROLLEN_GRUPPE, betreuteIds,
externPruefen, externSql, sichtbarePersonenIds, sichtbareCreatorIds,
MODI_KATEGORIEN, kategorienFuer, kategoriePersonen,
ohneTeamDogi, ohneAgentur, siehtModis, TEAM_DOGI_ROLLEN,
} from "./workspace.js";
export const aufgabenRouter = express.Router();
const STATUS = ["offen", "arbeit", "review", "erledigt"];
const PRIORITAETEN = ["hoch", "mittel", "niedrig"];
const TITEL_MAX = 160;
const TEXT_MAX = 4000;
const jetzt = () => new Date().toISOString();
/* ---------- Schranke ---------------------------------------------------- */
function angemeldet(req, res, next) {
const person = sitzungLesen(req);
if (!person) return res.status(401).json({ fehler: "nicht_angemeldet" });
req.person = person;
next();
}
/* Schutz gegen Anfragen von fremden Seiten. SameSite=lax verhindert das
meiste schon, aber nur solange sich der Browser daran hält. Bei allem,
was Daten verändert, wird zusätzlich geprüft, dass die Anfrage von
dieser Domain kommt. Fehlt der Kopf ganz (z. B. bei curl), ist es kein
Browser-Angriff über eine fremde Seite -- dann zählt allein das Cookie. */
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();
}
aufgabenRouter.use("/workspace/api", angemeldet);
/* ---------- Sichtbarkeit ------------------------------------------------ */
/* =====================================================================
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.
===================================================================== */
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("a", ["creator_id", "verantwortlich_id", "erstellt_von"])}`,
werte: regel.werte,
};
}
if (siehtModis(person)) return regel;
return {
wo: `(${regel.wo}) AND ${ohneTeamDogi("a", ["creator_id", "verantwortlich_id", "erstellt_von"])}`,
werte: regel.werte,
};
}
/* Liefert WHERE-Bedingung und Werte, passend zur Rolle. An genau einer
Stelle definiert, damit keine Abfrage sie versehentlich vergisst. */
function sichtbarRoh(person) {
switch (person.rolle) {
/* NUR DogFather sieht alles. Ausdruecklich so gewuenscht
(01.09.2026) -- und ausdruecklich NUR er. */
case "admin":
return { wo: "1=1", werte: [] };
/* SPICY MEDIA sieht alles ausser dem, was DogFather gehoert
(07.09.2026). Die Bedingung kommt aus workspace.js -- eine
abgeschriebene Fassung waere die Stelle, an der es beim naechsten
Umbau wieder durchsickert. */
case "spicy":
return { wo: ohneDogFather("a", ["creator_id", "verantwortlich_id", "erstellt_von"]),
werte: [] };
case "creator":
return {
wo: "(a.creator_id = ? OR a.verantwortlich_id = ? OR a.erstellt_von = ?)",
werte: [person.id, person.id, person.id],
};
/* MANAGER STAND HIER BIS ZUM 01.09.2026 NICHT -- er fiel in den
Default und sah damit auf dem Aufgabenbrett GAR NICHTS. Ein
leeres Brett sieht aus wie "nichts zu tun", nicht wie ein Fehler;
deshalb ist das vermutlich lange niemandem aufgefallen.
Jetzt gilt fuer ihn dieselbe Regel wie fuer einen Scout: eigene
Aufgaben plus die der Creator, die er betreut. Das ist genau das
Gewuenschte -- "nur ihre zugeteilten Aufgaben von ihren Creator". */
/* "ODER ich habe sie selbst angelegt" kam am 02.09.2026 dazu, und es
war ein echter Fehler, dass es fehlte.
Legte eine Managerin eine Aufgabe an und liess das Feld "Creator"
auf "—" (oder trug seit heute einen freien Namen ein), war
creator_id leer und verantwortlich_id ebenfalls. Damit traf KEINE
der beiden Bedingungen zu: Die Aufgabe verschwand in dem Moment,
in dem sie gespeichert wurde -- nur DogFather sah sie noch. Kein
Fehler, keine Meldung, die Aufgabe war einfach weg.
Es bleibt dabei, dass nur DogFather ALLES sieht. Hier kommt
niemand an etwas Fremdes heran -- nur an das, was er selbst
geschrieben hat. */
case "scout":
case "manager": {
const eigen = "(a.verantwortlich_id = ? OR a.erstellt_von = ?)";
const b = betreutWo(person, "a.creator_id");
return b
? { wo: `(${eigen} OR ${b.wo})`, werte: [person.id, person.id, ...b.werte] }
: { wo: eigen, werte: [person.id, person.id] };
}
/* =================================================================
MODI (10.09.2026) -- UND FAST WAERE DERSELBE FEHLER PASSIERT WIE
AM 01.09.2026 BEIM MANAGER.
Er stand hier nicht, fiel in den Default und sah damit auf dem
Aufgabenbrett GAR NICHTS -- eigene Aufgaben eingeschlossen. Und
wie der Kommentar oben schon sagt: Ein leeres Brett sieht aus wie
"nichts zu tun", nicht wie ein Fehler. Der Rollen-Rundgang
(pruef-rollen) meldete fuer den Modi brav "aufgaben.html ok",
denn die Seite laedt ja, sie ist nur leer. Gefunden hat es erst
eine Pruefung, die eine Aufgabe ANLEGT und sie danach
wiederzufinden versucht.
WAS ER SIEHT: die Aufgaben des ganzen Modi-Teams. Filipes
Entscheidung vom 09.09.2026 -- "ja, sie sind untereinander ein
Team". Ohne das koennte niemand eine Schicht tauschen oder eine
Eskalation weiterreichen, ohne dass DogFather sie einzeln
durchstellt.
AENDERN DARF ER TROTZDEM NUR SEINE EIGENEN. Das entscheidet
darfAendern() weiter unten, und es bleibt dabei: Sehen, um sich
abzustimmen, ist etwas anderes als in fremder Arbeit schreiben.
WARUM DIE NUMMERN FRISCH GELESEN WERDEN und nicht einmal beim
Start: Kommt ein Modi dazu, muessen ihn die anderen sofort sehen.
Eine Liste, die beim Serverstart entsteht, waere bis zum naechsten
Neustart falsch -- und niemand wuesste, warum. */
/* BEIDE ROLLEN DES TEAMS TEILEN SICH DIESE SICHT (10.09.2026).
Die rechte Hand soll laut Blueprint 3.1 "gleichen Ueberblick wie
Owner" haben. Innerhalb des Teams heisst das: dieselbe Sicht wie
ein Modi -- alle Aufgaben des Teams, nicht nur die eigenen. Der
Unterschied zwischen ihr und einem Modi liegt woanders (Eingang,
Entscheidungen), nicht hier.
`case` ohne `break` faellt in den naechsten -- genau das ist hier
gewollt und der kuerzeste ehrliche Weg, "diese beiden gleich" zu
sagen. */
case "hand":
case "modi": {
const liste = [...TEAM_DOGI_ROLLEN].map((r) => `'${r}'`).join(", ");
const modis = db().prepare(
`SELECT id FROM personen WHERE rolle IN (${liste})`).all().map((z) => z.id);
/* Kann nicht leer sein -- diese Person gehoert selbst dazu. Die
Abfrage faende sonst `IN ()`, und das ist in SQLite ein
Syntaxfehler. */
if (!modis.length) return { wo: "a.verantwortlich_id = ?", werte: [person.id] };
const platz = modis.map(() => "?").join(",");
return {
wo: `(a.creator_id IN (${platz}) OR a.verantwortlich_id IN (${platz})`
+ ` OR a.erstellt_von IN (${platz}))`,
werte: [...modis, ...modis, ...modis],
};
}
default:
return { wo: "0=1", werte: [] }; // unbekannte Rolle sieht nichts
}
}
function darfAendern(person, aufgabe) {
if (istLeitung(person)) return true;
return aufgabe.creator_id === person.id || aufgabe.verantwortlich_id === person.id;
}
const SPALTEN = `
a.id, a.titel, a.beschreibung, a.status, a.prioritaet, a.frist,
a.creator_id, a.verantwortlich_id, a.erstellt, a.geaendert, a.erledigt_am,
a.creator_extern, a.verantwortlich_extern,
${externSql("pc.name", "a.creator_extern")} AS creator_name,
${externSql("pv.name", "a.verantwortlich_extern")} AS verantwortlich_name,
/* Abbruch (05.09.2026). Der Grund gehört mit in die Liste, nicht
hinter einen zweiten Aufruf: Wer den Bereich aufklappt, will genau
das lesen -- ein Nachladen je Zeile wäre bei zwanzig abgebrochenen
Aufgaben zwanzig Anfragen. */
a.abbruch_grund, a.abgebrochen_am, a.status_vorher,
/* Die Vorlage, aus der sie entstanden ist (09.09.2026) -- damit das
Vorlagenbrett zeigen kann, was schon geholt wurde. */
a.vorlage,
/* Die Kategorie (10.09.2026, Kapitel 6.1 des Anforderungsdokuments).
Sie kommt fuer JEDE Aufgabe mit -- wer sie nicht benutzen darf,
hat ohnehin keine Aufgabe mit einem Wert darin. Sie hier je nach
Rolle wegzulassen waere eine zweite Sichtbarkeitsregel neben der,
die es schon gibt, und damit eine zweite Gelegenheit, sie falsch
zu ziehen. */
a.kategorie,
pa.name AS abbruch_von_name`;
const VERBUND = `
FROM aufgaben a
LEFT JOIN personen pc ON pc.id = a.creator_id
LEFT JOIN personen pv ON pv.id = a.verantwortlich_id
LEFT JOIN personen pa ON pa.id = a.abbruch_von`;
/* ---------- Lesen ------------------------------------------------------- */
aufgabenRouter.get("/workspace/api/aufgaben", (req, res) => {
try {
const { wo, werte } = sichtbar(req.sicht || req.person);
const reihen = db().prepare(`
SELECT ${SPALTEN},
(SELECT COUNT(*) FROM aufgaben_notizen n WHERE n.aufgabe_id = a.id) AS notizen
${VERBUND}
WHERE ${wo}
/* DRINGEND SCHLAEGT WICHTIG (09.09.2026).
Hier stand die Prioritaet an erster Stelle. Folge auf dem
Brett: Eine seit drei Tagen ueberfaellige Aufgabe mit
Prioritaet "mittel" stand UNTER einer, die als "hoch"
eingetragen ist und erst in drei Wochen faellig wird. Wer die
Spalte von oben liest, faengt dann mit dem Falschen an.
Eine Prioritaet ist eine Einschaetzung von damals, eine
ueberschrittene Frist ist eine Tatsache von heute. Deshalb:
erst was faellig ist, dann nach Datum, und die Prioritaet
entscheidet nur noch bei gleichem Datum.
Die Sortierung steht hier und nicht im Browser: Die Startseite
und die Uebersicht lesen dieselbe Liste, und zwei Sortierungen
fuer dieselbe Frage laufen auseinander. */
ORDER BY
CASE WHEN a.status <> 'erledigt' AND a.frist IS NOT NULL AND a.frist < ?
THEN 0 ELSE 1 END,
CASE WHEN a.frist IS NULL THEN 1 ELSE 0 END, a.frist,
CASE a.prioritaet WHEN 'hoch' THEN 0 WHEN 'mittel' THEN 1 ELSE 2 END,
a.id DESC`).all(...werte, heuteLokal());
res.json({
aufgaben: reihen,
/* Die Kategorien kommen mit der Liste, nicht ueber einen eigenen
Aufruf: Das Brett braucht beides im selben Augenblick, und ein
zweiter Aufruf waere ein zweiter Weg, der einzeln scheitern
kann. Wer sie nicht benutzen darf, bekommt eine leere Liste --
und die Oberflaeche zeigt dann gar kein Feld. */
kategorien: kategorienFuer(req.person),
/* Fuer wessen Aufgaben sie gilt -- als Nummern, nicht als
Rollenname. Im Browser darf nichts stehen, woraus sich auf eine
verborgene Rolle schliessen laesst. */
/* Die Kategorien bleiben beim Angemeldeten: Sie entscheiden,
WOHIN geschrieben werden darf, nicht was zu sehen ist. Wer in
fremder Sicht eine Aufgabe anlegt, legt sie als er selbst an --
eine Auswahl aus fremden Kategorien waere ein Angebot, das der
Server danach ablehnt. */
kategorie_fuer: kategoriePersonen(req.person),
});
} catch (fehler) {
console.error("[workspace] Aufgaben lesen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
aufgabenRouter.get("/workspace/api/uebersicht", (req, res) => {
try {
const { wo, werte } = sichtbar(req.sicht || req.person);
const zaehle = (zusatz, extra = []) => db()
.prepare(`SELECT COUNT(*) AS n ${VERBUND} WHERE ${wo}${zusatz}`)
.get(...werte, ...extra).n;
const heute = jetzt().slice(0, 10);
/* ABGEBROCHENE SIND NICHT "NOCH ZU TUN" (08.09.2026).
Filipe, screen12: "die abgebrochenen sollen oben nicht mehr mit
zählen die sollen ihre eigenen kategorie kriegen".
Hier stand nur "ungleich erledigt", und das war der Fehler: Eine
abgebrochene Aufgabe ist zwar nicht "erledigt", aber eben auch
nicht offen. Sie fiel damit in BEIDE Zahlen oben -- eine Aufgabe,
die niemand mehr anfassen wird, mahnte weiter als überfällig.
DERSELBE FEHLER STAND AN ZWÖLF STELLEN in sieben Dateien, nicht
nur hier. Am schwersten wog `workspace-push.js`: Dort werden
Erinnerungen VERSCHICKT -- für Aufgaben, die längst abgebrochen
waren. Filipe hat eine Stelle gesehen; gesucht werden musste nach
dem Muster, nicht nach dem Symptom.
Das ist die Kehrseite einer bewussten Entscheidung weiter unten in
dieser Datei: "abgebrochen" steht absichtlich NICHT in STATUS,
damit der normale Weg es nicht setzen kann. Genau deshalb rutscht
es aber durch jede Bedingung, die nur gegen 'erledigt' prüft --
und davon gab es hier zwei.
`NOT IN` statt einer zweiten Ungleichung: Wer später einen dritten
Endzustand einführt, ergänzt eine Liste, statt eine Kette von
`<>` zu verlängern, bei der das Vergessen niemandem auffällt. */
const ERLEDIGT_ODER_WEG = " AND a.status NOT IN ('erledigt', 'abgebrochen')";
res.json({
offen: zaehle(" AND a.status = 'offen'"),
arbeit: zaehle(" AND a.status = 'arbeit'"),
review: zaehle(" AND a.status = 'review'"),
erledigt: zaehle(" AND a.status = 'erledigt'"),
/* Die eigene Kategorie, die Filipe verlangt hat. Sie steht bei den
abgeschlossenen, nicht bei den offenen -- die Aufgabe ist vom
Tisch, nur eben anders als durch Erledigen. */
abgebrochen: zaehle(" AND a.status = 'abgebrochen'"),
/* Überfällig = Frist vorbei und noch offen. Genau die Zahl,
die das Konzept auf dem Dashboard sehen will. */
ueberfaellig: zaehle(ERLEDIGT_ODER_WEG + " AND a.frist IS NOT NULL AND a.frist < ?", [heute]),
heute: zaehle(ERLEDIGT_ODER_WEG + " AND a.frist = ?", [heute]),
});
} catch (fehler) {
console.error("[workspace] Übersicht:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* Für die Zuweisung: wen darf ich überhaupt eintragen? Scouts bekommen
die Liste bewusst nicht -- sie sollen keine fremden Namen sehen. */
aufgabenRouter.get("/workspace/api/personen", (req, res) => {
try {
/* Nicht die ROLLE, sondern die ZUTEILUNG entscheidet (03.09.2026).
Hier stand eine Abfrage ueber ALLE -- eine Managerin bekam damit
auch Namen und Daten von Creators, die ihr nie zugeteilt waren.
sichtbarePersonenIds/sichtbareCreatorIds liefern null fuer
DogFather (= keine Einschraenkung) und sonst genau die erlaubten
Nummern. */
/* DAS BILD GEHOERT DAZU (07.09.2026, Wunsch Filipe: "jeder soll auch
immer das profilbild von denen sehen mit denen sie verbunden
sind").
Diese Liste lieferte bisher `id, name, rolle` -- und deshalb
konnte KEINE Oberflaeche ein Gesicht zeigen, auch wenn eines
hochgeladen war. Der Fehler lag nicht in der Anzeige, sondern
hier: Was nicht mitkommt, kann niemand zeichnen.
Ausgeliefert wird die fertige ADRESSE, nicht der Dateiname. Sonst
muesste jede Stelle im Browser denselben Pfad zusammensetzen --
und beim naechsten Umzug des Ordners waere er an sechs Stellen
falsch. Wer kein Bild hat, bekommt `null`; die Oberflaeche zeigt
dann wie bisher den Anfangsbuchstaben. */
/* DIE UEBERSCHRIFT KOMMT MIT (11.09.2026, dritter Fall derselben
Luecke).
Der Browser gruppiert Personenlisten nach der Rollenfolge aus
bereiche.js -- und wer dort nicht steht, wird nicht gezeichnet.
Das ist jetzt zum dritten Mal aufgefallen: in der Chat-Auswahl,
in der Personenliste, und hier im Sicht-Umschalter. DogFather
konnte die Sicht seines Teams nicht waehlen, weil das Team in
der Auswahl gar nicht vorkam.
Die Rollennamen duerfen dort nicht stehen (sie gehoeren in keine
Datei, die jeder herunterlaedt) -- also schickt der Server einen
TEXT mit, und der Browser zeichnet, was ankommt. */
const mitBild = (z) => ({
id: z.id, name: z.name, rolle: z.rolle,
gruppe: ROLLEN_GRUPPE[z.rolle] || "Weitere",
bild: z.bild ? `/workspace/api/steckbrief/bild/${z.bild}` : null,
});
const ids = sichtbarePersonenIds(req.person);
if (ids === null) {
return res.json({
personen: db().prepare(
"SELECT id, name, rolle, bild FROM personen WHERE aktiv = 1 ORDER BY "
+ ROLLEN_SORTIERUNG + ", name").all().map(mitBild),
});
}
if (!ids.length) {
return res.json({ personen: [{ id: req.person.id, name: req.person.name,
rolle: req.person.rolle, gruppe: ROLLEN_GRUPPE[req.person.rolle] || "Weitere",
bild: null }] });
}
res.json({
personen: db().prepare(
`SELECT id, name, rolle, bild FROM personen WHERE aktiv = 1
AND id IN (${ids.map(() => "?").join(",")})
ORDER BY ` + ROLLEN_SORTIERUNG + ", name").all(...ids).map(mitBild),
});
} catch {
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* ---------- Anlegen und Ändern ------------------------------------------ */
const KATEGORIEN = new Set(MODI_KATEGORIEN.map((k) => k.wert));
function pruefeFelder(körper, { neu, person }) {
const fehler = [];
const aus = {};
if (neu || körper.titel !== undefined) {
const titel = String(körper.titel ?? "").trim();
if (titel.length < 2) fehler.push("Titel fehlt.");
else if (titel.length > TITEL_MAX) fehler.push(`Titel ist länger als ${TITEL_MAX} Zeichen.`);
else aus.titel = titel;
}
if (körper.beschreibung !== undefined) {
const t = String(körper.beschreibung ?? "").trim();
if (t.length > TEXT_MAX) fehler.push("Beschreibung ist zu lang.");
else aus.beschreibung = t || null;
}
if (körper.status !== undefined) {
if (!STATUS.includes(körper.status)) fehler.push("Unbekannter Status.");
else aus.status = körper.status;
}
if (körper.prioritaet !== undefined) {
if (!PRIORITAETEN.includes(körper.prioritaet)) fehler.push("Unbekannte Priorität.");
else aus.prioritaet = körper.prioritaet;
}
if (körper.frist !== undefined) {
const f = String(körper.frist ?? "").trim();
if (!f) aus.frist = null;
else if (!/^\d{4}-\d{2}-\d{2}$/.test(f) || Number.isNaN(Date.parse(f))) fehler.push("Frist ist kein gültiges Datum.");
else aus.frist = f;
}
for (const feld of ["creator_id", "verantwortlich_id"]) {
if (körper[feld] === undefined) continue;
const wert = körper[feld];
if (wert === null || wert === "") { aus[feld] = null; continue; }
const zahl = Number(wert);
if (!Number.isInteger(zahl) || zahl < 1) fehler.push("Ungültige Zuordnung.");
else aus[feld] = zahl;
}
/* DIE KATEGORIE (10.09.2026).
STILLSCHWEIGEND FALLEN GELASSEN, NICHT ABGELEHNT, wenn jemand sie
schickt, der sie nicht benutzen darf. Eine Fehlermeldung
("Unbekannte Kategorie") waere die Auskunft, dass es das Feld gibt
-- und genau die soll niemand bekommen. Wer sie benutzen darf,
bekommt bei einem falschen Wert dagegen sehr wohl eine Absage:
Fuer ihn ist ein Tippfehler ein Fehler und kein Geheimnis.
Leer heisst ausdruecklich `null` und nicht "unveraendert" -- sonst
liesse sich eine einmal gesetzte Kategorie nie wieder entfernen. */
if (körper.kategorie !== undefined && kategorienFuer(person).length) {
const k = String(körper.kategorie ?? "").trim();
if (!k) aus.kategorie = null;
else if (!KATEGORIEN.has(k)) fehler.push("Unbekannte Kategorie.");
else aus.kategorie = k;
}
/* Frei eingetragene Namen statt einer Person -- eine Agentur, eine
Marke, jemand ohne Konto. Sie schlagen die Auswahl: Wer tippt,
meint das Getippte, und die Verknuepfung faellt weg. */
externPruefen(körper, aus, "creator", fehler);
externPruefen(körper, aus, "verantwortlich", fehler);
return { aus, fehler };
}
/* ---------- Gesamtuebersicht ----------------------------------------------
"Die Admin-Rolle behaelt den Gesamtueberblick" (Konzept, Seite 2) und
"UEBERSICHT -- alles zentral" (Seite 1). Genau das fehlte: eine
Ansicht, die JE CREATOR zeigt, wie es steht, statt nur die eigenen
Zahlen.
Fuehrt keine eigenen Daten -- alles kommt aus Aufgaben, Terminen,
Bereichen, Profil und Start-Check. Wer welchen Creator sieht, richtet
sich nach derselben Betreuungsregel wie ueberall. */
aufgabenRouter.get("/workspace/api/uebersicht/creator", (req, res) => {
try {
const person = req.person;
let wo = "p.rolle = 'creator' AND p.aktiv = 1";
let werte = [];
/* Zuteilung statt Rolle (03.09.2026): Ein Manager fiel hier durch
beide Zweige hindurch und bekam die Gesamtuebersicht ueber ALLE
Creator -- mit Namen, offenen Aufgaben, Terminen und dem Stand
ihres Start-Checks. sichtbareCreatorIds gibt allein DogFather
null (= keine Einschraenkung). */
const erlaubt = sichtbareCreatorIds(person);
if (erlaubt !== null) {
if (!erlaubt.length) return res.json({ creator: [], eigen: person.rolle === "creator" });
wo += ` AND p.id IN (${erlaubt.map(() => "?").join(",")})`;
werte = erlaubt;
}
/* ORTSZEIT: toISOString() liefert UTC und damit nachts den Vortag --
eine heute faellige Aufgabe galt dann noch nicht als faellig. */
const heute = heuteLokal();
const jetztIso = new Date().toISOString();
const liste = db().prepare(`
SELECT p.id, p.name, p.letzter_login,
(SELECT name FROM personen b
WHERE b.id = (SELECT betreuer_id FROM betreuung WHERE creator_id = p.id)) AS betreuer,
(SELECT COUNT(*) FROM aufgaben a
WHERE a.creator_id = p.id AND a.status = 'offen') AS offen,
(SELECT COUNT(*) FROM aufgaben a
WHERE a.creator_id = p.id AND a.status = 'arbeit') AS arbeit,
(SELECT COUNT(*) FROM aufgaben a
WHERE a.creator_id = p.id AND a.status = 'review') AS review,
(SELECT COUNT(*) FROM aufgaben a
WHERE a.creator_id = p.id AND a.status NOT IN ('erledigt', 'abgebrochen')
AND a.frist IS NOT NULL AND a.frist < ?) AS ueberfaellig,
(SELECT COUNT(*) FROM aufgaben a
WHERE a.creator_id = p.id AND a.erledigt_am IS NOT NULL
AND a.erledigt_am >= ?) AS erledigt30,
(SELECT COUNT(*) FROM eintraege e
WHERE e.creator_id = p.id AND e.status = 'offen'
AND e.dringlichkeit = 'hoch') AS dringend,
(SELECT MIN(t.beginn) FROM termine t
WHERE (t.creator_id = p.id OR t.teilnehmer_id = p.id)
AND t.beginn >= ? AND t.erledigt = 0) AS naechster_termin,
(SELECT COUNT(*) FROM startcheck s
WHERE s.creator_id = p.id AND s.bewertung IS NOT NULL) AS check_geprueft,
(SELECT COUNT(*) FROM startcheck s
WHERE s.creator_id = p.id AND s.bewertung = 'handlung') AS check_handlung,
(SELECT naechster_review FROM profile f WHERE f.person_id = p.id) AS naechster_review,
(SELECT COUNT(*) FROM profile f WHERE f.person_id = p.id) AS hat_profil
FROM personen p
WHERE ${wo}
ORDER BY p.name`).all(
heute, new Date(Date.now() - 30 * 86400_000).toISOString(),
heute + "T00:00", ...werte);
/* Der Review-Termin ist Steuerungswissen -- ein Creator sieht ihn in
seinem Profil auch nicht, also hier ebenso wenig. */
if (!istLeitung(person)) for (const c of liste) delete c.naechster_review;
res.json({
creator: liste,
eigen: person.rolle === "creator",
check_gesamt: 16,
stand: jetztIso,
});
} catch (fehler) {
console.error("[workspace] Gesamtuebersicht:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* ---------- Rueckmeldungen ("Aufgaben & Feedback") ------------------------
Wer die Aufgabe sieht, darf mitreden. Geprueft wird das ueber dieselbe
Sichtbarkeitsregel wie fuer die Aufgabe selbst -- eine zweite Regel
waere eine zweite Stelle, an der es irgendwann auseinanderlaeuft.
404 statt 403, wenn die Aufgabe nicht sichtbar ist: Wer sie nicht
sehen darf, soll auch nicht erfahren, dass es sie gibt. */
const NOTIZ_MAX = 2000;
function aufgabeSichtbar(person, id) {
const { wo, werte } = sichtbar(person);
return db().prepare(`SELECT a.id FROM aufgaben a WHERE ${wo} AND a.id = ?`).get(...werte, id);
}
aufgabenRouter.get("/workspace/api/aufgaben/:id/notizen", (req, res) => {
try {
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
if (!aufgabeSichtbar(req.person, id)) return res.status(404).json({ fehler: "nicht_gefunden" });
res.json({
notizen: db().prepare(`
SELECT n.id, n.text, n.erstellt, n.person_id, p.name AS von, p.rolle AS rolle
FROM aufgaben_notizen n LEFT JOIN personen p ON p.id = n.person_id
WHERE n.aufgabe_id = ? ORDER BY n.id`).all(id),
ich: req.person.id,
darf_alles_loeschen: istLeitung(req.person),
});
} catch (fehler) {
console.error("[workspace] Notizen lesen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
aufgabenRouter.post("/workspace/api/aufgaben/:id/notizen", gleicheHerkunft, (req, res) => {
try {
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
if (!aufgabeSichtbar(req.person, id)) return res.status(404).json({ fehler: "nicht_gefunden" });
const text = String(req.body?.text ?? "").trim().slice(0, NOTIZ_MAX);
if (text.length < 2) return res.status(400).json({ fehler: "Schreib erst etwas." });
const { lastInsertRowid } = db().prepare(
"INSERT INTO aufgaben_notizen (aufgabe_id, person_id, text, erstellt) VALUES (?,?,?,?)")
.run(id, req.person.id, text, jetzt());
protokolliere("aufgabe_notiz", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `Aufgabe #${id}`.slice(0, 120),
});
res.status(201).json({ id: Number(lastInsertRowid) });
} catch (fehler) {
console.error("[workspace] Notiz schreiben:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
aufgabenRouter.delete("/workspace/api/notizen/:id", gleicheHerkunft, (req, res) => {
try {
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
const notiz = db().prepare(
"SELECT id, aufgabe_id, person_id FROM aufgaben_notizen WHERE id = ?").get(id);
if (!notiz) return res.status(404).json({ fehler: "nicht_gefunden" });
if (!aufgabeSichtbar(req.person, notiz.aufgabe_id)) {
return res.status(404).json({ fehler: "nicht_gefunden" });
}
/* Die eigene Rueckmeldung darf jeder zuruecknehmen, fremde nur die
Leitung. Eine Rueckmeldung ist keine Abstimmung -- wer sich
vertippt hat, soll das nicht bei jemandem beantragen muessen. */
if (notiz.person_id !== req.person.id && !istLeitung(req.person)) {
return res.status(403).json({ fehler: "Fremde Rückmeldungen löscht nur die Leitung." });
}
db().prepare("DELETE FROM aufgaben_notizen WHERE id = ?").run(id);
protokolliere("aufgabe_notiz_geloescht", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `#${id} zu Aufgabe #${notiz.aufgabe_id}`.slice(0, 120),
});
res.json({ ok: true });
} catch (fehler) {
console.error("[workspace] Notiz löschen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
aufgabenRouter.post("/workspace/api/aufgaben", gleicheHerkunft, (req, res) => {
try {
const { aus, fehler } = pruefeFelder(req.body || {}, { neu: true, person: req.person });
if (fehler.length) return res.status(400).json({ fehler: fehler.join(" ") });
/* Wer nicht Management ist, darf ausschließlich für sich selbst
anlegen -- egal, was im Aufruf steht. */
if (!istLeitung(req.person)) {
aus.creator_id = req.person.rolle === "creator" ? req.person.id : null;
aus.verantwortlich_id = req.person.id;
}
for (const feld of ["creator_id", "verantwortlich_id"]) {
if (aus[feld] && !db().prepare("SELECT 1 FROM personen WHERE id = ? AND aktiv = 1").get(aus[feld])) {
return res.status(400).json({ fehler: "Zugeordnete Person gibt es nicht." });
}
}
const { lastInsertRowid } = db().prepare(`
INSERT INTO aufgaben
(titel, beschreibung, status, prioritaet, creator_id, verantwortlich_id,
creator_extern, verantwortlich_extern, frist, kategorie, erstellt, erstellt_von)
VALUES (?,?,?,?,?,?,?,?,?,?,?,?)`).run(
aus.titel, aus.beschreibung ?? null, aus.status ?? "offen",
aus.prioritaet ?? "mittel", aus.creator_id ?? null, aus.verantwortlich_id ?? null,
aus.creator_extern ?? null, aus.verantwortlich_extern ?? null,
aus.frist ?? null, aus.kategorie ?? null, jetzt(), req.person.id);
protokolliere("aufgabe_angelegt", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `#${lastInsertRowid} ${aus.titel}`.slice(0, 120),
});
res.status(201).json({ id: Number(lastInsertRowid) });
} catch (fehler) {
console.error("[workspace] Aufgabe anlegen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
aufgabenRouter.patch("/workspace/api/aufgaben/:id", gleicheHerkunft, (req, res) => {
try {
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
/* Erst mit der Sichtbarkeitsregel holen: Was jemand nicht sehen darf,
existiert für ihn auch nicht -- deshalb 404 und nicht 403. Sonst
liesse sich durch Ausprobieren herausfinden, welche Nummern es gibt. */
const { wo, werte } = sichtbar(req.person);
const aufgabe = db().prepare(
`SELECT a.* ${VERBUND} WHERE ${wo} AND a.id = ?`).get(...werte, id);
if (!aufgabe) return res.status(404).json({ fehler: "nicht_gefunden" });
if (!darfAendern(req.person, aufgabe)) return res.status(403).json({ fehler: "nicht_erlaubt" });
const { aus, fehler } = pruefeFelder(req.body || {}, { neu: false, person: req.person });
if (fehler.length) return res.status(400).json({ fehler: fehler.join(" ") });
/* Zuordnungen darf nur das Management verschieben. */
if (!istLeitung(req.person)) { delete aus.creator_id; delete aus.verantwortlich_id; }
const felder = Object.keys(aus);
if (!felder.length) return res.status(400).json({ fehler: "nichts_zu_aendern" });
const setz = felder.map((f) => `${f} = ?`);
const daten = felder.map((f) => aus[f]);
setz.push("geaendert = ?"); daten.push(jetzt());
if (aus.status === "erledigt" && aufgabe.status !== "erledigt") {
setz.push("erledigt_am = ?"); daten.push(jetzt());
} else if (aus.status && aus.status !== "erledigt") {
setz.push("erledigt_am = NULL");
}
db().prepare(`UPDATE aufgaben SET ${setz.join(", ")} WHERE id = ?`).run(...daten, id);
protokolliere("aufgabe_geaendert", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `#${id} ${felder.join(",")}`.slice(0, 120),
});
res.json({ ok: true });
} catch (fehler) {
console.error("[workspace] Aufgabe ändern:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* ---------- Abbrechen ----------------------------------------------------
Wunsch Filipe, 05.09.2026: *"ich will dass man in jedem status die
aufgaben auch abbrechen kann. nur ich die manager und scouts sollen
auch die aufgaben abbrechen können."*
WARUM EIN EIGENER WEG und nicht einfach `status: "abgebrochen"` über
den PATCH oben: Dort entscheidet darfAendern() -- und das lässt auch
den zuständigen Creator ändern. Stünde "abgebrochen" bloss in der
STATUS-Liste, könnte ein Creator seine eigene Aufgabe abbrechen,
ohne dass es irgendwo auffällt. Die Rollenregel gehört an EINE
Stelle, an der man sie sieht.
Deshalb steht "abgebrochen" bewusst NICHT in STATUS: Der normale
Statuswechsel kann diesen Zustand gar nicht erreichen.
Der Grund ist Pflicht. Ohne ihn weiss in vier Wochen niemand mehr,
warum etwas wegfiel -- und dann ist es von Löschen nicht mehr zu
unterscheiden. */
/** Wer darf abbrechen? DogFather, Manager, Scouts -- Creator nicht. */
/* Spicy Media steht hier seit dem 07.09.2026 mit drin: Die Rolle hat
"die gleichen rechte wie dogfather ausser Automationen, Personen nur
anlegen, keine privaten Daten". Abbrechen gehoert nicht zu den
Ausnahmen -- sie fehlte hier nur, weil diese Liste beim Anlegen der
Rolle uebersehen wurde. Gefunden hat es keine Ueberlegung, sondern
eine Pruefung, die nach eigenen Rollenlisten sucht
(pruef-css-klassen.mjs). */
const DARF_ABBRECHEN = new Set(["spicy", "admin", "manager", "scout"]);
const ABBRUCH_GRUND_MAX = 500;
aufgabenRouter.post("/workspace/api/aufgaben/:id/abbrechen", gleicheHerkunft, (req, res) => {
try {
if (!DARF_ABBRECHEN.has(req.person.rolle)) {
return res.status(403).json({ fehler: "Nur DogFather, Spicy Media, Manager und Scouts können Aufgaben abbrechen." });
}
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
const grund = String(req.body?.grund ?? "").trim();
if (grund.length < 3) {
return res.status(400).json({ fehler: "Bitte kurz sagen, warum die Aufgabe abgebrochen wird." });
}
if (grund.length > ABBRUCH_GRUND_MAX) {
return res.status(400).json({ fehler: `Der Grund ist länger als ${ABBRUCH_GRUND_MAX} Zeichen.` });
}
/* Wie beim PATCH: erst durch die Sichtbarkeitsregel. Was jemand
nicht sehen darf, existiert für ihn nicht -- 404, nicht 403. */
const { wo, werte } = sichtbar(req.person);
const aufgabe = db().prepare(
`SELECT a.* ${VERBUND} WHERE ${wo} AND a.id = ?`).get(...werte, id);
if (!aufgabe) return res.status(404).json({ fehler: "nicht_gefunden" });
if (aufgabe.status === "abgebrochen") {
return res.status(409).json({ fehler: "Diese Aufgabe ist schon abgebrochen." });
}
/* status_vorher hält fest, WIE WEIT es war. "Im Review
abgebrochen" ist eine ganz andere Aussage als "nie angefangen"
-- und beim Wiederaufnehmen geht es genau dorthin zurück. */
db().prepare(`
UPDATE aufgaben
SET status = 'abgebrochen', status_vorher = ?, abbruch_grund = ?,
abgebrochen_am = ?, abbruch_von = ?, geaendert = ?, erledigt_am = NULL
WHERE id = ?`)
.run(aufgabe.status, grund, jetzt(), req.person.id, jetzt(), id);
protokolliere("aufgabe_abgebrochen", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `#${id} (${aufgabe.status}) ${grund}`.slice(0, 120),
});
res.json({ ok: true, status_vorher: aufgabe.status });
} catch (fehler) {
console.error("[workspace] Aufgabe abbrechen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/** Wieder aufnehmen. Geht zurück in den Status, in dem abgebrochen
* wurde -- nicht nach "offen". Wer eine Aufgabe im Review abbricht
* und wieder aufnimmt, will sie im Review zurück, nicht von vorn.
*
* Dieselbe Rollenregel: Wer abbrechen darf, darf auch zurücknehmen.
* Eine Handlung ohne Umkehr wäre hier falsch -- ein Abbruch aus
* Versehen soll niemanden zwingen, die Aufgabe neu zu schreiben. */
aufgabenRouter.post("/workspace/api/aufgaben/:id/wiederaufnehmen", gleicheHerkunft, (req, res) => {
try {
if (!DARF_ABBRECHEN.has(req.person.rolle)) {
return res.status(403).json({ fehler: "Nur DogFather, Manager und Scouts können das." });
}
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
const { wo, werte } = sichtbar(req.person);
const aufgabe = db().prepare(
`SELECT a.* ${VERBUND} WHERE ${wo} AND a.id = ?`).get(...werte, id);
if (!aufgabe) return res.status(404).json({ fehler: "nicht_gefunden" });
if (aufgabe.status !== "abgebrochen") {
return res.status(409).json({ fehler: "Diese Aufgabe läuft doch." });
}
/* Fällt status_vorher aus (alte Zeile, von Hand geändert), geht es
nach "offen" -- ein bekannter Zustand ist besser als ein leeres
Feld, das den CHECK verletzt und die Aufgabe unerreichbar macht. */
const zurueck = STATUS.includes(aufgabe.status_vorher) ? aufgabe.status_vorher : "offen";
db().prepare(`
UPDATE aufgaben
SET status = ?, status_vorher = NULL, abbruch_grund = NULL,
abgebrochen_am = NULL, abbruch_von = NULL, geaendert = ?
WHERE id = ?`).run(zurueck, jetzt(), id);
protokolliere("aufgabe_wiederaufgenommen", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `#${id} -> ${zurueck}`.slice(0, 120),
});
res.json({ ok: true, status: zurueck });
} catch (fehler) {
console.error("[workspace] Aufgabe wiederaufnehmen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* ---------- Löschen ------------------------------------------------------
Nur Management. Das Konzept will ausdrücklich, dass Erledigtes sichtbar
bleibt ("Erledigte Aufgaben verschwinden nicht") -- Löschen ist deshalb
der Ausnahmefall für Fehleinträge, nicht der normale Abschluss. Der
Titel wandert ins Protokoll, damit nachvollziehbar bleibt, was weg ist. */
aufgabenRouter.delete("/workspace/api/aufgaben/:id", gleicheHerkunft, (req, res) => {
try {
if (!istLeitung(req.person)) return res.status(403).json({ fehler: "nicht_erlaubt" });
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
const aufgabe = db().prepare("SELECT id, titel FROM aufgaben WHERE id = ?").get(id);
if (!aufgabe) return res.status(404).json({ fehler: "nicht_gefunden" });
db().prepare("DELETE FROM aufgaben WHERE id = ?").run(id);
protokolliere("aufgabe_geloescht", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `#${id} ${aufgabe.titel}`.slice(0, 120),
});
res.json({ ok: true });
} catch (fehler) {
console.error("[workspace] Aufgabe löschen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});