DogFatherGitandClaude Opus 5
731537b682
VanVan im Support (Runde 1, „Ging noch nicht"): „Das dort steht ich
bewerbe mich ist jetzt weg, aber dafür hat er noch mal 2 Buttons
hinzugefügt mit ich fange an und fertig. Wenn man auf ich fange an
drückt steht dort in Bearbeitung und wenn man auf fertig drückt dann
wird es zu erledigt. Die Aufgabe bleibt aber im status offen stehen.
Die beiden Buttons können entfernt werden, weil es darüber ja den
button starten gibt, der auch korrekt funktioniert."
SIE HAT ETWAS GROESSERES GEFUNDEN ALS ZWEI UEBERFLUESSIGE KNOEPFE.
Es gab ZWEI Zustaende nebeneinander, und sie kannten sich nicht:
aufgaben.status offen · arbeit · review · erledigt
aufgaben_zuteilung.zustand angenommen · arbeit · erledigt
Die zwei Knoepfe setzten den zweiten (`/mein-stand`), der
Starten-Knopf den ersten. Auf der Karte stand „in Bearbeitung", in der
Liste „offen" -- und beides stimmte. Das ist schlimmer als ein Fehler:
Es gibt nichts, dem man glauben kann. Zwei Antworten auf dieselbe
Frage sind in diesem Haus verboten, und genau das war es.
WAS ICH BEINAHE FALSCH GEMACHT HAETTE
Ihr Wunsch war „entfernt die Knoepfe". Bevor ich das tue, habe ich
gemessen, was danach bliebe -- am Bildschirm einer Modi mit einer
angenommenen Aufgabe:
Karten-Knoepfe: []
Schritt-Knoepfe: []
KEIN EINZIGER. Die Modi sieht den Starten-Knopf NICHT, weil
`darfAendern` fuer sie falsch ist: Sie ist weder Leitung noch
`creator_id`, `verantwortlich_id` oder `erstellt_von` -- die Zuteilung
laeuft ueber eine eigene Tabelle. VanVan ist Leitung und sieht ihn;
deshalb klang „den gibt es doch" selbstverstaendlich.
Haette ich die Knoepfe einfach geloescht, haette ich der Modi die
einzige Handlung weggenommen, die sie hatte -- eine Meldung „behoben",
nach der weniger geht als vorher.
ALSO WIRD IHR SATZ WAHR GEMACHT
1. Wer eine Aufgabe WIRKLICH hat (angenommen/arbeit/erledigt), darf
ihren STATUS setzen. Damit sieht die Modi denselben Knopf wie alle
-- gemessen: „Schritt-Knoepfe: [starten ▶]".
ENG GEFASST: nur der Status, nur allein in der Anfrage. Die
Pruefung ist `Object.keys(...).length === 1` und nicht „enthaelt
status" -- sonst waere die schmale Tuer die breite mit einem
Zusatzfeld.
2. Der Statuswechsel zieht die Zuteilung MIT. Ohne das waere das
Entfernen eine stille Verschlechterung gewesen: Die Zaehler einer
Person („offen / in Arbeit / erledigt") lesen die ZUTEILUNG, nicht
die Aufgabe. Jede Zuteilung waere fuer immer auf „angenommen"
stehen geblieben, und die Zahlen haetten aufgehoert, die
Wirklichkeit zu zeigen -- ohne dass irgendwo etwas rot wird.
ABGELEITET, NICHT ZWEIMAL GESCHRIEBEN: `STATUS_ALS_ZUSTAND` gibt
es seit dem 22.09. Benutzt wird genau sie, mit EINER Abweichung,
und die steht daneben: Wer zugesagt hat, faellt beim Zurueckdrehen
auf „angenommen", nicht auf „offen". Eine Zusage verschwindet
nicht, weil jemand den Status zurueckstellt.
3. Die zwei Knoepfe sind weg. Der Weg `/mein-stand` bleibt -- er ist
die Schranke fuer den, der die Schnittstelle direkt anspricht.
GEGENPROBEN ZUM ERWEITERTEN RECHT (ein Recht ohne Gegenprobe ist ein
Loch mit Begruendung):
Anna hat eine Aufgabe, die ihr NUR zugeteilt ist
(darf_aendern false, darf_status true)
sie setzt den Status ihrer Aufgabe (200)
mit einem zweiten Feld kommt sie nicht durch (403)
und umschreiben darf sie gar nicht (403)
der Titel steht unveraendert da („Clips schneiden")
und wer sie nicht hat, setzt auch keinen Status (404)
zurueckgedreht steht Anna wieder auf „angenommen"
eine Bewerbung bleibt eine Bewerbung (abgelehnt -> abgelehnt)
ZWEI EIGENE FEHLER, BEIDE VON DER MESSUNG GEFUNDEN:
· Mein erster Zeuge war Bea und die Pool-Aufgabe. Die Gegenprobe
wurde rot: Bea darf sie ohnehin umschreiben, weil das Uebernehmen
aus dem Pool sie verantwortlich macht. An ihr laesst sich ueber die
neue, schmale Tuer gar nichts zeigen. Der reine Fall wird jetzt
GESUCHT (darf_aendern falsch, Zuteilung angenommen) statt
hingeschrieben -- eine feste Nummer waere die naechste, die beim
naechsten Umbau nicht mehr stimmt.
· Mein Abschnitt stellte Annas Aufgabe auf „arbeit" und liess sie so
stehen; ein spaeterer zaehlte ihre „angenommen" und wurde dadurch
rot. Eine Pruefung, die den Bestand fuer die naechste veraendert,
misst ab da etwas anderes als sie glaubt. Jetzt raeumt sie auf --
und die Rueckfahrt ist selbst eine Messung.
ZWEI PRUEFUNGEN MUSSTEN MITZIEHEN, und das ist richtig so: Beide
verlangten „Ich fange an" -- geschrieben von mir am 30.09. fuer
VanVans ERSTE Meldung. Ihre Absicht bleibt woertlich dieselbe („kann
sie wirklich etwas tun?"), nur ist der Griff jetzt der Statusknopf.
`knoepfeAn` sieht dafuer auch neben den Zuteilungsblock: „kann sie
etwas tun?" laesst sich am Block allein nicht beantworten.
GEPRUEFT: pruef-zuteilung 75 -> 90 ok · pruef-bewerbung-aufgaben
162 -> 164 ok · pruef-struktur 99 · pruef-resuemee 35 ·
pruef-aufgabenbrett 49 · pruef-rechtetafel 19 ·
pruef-aufgaben-vorlagen 46.
Co-Authored-By: Claude Opus 5 <[email protected]>
1382 lines
64 KiB
JavaScript
1382 lines
64 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, darfAufgabenVerteilen, darfAufgabenAnlegen, ohneDogFather, heuteLokal, ROLLEN_SORTIERUNG, ROLLEN_GRUPPE, betreuteIds,
|
|
externPruefen, externSql, sichtbarePersonenIds, sichtbareCreatorIds,
|
|
MODI_KATEGORIEN, kategorienFuer, kategoriePersonen,
|
|
KANAELE, kanaeleFuer,
|
|
ohneTeamDogi, ohneAgentur, siehtModis, TEAM_DOGI_ROLLEN,
|
|
} from "./workspace.js";
|
|
import { eskalationSetzen } from "./workspace-eskalation.js";
|
|
import { AUFWAND, AUFWAND_SCHLUESSEL } from "./workspace-womit.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();
|
|
|
|
import { zuteilen, mitZuteilung, bewerbungenSchliessen,
|
|
zuteilungenNachStatus } from "./workspace-zuteilung.js";
|
|
|
|
/* ---------- 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 roh = sichtbarRoh(person);
|
|
const regel = mitZugeteilten(roh, 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,
|
|
};
|
|
}
|
|
/* ==== DREI FAELLE UND NICHT ZWEI (24.09.2026, nachgebessert) =====
|
|
|
|
Hier stand bis heute `if (siehtModis(person)) return regel;` --
|
|
"wer Modi-Daten sehen darf, bekommt sie ungefiltert". Auf der
|
|
AGENTURADRESSE hiess das in der Praxis: DogFather sieht dort auch
|
|
Team Dogi. Genau das hat Filipe am 24.09.2026 abgeschafft.
|
|
|
|
DIE ERSTE FASSUNG DIESER REPARATUR WAR ZU GROB: Ich habe die Zeile
|
|
einfach gestrichen. Damit fiel auch der Fall "keine der beiden
|
|
Adressen" durch -- also jede Pruefadresse. Gemessen: 19
|
|
Fehlschlaege in drei Pruefungen, weil ein Modi seine eigenen
|
|
Aufgaben nicht mehr sah. Nicht weil etwas kaputt war, sondern weil
|
|
`ohneTeamDogi` dort ploetzlich auf ihn selbst zeigte.
|
|
|
|
ES SIND DREI LAGEN, und jede bekommt ihre Zeile:
|
|
crew -> ohne die Agentur
|
|
agentur -> ohne Team Dogi, AUCH fuer DogFather (das ist neu)
|
|
kein Haus (localhost, Pruefungen) -> die alte Rollenregel,
|
|
unveraendert. Sonst waeren alle Modi-Pruefungen des
|
|
Hauses still gruen und blind -- die Falle, vor der
|
|
crew-adresse.js dreimal warnt.
|
|
|
|
`siehtModis` BLEIBT UNVERAENDERT und wird anderswo weiter
|
|
gebraucht (Rechtefragen, z.B. in der Checkliste). "Darf ich das
|
|
sehen" und "welchen Ausschnitt sehe ich gerade" sind zwei Fragen;
|
|
wer sie in eine Funktion legt, kann spaeter nicht mehr sagen,
|
|
welche zugeschlagen hat. */
|
|
if (person.haus === "agentur") {
|
|
return {
|
|
wo: `(${regel.wo}) AND ${ohneTeamDogi("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,
|
|
};
|
|
}
|
|
|
|
/** WER EINE AUFGABE BEKOMMEN HAT, SIEHT SIE -- immer (21.09.2026).
|
|
*
|
|
* Ohne das koennte man jemandem eine Aufgabe geben, die er nie zu
|
|
* Gesicht bekommt: Bei "mehrere" und "pool" bleibt
|
|
* `verantwortlich_id` leer, und die alten Regeln fragen genau danach.
|
|
* Die Aufgabe stuende dann im Resuemee der Leitung und waere fuer den
|
|
* Menschen, der sie machen soll, unsichtbar -- der unangenehmste
|
|
* denkbare Fehler in einem Aufgabensystem.
|
|
*
|
|
* ODER, NICHT UND: Das erweitert die Sicht, es engt sie nicht ein.
|
|
* Die Haustrennung darueber bleibt ein UND und wirkt weiterhin. */
|
|
function mitZugeteilten(regel, person) {
|
|
if (!regel || !person?.id) return regel;
|
|
/* Wer ohnehin alles sieht, braucht die Erweiterung nicht -- und eine
|
|
Bedingung, die immer wahr ist, macht die Abfrage nur langsamer. */
|
|
if (regel.wo === "1=1") return regel;
|
|
return {
|
|
wo: `(${regel.wo} OR EXISTS (SELECT 1 FROM aufgaben_zuteilung z`
|
|
+ ` WHERE z.aufgabe_id = a.id AND z.person_id = ?))`,
|
|
werte: [...regel.werte, person.id],
|
|
};
|
|
}
|
|
|
|
/* 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. */
|
|
/* =================================================================
|
|
EIN MODI SIEHT NUR SEINE EIGENEN (22.09.2026) -- und das dreht
|
|
die Entscheidung vom 09.09. ausdruecklich um.
|
|
|
|
Filipe, mehrfach und zuletzt unmissverstaendlich: "die modis
|
|
sollen immer nur ihre aufgaben auch sehen und nicht die von
|
|
anderen, so wie bei den daten ... damit wir endlich den modis
|
|
aufgaben anstaendig verteilen koennen und sie sich nicht selber
|
|
aufgaben geben."
|
|
|
|
Am 09.09. hatte er das Gegenteil entschieden ("ja, sie sind
|
|
untereinander ein team"), damit ein Schichttausch ohne Umweg
|
|
geht. Diese Zeile haelt beides fest, damit niemand spaeter die
|
|
aeltere Entscheidung findet und sie fuer die gueltige haelt: Die
|
|
neuere gilt.
|
|
|
|
WAS BLEIBT: Was ihm ueber `aufgaben_zuteilung` gegeben wurde,
|
|
sieht er weiterhin -- das haengt `mitZugeteilten()` an diese
|
|
Bedingung an. Ein Pool, in dem er steht, bleibt also sichtbar,
|
|
bis ihn jemand uebernimmt. */
|
|
case "modi":
|
|
return { wo: "a.verantwortlich_id = ?", werte: [person.id] };
|
|
|
|
case "hand":
|
|
/* Die linke Hand sieht dasselbe wie die rechte (21.09.2026). */
|
|
case "linke": {
|
|
/* =================================================================
|
|
AUF DER ADRESSE VON TEAM DOGI SEHEN SIE ALLES (22.09.2026)
|
|
|
|
Filipe: „rechte hand linke hand und dogfather sehen alle
|
|
aufgaben und koennen alle verteilen."
|
|
|
|
GEFUNDEN BEIM BAUEN DER BEWERBUNG, nicht beim Lesen: Die
|
|
rechte Hand soll ueber Bewerbungen entscheiden -- und sah die
|
|
Aufgabe nicht, um die es ging. Gemessen an einer Pool-Aufgabe,
|
|
die DogFather fuer zwei Modis angelegt hat:
|
|
|
|
DogFather sieht sie 1 Bewerbung
|
|
Modi sieht sie 1 Bewerbung
|
|
rechte Hand SIEHT SIE NICHT (Liste leer)
|
|
|
|
Die Regel darunter sammelt die Menschen mit einer
|
|
TEAM_DOGI_ROLLE und fragt, ob einer von ihnen als Creator,
|
|
Verantwortlicher oder Ersteller eingetragen ist. Bei einer
|
|
Pool-Aufgabe bleibt `verantwortlich_id` aber leer (das ist ihr
|
|
Sinn), `creator_id` war leer, und der Ersteller ist DogFather
|
|
-- der in dieser Liste nicht steht. Alle drei Bedingungen
|
|
gingen also ins Leere.
|
|
|
|
Eine Entscheiderin, die das zu Entscheidende nicht sieht,
|
|
waere ein Knopf ohne Gegenstand. Und es ist ohnehin das, was
|
|
Filipe gesagt hat.
|
|
|
|
`1=1` HEISST HIER NICHT „ALLES IM HAUS": `sichtbar()` haengt
|
|
fuer `haus === "crew"` ein `AND ohneAgentur(...)` davor. Die
|
|
Trennung der zwei Haeuser bleibt damit unberuehrt -- es ist
|
|
„alles von Team Dogi", nicht „alles".
|
|
|
|
DIE ALTE REGEL BLEIBT ALS RUECKFALL stehen, fuer den Fall,
|
|
dass eine Hand je auf einer anderen Adresse auftaucht. Sie
|
|
dort auf `1=1` zu setzen waere eine Tuer in das andere Haus.
|
|
================================================================= */
|
|
if (person.haus === "crew") return { wo: "1=1", werte: [] };
|
|
|
|
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;
|
|
/* WER SIE ANGELEGT HAT, DARF SIE AUCH AENDERN (25.09.2026).
|
|
|
|
Filipe: „kuemmer dich bitte auch drum dass die rechte hand, wenn
|
|
sie aufgaben an die modis oder linke hand erstellt, will ich dass
|
|
sie die moeglichkeit hat die auch zu bearbeiten und zu loeschen."
|
|
|
|
WARUM DAS VORHER NICHT GING, obwohl es so aussah: `creator_id`
|
|
sagt nicht, WER die Aufgabe angelegt hat -- es sagt, ZU WEM sie
|
|
gehoert (so steht es am Tabellenkopf). Verteilt die rechte Hand
|
|
eine Aufgabe an einen Modi, steht dort der Modi. Sie hatte damit
|
|
an ihrer eigenen Aufgabe keine einzige der drei Bedingungen
|
|
erfuellt und bekam vom Server ein 403 -- auf einen Knopf, den die
|
|
Oberflaeche ihr trotzdem zeigte.
|
|
|
|
`erstellt_von` GIBT ES SEIT JEHER und wird beim Anlegen gefuellt;
|
|
die Sichtbarkeitsregeln fragen sie an sechs Stellen ab. Sie stand
|
|
nur nie in dieser Zeile.
|
|
|
|
DIE REGEL IST ALLGEMEIN, nicht auf eine Rolle gemuenzt: Wer etwas
|
|
angelegt hat, darf es auch wieder anfassen. Ein Rollenname hier
|
|
waere die naechste zweite Wahrheit -- und in diesem Haus ist genau
|
|
das in derselben Woche schon dreimal veraltet. */
|
|
return aufgabe.creator_id === person.id
|
|
|| aufgabe.verantwortlich_id === person.id
|
|
|| aufgabe.erstellt_von === person.id;
|
|
}
|
|
|
|
/* ===== UND LOESCHEN? =================================================
|
|
|
|
Loeschen ist das Einzige, was sich nicht zuruecknehmen laesst --
|
|
deshalb eine eigene Frage und nicht einfach `darfAendern`.
|
|
|
|
ZWEI BEDINGUNGEN, UND BEIDE MUESSEN STIMMEN:
|
|
|
|
1. Die Person darf Aufgaben ueberhaupt VERTEILEN. Damit ist
|
|
ausgeschlossen, dass jemand, dem eine Aufgabe nur zugeteilt
|
|
wurde, sie loescht statt sie abzulehnen -- ein Modi soll sie
|
|
ablehnen oder abbrechen, nicht verschwinden lassen.
|
|
2. Die Person darf sie aendern (siehe oben). Damit ist es genau
|
|
das, was Filipe gesagt hat: ihre eigenen.
|
|
|
|
DOGFATHER UND DIE MANAGER bleiben unveraendert: `istLeitung` macht
|
|
`darfAendern` fuer sie immer wahr, und verteilen duerfen sie
|
|
ohnehin. Die Zeile ist damit eine Erweiterung, keine Einschraenkung
|
|
-- nachgewiesen in pruef-aufgaben-loeschen mit einer Gegenprobe. */
|
|
function darfLoeschen(person, aufgabe) {
|
|
return darfAufgabenVerteilen(person) && darfAendern(person, aufgabe);
|
|
}
|
|
|
|
/* ===== UND DEN STATUS? (02.10.2026) =================================
|
|
|
|
VanVan im Support: „Die beiden Buttons können entfernt werden, weil
|
|
es darüber ja den button starten gibt, der auch korrekt funktioniert
|
|
wenn man ihn benutzt und die Aufgabe dann aus dem Status offen zum
|
|
Status in Arbeit schiebt."
|
|
|
|
SIE HAT RECHT -- ABER NICHT FUER DEN MODI. Nachgemessen am
|
|
Bildschirm einer Modi mit einer angenommenen Aufgabe:
|
|
|
|
Karten-Knoepfe: []
|
|
Schritt-Knoepfe: []
|
|
|
|
Keiner. Sie sieht den Starten-Knopf nicht, weil `darfAendern` fuer
|
|
sie falsch ist -- sie ist weder Leitung noch `creator_id`,
|
|
`verantwortlich_id` oder `erstellt_von`; die Zuteilung laeuft ueber
|
|
eine eigene Tabelle. VanVan ist Leitung und sieht ihn, deshalb
|
|
klang „den gibt es doch" selbstverstaendlich.
|
|
|
|
Haette ich die zwei Knoepfe einfach geloescht, haette ich der Modi
|
|
die einzige Handlung weggenommen, die sie hatte. Das waere eine
|
|
Meldung „behoben" gewesen, nach der weniger geht als vorher.
|
|
|
|
ALSO WIRD IHR SATZ WAHR GEMACHT: Wer eine Aufgabe wirklich hat,
|
|
darf ihren STATUS setzen. Damit gibt es EINEN Weg fuer alle, und
|
|
der bewegt das, was alle lesen.
|
|
|
|
ENG GEFASST, UND ZWAR ABSICHTLICH: nur der Status. Nicht Titel,
|
|
nicht Frist, nicht die Zuteilung. `darfAendern` bleibt unberuehrt
|
|
-- wer eine Aufgabe bekommt, darf sie tun, nicht umschreiben.
|
|
|
|
NUR WER ZUGESAGT HAT. Eine Bewerbung ist keine Zusage, und ein
|
|
„abgelehnt" ist eine Entscheidung; beide geben kein Recht. */
|
|
function darfStatusSetzen(person, aufgabe) {
|
|
if (darfAendern(person, aufgabe)) return true;
|
|
try {
|
|
const z = db().prepare(`SELECT 1 FROM aufgaben_zuteilung
|
|
WHERE aufgabe_id = ? AND person_id = ?
|
|
AND zustand IN ('angenommen','arbeit','erledigt')`)
|
|
.get(aufgabe.id, person.id);
|
|
return !!z;
|
|
} catch { return false; }
|
|
}
|
|
|
|
const SPALTEN = `
|
|
a.id, a.titel, a.beschreibung, a.status, a.prioritaet, a.aufwand, a.frist,
|
|
/* DAUERHAFT (30.09.2026). Ohne diese Spalte weiss die Oberflaeche
|
|
nichts davon -- sie zeigte weiter einen Fertig-Knopf, der eine
|
|
Absage holt.
|
|
|
|
KEIN BACKTICK IN DIESEM KOMMENTAR: SPALTEN ist selbst ein
|
|
Template-String, und ein Backtick darin beendet ihn. Beim ersten
|
|
Anlauf stand hier ein Beispiel in Backticks -- die Datei war
|
|
danach syntaktisch kaputt. Dieselbe Familie wie die deutsche
|
|
Anfuehrung in einem Anfuehrungsstring: ein Zeichen, das in der
|
|
Umgebung etwas bedeutet. */
|
|
a.dauerhaft,
|
|
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,
|
|
/* Wie sie verteilt wurde (21.09.2026) -- ohne das koennte die
|
|
Oberflaeche "mehrere" und "pool" nicht unterscheiden, und genau
|
|
daran haengt, ob eine uebernommene Aufgabe fuer die anderen noch
|
|
offen ist. */
|
|
a.verteilart,
|
|
/* WER SIE ANGELEGT HAT (25.09.2026). Sie stand in den
|
|
Sichtbarkeitsregeln laengst, fehlte aber in dieser Spaltenliste --
|
|
und damit in jeder Aufgabe, die darfAendern zu sehen bekam. Ohne
|
|
sie waere die neue Regel eine Zeile, die nie zutrifft: ein
|
|
Vergleich gegen undefined.
|
|
|
|
KEINE RUECKSTRICHE IN DIESEM KOMMENTAR: Die Liste ist ein
|
|
Vorlagentext (Backticks), und ein Rueckstrich darin beendet ihn
|
|
mitten im Satz. Beim ersten Anlauf hat node genau das gemeldet. */
|
|
a.erstellt_von,
|
|
/* 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,
|
|
a.kanal,
|
|
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());
|
|
/* WIE LANGE GEHT DAS SCHON SO? Am Server gerechnet, nicht im
|
|
Browser: Startseite, Brett und Uebersicht lesen dieselbe Liste,
|
|
und drei Stellen, die dieselbe Frage selbst beantworten, geben
|
|
irgendwann drei Antworten. */
|
|
eskalationSetzen(reihen);
|
|
|
|
/* ==== WER DARF DIESE KARTE WEITERSCHIEBEN? (20.09.2026) ==========
|
|
|
|
An jeder Karte stehen „◀ zurueck" und „▶ In Arbeit". Sie wurden
|
|
OHNE Pruefung gebaut -- auch an den Karten anderer Leute.
|
|
|
|
Ein Modi sieht das Brett des ganzen Teams (siehe sichtbarkeit
|
|
weiter oben, das ist Absicht). Er tippt an einer fremden Karte
|
|
auf „In Arbeit", der Server lehnt mit 403 ab, und die Meldung
|
|
erscheint GANZ OBEN auf der Seite. Bei einer Karte weiter unten
|
|
sieht er davon nichts -- fuer ihn tut der Knopf einfach nichts.
|
|
|
|
Zwei Zeilen tiefer steht die Regel im Klartext: „hier geht es
|
|
nur darum, niemandem etwas anzubieten, das dann abgelehnt wird."
|
|
Sie galt fuer den Abbrechen-Knopf und nicht fuer diese beiden.
|
|
|
|
DIE ANTWORT KOMMT VOM SERVER, nicht aus einer zweiten Regel im
|
|
Browser: `darfAendern` entscheidet ohnehin schon ueber das
|
|
Schreiben. Zwei Stellen, die dieselbe Frage beantworten, geben
|
|
irgendwann zwei Antworten -- und die falsche ist dann die
|
|
sichtbare. */
|
|
for (const r of reihen) {
|
|
r.darf_aendern = darfAendern(req.person, r);
|
|
/* DEN STATUS DARF AUCH, WER SIE NUR HAT (02.10.2026).
|
|
Zwei Rechte statt einem, weil es zwei Fragen sind:
|
|
„darf ich das umschreiben?" und „darf ich das tun?".
|
|
Die Oberflaeche zeigt die Schrittknoepfe jetzt an diesem
|
|
Recht -- vorher hing sie am falschen, und eine Modi sah
|
|
gar keinen. */
|
|
r.darf_status = darfStatusSetzen(req.person, r);
|
|
/* DIE OBERFLAECHE SOLL DEN KNOPF NUR ZEIGEN, WENN ER GEHT.
|
|
Bisher entschied sie es an `darf_verteilen` -- einer Auskunft
|
|
ueber die PERSON. Loeschen haengt aber an der AUFGABE: Die
|
|
rechte Hand darf verteilen, sah also den Knopf an jeder
|
|
Aufgabe, und der Server sagte bei fremden 403. Ein Knopf, der
|
|
eine Absage holt, ist schlimmer als keiner. */
|
|
r.darf_loeschen = darfLoeschen(req.person, r);
|
|
}
|
|
|
|
/* WER HAT DIESE AUFGABE -- UND WIE STEHT SIE BEI IHM (21.09.2026).
|
|
In EINER Abfrage fuer alle Zeilen; eine je Aufgabe waeren bei
|
|
vierzig Karten vierzig Abfragen. Dazu je Zeile der eigene Stand
|
|
und, beim Pool, wer sie schon genommen hat -- damit niemand
|
|
doppelt arbeitet. */
|
|
mitZuteilung(reihen, req.person);
|
|
|
|
res.json({
|
|
aufgaben: reihen,
|
|
/* Die Aufwandsstufen kommen mit: Eine zweite Liste im Browser
|
|
waere die, die beim naechsten Wert veraltet. */
|
|
aufwand: AUFWAND,
|
|
/* 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),
|
|
/* DIE KANAELE (17.09.2026). Genau wie die Kategorien: Wer sie
|
|
nicht benutzen darf, bekommt eine leere Liste, und die
|
|
Oberflaeche zeigt dann gar kein Feld -- statt eines Feldes,
|
|
das da ist und nichts tut. */
|
|
kanaele: kanaeleFuer(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;
|
|
|
|
/* ORTSZEIT (01.10.2026): `jetzt().slice(0, 10)` waere der UTC-Tag.
|
|
Nachts zwischen 00:00 und 02:00 haette eine Aufgabe mit Frist
|
|
„gestern" noch als nicht ueberfaellig gegolten. */
|
|
const heute = heuteLokal();
|
|
|
|
/* 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",
|
|
/* WER AUFGABEN AUS DEM KATALOG BEKOMMEN KANN (17.09.2026).
|
|
|
|
Der Browser hatte das selbst entschieden --
|
|
`p.rolle === 'modi' || p.rolle === 'hand'`, mitten in
|
|
aufgaben.js. Diese Datei kann jeder ohne Anmeldung aus dem
|
|
offenen Netz lesen; damit stand dort schwarz auf weiss, wie
|
|
der verborgene Zugang heisst.
|
|
|
|
Jetzt entscheidet es der Server und schickt ein Ja/Nein. Aus
|
|
einem "true" laesst sich nichts ablesen. */
|
|
fuer_katalog: TEAM_DOGI_ROLLEN.has(z.rolle),
|
|
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));
|
|
const KANAL_WERTE = new Set(KANAELE.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;
|
|
}
|
|
/* DER AUFWAND IST FREIWILLIG -- ein leerer Wert nimmt die Schaetzung
|
|
zurueck, statt sie zu erzwingen. Wer nicht weiss, wie gross etwas
|
|
ist, soll nicht raten muessen; die Uebersicht sagt dann eben
|
|
"noch nicht eingeschaetzt", und das ist eine ehrliche Auskunft. */
|
|
if (körper.aufwand !== undefined) {
|
|
const w = String(körper.aufwand ?? "").trim();
|
|
if (!w) aus.aufwand = null;
|
|
else if (!AUFWAND_SCHLUESSEL.includes(w)) fehler.push("Unbekannter Aufwand.");
|
|
else aus.aufwand = w;
|
|
}
|
|
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;
|
|
}
|
|
/* ==== DAUERHAFT (30.09.2026) ======================================
|
|
|
|
VanVan im Support: „… noch nicht festlegen, dass die Aufgabe
|
|
dauerhaft sein soll und somit nicht vom Modi in den Status
|
|
erledigt gesetzt werden kann."
|
|
|
|
NUR, WER VERTEILT, DARF DAS SETZEN. Könnte der Zugeteilte seine
|
|
eigene Aufgabe dauerhaft machen, wäre das eine Ausrede; könnte er
|
|
es zurücknehmen, wäre die Sperre ein Knopf weiter offen. Ein
|
|
unerlaubtes Feld wird still übergangen und nicht abgelehnt — sonst
|
|
scheiterte ein Formular an einem Häkchen, das gar nicht gemeint
|
|
war. */
|
|
if (körper.dauerhaft !== undefined && darfAufgabenVerteilen(person)) {
|
|
aus.dauerhaft = körper.dauerhaft ? 1 : 0;
|
|
/* UND DANN GIBT ES KEINE FRIST MEHR. Eine dauerhafte Aufgabe mit
|
|
Frist wäre ab dem nächsten Tag für immer überfällig — und eine
|
|
Warnung, die immer kommt, ist keine mehr. Sie wird gelöscht und
|
|
nicht bloß ignoriert: Ein Datum, das dasteht und nicht gilt,
|
|
ist schlimmer als keins. */
|
|
if (aus.dauerhaft) aus.frist = null;
|
|
}
|
|
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;
|
|
}
|
|
|
|
/* DER KANAL -- dieselbe Regel wie bei der Kategorie, Wort fuer Wort
|
|
(17.09.2026). Wer keine Kanaele hat, schickt auch keine; ein Wert
|
|
von ihm faellt stillschweigend, damit die Absage nicht verraet,
|
|
dass es das Feld gibt. Wer sie hat, bekommt bei einem falschen
|
|
Wert sehr wohl eine Absage -- fuer ihn ist ein Tippfehler ein
|
|
Fehler und kein Geheimnis.
|
|
|
|
LEER HEISST `null` UND DAS HEISST "gilt fuer alles". Vieles ist
|
|
nicht kanalgebunden: eine Absprache im Team, ein Zugang, eine
|
|
Auswertung. Ein Pflichtfeld haette dafuer einen falschen Kanal
|
|
erzwungen. */
|
|
if (körper.kanal !== undefined && kanaeleFuer(person).length) {
|
|
const k = String(körper.kanal ?? "").trim();
|
|
if (!k) aus.kanal = null;
|
|
else if (!KANAL_WERTE.has(k)) fehler.push("Unbekannter Kanal.");
|
|
else aus.kanal = 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 {
|
|
/* Die Auswahl folgt der SICHT, nicht dem Angemeldeten -- dieselbe
|
|
Regel wie bei den Daten dieses Moduls. Zwei Antworten auf eine
|
|
Frage waren der Grund, warum eine fremde Sicht nur auf der
|
|
halben Seite ankam (11.09.2026). */
|
|
const person = req.sicht || 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 {
|
|
/* IM TEAM DOGI LEGT NUR DIE LEITUNG AN (22.09.2026). Ein Modi
|
|
bekommt Aufgaben; er gibt sich keine. Die Schranke steht VOR der
|
|
Feldpruefung, damit die Antwort nicht erst ueber Feldfehler
|
|
redet, wenn der Weg ohnehin zu ist. */
|
|
if (!darfAufgabenAnlegen(req.person)) {
|
|
return res.status(403).json({ fehler: "nur_leitung_legt_an" });
|
|
}
|
|
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. */
|
|
/* VERTEILEN DARF NUR, WER ES DARF -- alle anderen legen die
|
|
Aufgabe auf sich selbst, egal was im Aufruf steht. Seit dem
|
|
20.09.2026 gehoert die rechte Hand dazu (darfAufgabenVerteilen),
|
|
ein Modi nicht: Er kann sich Aufgaben notieren, aber keine an
|
|
andere geben. */
|
|
if (!darfAufgabenVerteilen(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, kanal,
|
|
dauerhaft, erstellt, erstellt_von, haus)
|
|
VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)`).run(
|
|
/* DAS HAUS WIRD BEIM ANLEGEN GESCHRIEBEN (25.09.2026) -- siehe
|
|
das letzte Argument. Ohne es bekaeme eine Aufgabe, an der nur
|
|
DogFather haengt (Pool-Aufgabe ohne Verantwortlichen), kein
|
|
Haus -- und waere in beiden sichtbar. */
|
|
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, aus.kanal ?? null,
|
|
/* DAUERHAFT (30.09.2026). `pruefeFelder` laesst das Feld nur
|
|
durch, wenn die Person verteilen darf -- steht es nicht in
|
|
`aus`, ist es keine. */
|
|
aus.dauerhaft ?? 0,
|
|
jetzt(), req.person.id, req.person.haus || null);
|
|
|
|
/* AN MENSCHEN VERTEILEN (21.09.2026, Abschnitt 3).
|
|
Nur wer verteilen darf -- sonst koennte sich jemand selbst eine
|
|
Aufgabe anlegen und sie dem halben Team zuschieben. */
|
|
let verteilt = null;
|
|
if (darfAufgabenVerteilen(req.person) && Array.isArray(req.body?.zuteilung)) {
|
|
verteilt = zuteilen(Number(lastInsertRowid), req.body.zuteilung,
|
|
req.body?.verteilart, 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), zuteilung: verteilt });
|
|
} 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" });
|
|
/* ==== ZWEI TUEREN, UND DIE SCHMALE IST NEU (02.10.2026) =======
|
|
|
|
Wer die Aufgabe aendern darf, darf alles. Wer sie nur HAT, darf
|
|
genau eine Sache: ihren Status setzen -- und nichts sonst in
|
|
derselben Anfrage. Die Begruendung steht bei `darfStatusSetzen`.
|
|
|
|
DIE ENGE PRUEFUNG IST `Object.keys`, nicht „enthaelt status":
|
|
Wer `{status, titel}` schickt, kommt nicht durch. Sonst waere
|
|
die schmale Tuer die breite mit einem Zusatzfeld. */
|
|
const nurStatus = Object.keys(req.body || {}).length === 1
|
|
&& typeof req.body?.status === "string";
|
|
if (!darfAendern(req.person, aufgabe)
|
|
&& !(nurStatus && darfStatusSetzen(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());
|
|
/* WER SICH BEWORBEN HAT, WARTET NICHT WEITER (01.10.2026).
|
|
Eine erledigte Aufgabe hat keine offenen Bewerbungen mehr --
|
|
sonst steht bei dem Menschen „wartet auf Antwort" auf etwas,
|
|
das es nicht mehr gibt, und bei der Leitung eine
|
|
Entscheidung, die sich erledigt hat. */
|
|
const weg = bewerbungenSchliessen(aufgabe.id,
|
|
"Die Aufgabe wurde inzwischen erledigt.");
|
|
if (weg) {
|
|
console.log(`[aufgaben] ${weg} offene Bewerbung(en) zu #${aufgabe.id} `
|
|
+ "sind mit der Erledigung weggefallen.");
|
|
}
|
|
} else if (aus.status && aus.status !== "erledigt") {
|
|
setz.push("erledigt_am = NULL");
|
|
}
|
|
|
|
db().prepare(`UPDATE aufgaben SET ${setz.join(", ")} WHERE id = ?`).run(...daten, id);
|
|
|
|
/* ==== DER STATUS ZIEHT DIE ZUTEILUNGEN MIT (02.10.2026) ========
|
|
|
|
VanVan im Support: „Wenn man auf ich fange an drückt steht dort
|
|
in Bearbeitung … Die Aufgabe bleibt aber im status offen
|
|
stehen."
|
|
|
|
Bis heute liefen zwei Zustaende nebeneinander: der der AUFGABE
|
|
(offen/arbeit/review/erledigt) und der der ZUTEILUNG
|
|
(angenommen/arbeit/erledigt). Zwei Knoepfe setzten den einen,
|
|
der Starten-Knopf den anderen -- und keiner wusste vom anderen.
|
|
Auf der Karte stand „in Bearbeitung", in der Liste „offen".
|
|
|
|
Die Knoepfe sind weg. Damit die Zaehler der Person trotzdem
|
|
stimmen (sie lesen die ZUTEILUNG), folgt sie jetzt dem Status.
|
|
Die Begruendung im Einzelnen steht bei `zuteilungenNachStatus`;
|
|
sie gehoert dorthin, wo die Zuordnung steht. */
|
|
if (aus.status && aus.status !== aufgabe.status) {
|
|
const mit = zuteilungenNachStatus(id, aus.status);
|
|
if (mit) {
|
|
console.log(`[aufgaben] #${id} -> ${aus.status}: ${mit} Zuteilung(en) `
|
|
+ "sind mitgegangen.");
|
|
}
|
|
}
|
|
|
|
/* DIE ZUTEILUNG MITAENDERN (21.09.2026). Wer eine Aufgabe
|
|
bearbeitet und dabei die Leute wechselt, meint genau das -- eine
|
|
Aenderung, die nur den Titel mitnimmt und die Zuteilung stehen
|
|
laesst, waere eine halbe Aenderung ohne Hinweis.
|
|
|
|
`zuteilen` behaelt dabei den Stand derer, die schon geantwortet
|
|
haben: Ein zweites Speichern darf aus einem "angenommen" kein
|
|
"offen" machen. */
|
|
if (darfAufgabenVerteilen(req.person) && Array.isArray(req.body?.zuteilung)) {
|
|
zuteilen(id, req.body.zuteilung, req.body?.verteilart, req.person.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);
|
|
|
|
/* AUCH HIER FALLEN DIE OFFENEN BEWERBUNGEN WEG (01.10.2026).
|
|
Zwei Wege fuehren in den Endzustand -- erledigen und abbrechen
|
|
--, und beide brauchen dieselbe Aufraeumung. Nur einen zu
|
|
bedienen waere die Haelfte, die man spaeter sucht.
|
|
|
|
DER SATZ IST EIN ANDERER: „abgebrochen" ist nicht „erledigt",
|
|
und wer gewartet hat, soll den Unterschied lesen koennen. */
|
|
const wegAb = bewerbungenSchliessen(id, "Die Aufgabe wurde abgebrochen.");
|
|
if (wegAb) {
|
|
console.log(`[aufgaben] ${wegAb} offene Bewerbung(en) zu #${id} `
|
|
+ "sind mit dem Abbruch weggefallen.");
|
|
}
|
|
|
|
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 {
|
|
const id = Number(req.params.id);
|
|
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
|
|
|
|
/* ERST MIT DER SICHTBARKEITSREGEL HOLEN, dann fragen, ob sie
|
|
geloescht werden darf (25.09.2026).
|
|
|
|
Vorher stand hier `if (!istLeitung) 403` und danach ein
|
|
ungefiltertes `SELECT ... WHERE id = ?`. Zwei Dinge sind daran
|
|
jetzt anders:
|
|
|
|
* Die rechte Hand darf ihre eigenen loeschen -- das ist der
|
|
Auftrag. Die Rollenfrage allein konnte das nicht
|
|
beantworten, weil sie die AUFGABE nicht ansieht.
|
|
* Was jemand nicht sehen darf, gibt es fuer ihn nicht: 404
|
|
statt 403. Sonst liesse sich durch Ausprobieren
|
|
herausfinden, welche Nummern vergeben sind -- dieselbe
|
|
Ueberlegung wie beim Aendern eine Route weiter oben, wo sie
|
|
schon stand. */
|
|
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 (!darfLoeschen(req.person, aufgabe)) {
|
|
return res.status(403).json({ fehler: "nicht_erlaubt" });
|
|
}
|
|
|
|
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" });
|
|
}
|
|
});
|