Manager-Ziele zu Ende gebaut -- und dabei zwei Loecher gefunden

Filipe: „perfektioniere alles jetzt sofort, es muss ready sein."

Die Vorlage Punkt fuer Punkt gegen das Gebaute gehalten, nicht gegen
meine eigene Liste von heute Mittag. Vier Punkte standen noch offen,
und auf dem Weg dorthin sind zwei Fehler aufgefallen, nach denen
niemand gesucht hat.

DIE ZWEI FEHLER ZUERST -- beide gefunden durch Messen, nicht Denken

1. EINE GELOESCHTE PERSON HAETTE IHRE ZAHLEN MITGENOMMEN.
   `mz_eintrag.person_id` stand auf ON DELETE CASCADE. Die Vorlage
   sagt aber: „Wer die Rolle verliert, sieht die Kachel nicht mehr;
   die Daten bleiben fuer den DogFather erhalten." Mit CASCADE waere
   genau das nicht wahr gewesen -- `DELETE FROM personen` haette den
   Monatsverlauf eines Menschen lautlos mitgenommen.

   Jetzt SET NULL, und Name und Rolle stehen zusaetzlich als Text am
   Eintrag (dieselbe Bauweise wie bei support_meldungen). Die Rolle
   ist nicht Zierde: Ohne sie wuerde ein abgeschlossener Monat
   rueckwirkend an den Zielzahlen einer anderen Rolle gemessen.

   Der Umbau laeuft auf dem Bestand von heute Mittag -- Spaltenliste
   AUS PRAGMA abgeleitet, nicht gepflegt, und geprueft werden Zeilen
   UND Spalten. Am 11.09.2026 hat genau so ein Umbau drei Spalten mit
   Inhalt verloren, ohne Fehlermeldung, bei unveraenderter Zeilenzahl.

2. MEIN EIGENER SPERR-TRIGGER HAETTE DAS LOESCHEN BLOCKIERT.
   ON DELETE SET NULL ist kein Loeschen, sondern ein UPDATE auf
   person_id. Der Trigger sah eine Aenderung an einem abgeschlossenen
   Monat und brach ab -- `DELETE FROM personen` waere damit
   gescheitert, an einer Stelle, die mit Monatszielen nichts zu tun
   hat. Erlaubt ist jetzt genau eine Aenderung an einem alten Monat:
   dem Eintrag seinen Besitzer zu nehmen. Als BEDINGUNG und nicht als
   `UPDATE OF <spaltenliste>` -- eine Liste muesste jemand pflegen.

   Weil `CREATE TRIGGER IF NOT EXISTS` eine geaenderte Fassung nicht
   erneuert, wird die alte am INHALT erkannt und ersetzt. Eine
   Fassungsnummer muesste jemand hochzaehlen, und das wird vergessen.

DIE VIER OFFENEN PUNKTE DER VORLAGE

  04  Jede Aufgabenzeile hat ihr eigenes Zeichen -- aus dem Haus
      (`window.Bereiche`), nicht neu gezeichnet: Trichter, Bildschirm,
      Buch, Rahmen. Das Statuszeichen bleibt daneben; ein eingefaerbtes
      Aufgabenzeichen allein traegt die Stufe nicht.
  05  „Farbiger Rand + Badge": Eine Kachel, an der eine Warnung haengt,
      traegt jetzt einen feinen Saum -- JEDE Kachel, nicht nur diese.
      Eine Regel, die nur an einer Stelle gilt, wird beim naechsten Mal
      vergessen.
  08  Die Team-Tabelle ist sortierbar: jede Spalte ein Knopf (kein
      anklickbares <th> -- das erreicht die Tastatur nicht), mit
      aria-sort, und sortiert wird nach ANTEIL statt nach nackter Zahl.
      Dazu eine Ampel-Spalte mit Wort. Auf dem Handy verschwindet die
      Kopfzeile im Kartenmodus, deshalb steht das Sortieren zusaetzlich
      in der Leiste -- sonst waere es auf einem Telefon nicht
      vorhanden.
  09  Wer die Rolle verliert, steht weiter in der Uebersicht, als
      „nicht mehr dabei" und mit der Rolle von damals. Wer geloescht
      wurde, erscheint als zusammengefasste Zeile unter dem
      mitgeschriebenen Namen.

WAS DER SAUM MICH GELEHRT HAT

Er stand zuerst in start.css und war wirkungslos -- der Browser
lieferte weiter den Faseschatten. Der Grund steht seit dem 25.09.2026
in module.css: `:is()` uebernimmt die Spezifitaet seines staerksten
Arguments, und `.gruppe[data-gruppe]` macht die ganze Modulliste
(0,2,0) -- genau so stark wie `.kachel[data-warn="ja"]`, bei
Gleichstand gewinnt die zuletzt geladene Datei. Dieselbe Falle wie
damals bei den Fokusringen, dieselbe Antwort: Was gegen die Modulform
gewinnen muss, gehoert in die Datei mit der Modulform. Gemerkt habe
ich es nur, weil die Bildmessung den errechneten Schatten AUSGIBT
statt ein Bild zu machen.

Beim Herausschneiden blieb eine Klammer zu viel in start.css stehen --
gefunden von pruef-css-klassen („eine schliessende Klammer ohne
oeffnende"), bevor sie still CSS verschluckt hat.

AUSSERDEM BEHOBEN

  * Spicy Media sah an einer FREMDEN Liste „Bearbeiten" und „Loeschen",
    und der Server antwortete mit 403. Ein Knopf, der nichts tut, ist
    schlimmer als kein Knopf.
  * Klick auf eine Person klappt jetzt alle vier Zeilen auf. Die
    Vorlage verspricht „zeigt deren Eintraege" -- zugeklappt zeigte
    der Klick nur Zahlen.
  * Der CSV-Export kennt drei Staende statt zwei: „pflichtig", „neu,
    noch ohne Pflicht", „nicht mehr dabei". Vorher hiess beides „nein".
  * Das Aufklappen baute die ganze Liste neu und riss den
    angeklickten Knopf weg (Fokus sprang nach oben).

GEPRUEFT: 168 Pruefungen, 0 Fehler (vorher 141)

Neu darunter: der Umbau auf einem echten Alt-Bestand (Zeilen, Spalten,
Inhalt, Indizes, Trigger, und ein zweiter Lauf, der nichts mehr tut),
das Loeschen einer Person mit Eintraegen aus einem abgeschlossenen
Monat -- mit Gegenprobe, dass dieselbe Sperre den INHALT weiterhin
nicht aendern laesst.

Zwei meiner neuen Pruefungen haben zuerst sich selbst gemessen statt
den Code: Eine verglich gegen einen Eintrag, den sie vorher geloescht
hatte (404 sah aus wie ein haltender Riegel), die andere meldete eine
fehlende Spalte, die nur ihr eigener Handeinsatz verursacht hatte.
Beide berichtigt.

Am Bildschirm nachgemessen bei 412 px und 1280 px: kein waagerechtes
Schieben, kein eigenes Beruehrziel unter 40 px, genau EINE Kachel mit
Saum und zwanzig ohne.

Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
2026-10-02 17:34:58 +02:00
co-authored by Claude Opus 5
parent db656f6e14
commit f6d2437985
55 changed files with 1617 additions and 727 deletions
+189 -8
View File
@@ -153,16 +153,40 @@ export const ERSTER_MONAT = "2026-10";
* vergessenes Zurücksetzen keine dauerhaft offene Tür ist. */
export const FREIGABE_SEKUNDEN = 120;
export function managerZieleTabellen(d) {
d.exec(`
/* Die Tabellen als TEXT und nicht direkt ausgefuehrt: Der Umbau
weiter unten muss sie nach einem DROP TABLE ein zweites Mal
anlegen koennen -- samt der Indizes, die mit der Tabelle
verschwinden. Zweimal hingeschrieben waeren es zwei Fassungen,
von denen eine veraltet. */
const TABELLEN = `
/* ---------- Ein Eintrag --------------------------------------- */
CREATE TABLE IF NOT EXISTS mz_eintrag (
id INTEGER PRIMARY KEY AUTOINCREMENT,
/* CASCADE und nicht SET NULL: Ein Eintrag ohne Person ist in
dieser Tabelle sinnlos — gezählt wird je Person. Was bleiben
soll, wenn jemand geht, ist die Pipeline und das Protokoll,
nicht sein Monatszähler. */
person_id INTEGER NOT NULL REFERENCES personen(id) ON DELETE CASCADE,
/* SET NULL UND NICHT CASCADE -- berichtigt am 02.10.2026, am
selben Tag, an dem die Tabelle entstand.
Zuerst stand hier CASCADE mit der Begruendung, ein Eintrag
ohne Person sei sinnlos. Die Vorlage sagt aber ausdruecklich:
„Wer die Rolle verliert, sieht die Kachel nicht mehr; die
Daten bleiben fuer den DogFather erhalten." Mit CASCADE waere
genau das nicht wahr gewesen -- DELETE FROM personen in
workspace-personen.js haette den ganzen Monatsverlauf eines
Menschen lautlos mitgenommen, mitten in einem laufenden Jahr.
Das ist dieselbe Entscheidung wie bei support_meldungen: Wird
ein Zugang geloescht, verliert der Eintrag seinen Absender,
nicht seinen Inhalt. Deshalb stehen Name und Rolle zusaetzlich
als Text daneben -- eine Verknuepfung allein ueberlebt das
Loeschen nicht. */
person_id INTEGER REFERENCES personen(id) ON DELETE SET NULL,
/* WER ES WAR, als er es eintrug. Nicht nur verknuepft, sondern
mitgeschrieben: Nach einem Rollenwechsel oder einer Loeschung
stuende sonst „—" neben einer Zahl, die in den Monatsverlauf
eingeht. Die Rolle entscheidet ausserdem, welches Ziel fuer
diesen Monat galt -- eine heute andere Rolle wuerde den
abgeschlossenen Monat rueckwirkend an anderen Zahlen messen. */
von_name TEXT,
von_rolle TEXT,
aufgabe TEXT NOT NULL
CHECK (aufgabe IN ('creator','meeting','schulung','werbung')),
/* 'JJJJ-MM'. Der Monatsschnitt entsteht über diese Spalte und
@@ -256,7 +280,139 @@ export function managerZieleTabellen(d) {
bis TEXT
);
INSERT OR IGNORE INTO mz_freigabe (eins, offen, bis) VALUES (1, 0, NULL);
`);
`;
/* =====================================================================
DER UMBAU: aus CASCADE wird SET NULL (02.10.2026)
=====================================================================
Noetig, weil die Tabelle am selben Tag schon mit CASCADE ausgeliefert
wurde. Ein ALTER TABLE kann in SQLite weder einen Fremdschluessel
noch ein NOT NULL aendern -- dafuer gibt es nur den Weg ueber eine
neue Tabelle.
DREI DINGE, DIE HIER ANDERS GEMACHT SIND ALS BEIM LETZTEN MAL
1. DIE SPALTENLISTE WIRD ABGELEITET, NICHT GEPFLEGT. Am 11.09.2026
hat im Creator Workspace genau so ein Umbau DREI Spalten mit
Inhalt verloren -- die Liste war von Hand abgeschrieben, zweimal
(einmal fuer CREATE, einmal fuer INSERT), und beim Hinzufuegen
der naechsten Spalte hat sie niemand nachgezogen. Hier fragt
PRAGMA, was in BEIDEN Tabellen steht; eine Liste, die niemand
pflegt, kann nicht veralten.
2. GEZAEHLT WERDEN ZEILEN *UND* SPALTEN. Die Zeilenzaehlung war
damals als Sicherung gedacht und konnte den Spaltenverlust gar
nicht sehen: 24 Spalten hinein, 21 heraus, bei unveraenderter
Zeilenzahl, ohne Fehlermeldung. Stimmt hier etwas nicht, wird
geworfen -- und die Umstellung laeuft in einer Transaktion,
die dann zurueckrollt.
3. ER LAEUFT NUR, WENN ER MUSS. Gefragt wird die Datenbank selbst
(PRAGMA foreign_key_list), nicht eine Fassungsnummer, die jemand
hochzaehlen muesste.
===================================================================== */
function umbauWennNoetig(d) {
let brauchtEs = false;
try {
const verweise = d.prepare("PRAGMA foreign_key_list(mz_eintrag)").all();
brauchtEs = verweise.some((v) => v.table === "personen"
&& v.from === "person_id" && String(v.on_delete).toUpperCase() === "CASCADE");
} catch {
return; // Tabelle gibt es (noch) nicht
}
if (!brauchtEs) return;
const spaltenVon = (t) => d.prepare(`PRAGMA table_info(${t})`).all().map((s) => s.name);
const vorherZeilen = d.prepare("SELECT COUNT(*) n FROM mz_eintrag").get().n;
const vorherSpalten = spaltenVon("mz_eintrag");
/* Die Fremdschluessel muessen WAEHREND des Umbaus aus sein, sonst
laufen die Verweise waehrend der Umbenennung ins Leere. Danach
wieder an -- und ueberprueft. */
const warenAn = d.prepare("PRAGMA foreign_keys").get()?.foreign_keys;
d.exec("PRAGMA foreign_keys = OFF");
/* EIGENE TRANSAKTION NUR, WENN NOCH KEINE LAEUFT. Diese Funktion
wird aus dem Bauplan in workspace.js gerufen, und der oeffnet an
zwei Stellen selbst eine. Ein BEGIN darin wirft („cannot start a
transaction within a transaction") -- und das waere ein Abbruch
beim Serverstart, also die schlimmste Stelle fuer einen Fehler,
der sich vermeiden laesst. */
let meine = false;
try {
try { d.exec("BEGIN"); meine = true; } catch { meine = false; }
/* Die neue Tabelle entsteht aus derselben Vorlage wie die echte --
nur unter anderem Namen. Ein zweiter, von Hand geschriebener
CREATE waere die Fassung, die auseinanderlaeuft. */
d.exec(TABELLEN.replace(/mz_eintrag/g, "mz_eintrag_neu"));
const nachher = spaltenVon("mz_eintrag_neu");
const gemeinsam = vorherSpalten.filter((s) => nachher.includes(s));
if (!gemeinsam.includes("id") || !gemeinsam.includes("person_id")) {
throw new Error("Umbau: die Schluesselspalten fehlen in der neuen Tabelle");
}
const liste = gemeinsam.join(", ");
d.exec(`INSERT INTO mz_eintrag_neu (${liste}) SELECT ${liste} FROM mz_eintrag`);
const kopiert = d.prepare("SELECT COUNT(*) n FROM mz_eintrag_neu").get().n;
if (kopiert !== vorherZeilen) {
throw new Error(`Umbau: ${kopiert} statt ${vorherZeilen} Zeilen uebernommen`);
}
/* DIE SPALTENPROBE. Jede alte Spalte muss es weiterhin geben --
sonst ist still Inhalt verschwunden. */
const verloren = vorherSpalten.filter((s) => !nachher.includes(s));
if (verloren.length) {
throw new Error(`Umbau: Spalten verloren: ${verloren.join(", ")}`);
}
d.exec("DROP TABLE mz_eintrag");
d.exec("ALTER TABLE mz_eintrag_neu RENAME TO mz_eintrag");
if (meine) d.exec("COMMIT");
console.log(`[manager-ziele] person_id auf SET NULL umgestellt --`
+ ` ${kopiert} Zeilen, ${nachher.length} Spalten (vorher ${vorherSpalten.length}).`);
} catch (fehler) {
if (meine) { try { d.exec("ROLLBACK"); } catch { /* schon zurueck */ } }
try { d.exec("DROP TABLE IF EXISTS mz_eintrag_neu"); } catch { /* egal */ }
console.error("[manager-ziele] Umbau abgebrochen:", fehler?.message);
throw fehler;
} finally {
if (warenAn) d.exec("PRAGMA foreign_keys = ON");
}
/* NACH dem Umbau nachsehen, ob die Verweise noch stimmen. Ein
Umbau mit abgeschalteten Fremdschluesseln kann sie hinterlassen,
ohne dass irgendetwas meckert. */
const kaputt = d.prepare("PRAGMA foreign_key_check(mz_eintrag)").all();
if (kaputt.length) {
console.error(`[manager-ziele] ACHTUNG: ${kaputt.length} Verweise zeigen ins Leere.`);
}
}
export function managerZieleTabellen(d) {
d.exec(TABELLEN);
umbauWennNoetig(d);
d.exec(TABELLEN); // nach einem Umbau fehlen die Indizes
/* EIN GEAENDERTER TRIGGER WIRD NICHT VON SELBST NEU (02.10.2026).
`CREATE TRIGGER IF NOT EXISTS` sieht den Namen, findet ihn und
tut nichts -- die alte Fassung bliebe stehen, und zwar fuer
immer. Deshalb wird nachgesehen, ob die geltende Fassung die
Ausnahme fuer ON DELETE SET NULL schon kennt; wenn nicht, kommt
sie weg und wird unten neu gebaut.
Erkannt am INHALT und nicht an einer Fassungsnummer: Eine Nummer
muesste jemand hochzaehlen, und genau das wird vergessen. */
try {
const alt = d.prepare(
"SELECT sql FROM sqlite_master WHERE type='trigger' AND name='mz_kein_alter_update'")
.get()?.sql || "";
if (alt && !alt.includes("NEW.person_id IS NULL")) {
d.exec("DROP TRIGGER mz_kein_alter_update");
console.log("[manager-ziele] Sperr-Trigger erneuert (laesst jetzt ON DELETE SET NULL durch).");
}
} catch (fehler) {
console.error("[manager-ziele] Trigger pruefen:", fehler?.message);
}
/* ---------- Die Sperre ------------------------------------------
Drei Trigger, einer je Richtung. Sie stehen hier und nicht in
@@ -284,9 +440,33 @@ export function managerZieleTabellen(d) {
SELECT RAISE(ABORT, 'monat_gesperrt');
END;
/* DIE AUSNAHME IN ZEILE DREI IST KEINE BEQUEMLICHKEIT, sondern die
Reparatur eines Fehlers, den die Pruefung gefunden hat
(02.10.2026).
ON DELETE SET NULL ist kein Loeschen -- es ist ein UPDATE auf
mz_eintrag.person_id. Dieser Trigger hat es als Aenderung an
einem abgeschlossenen Monat gesehen und abgebrochen. Folge:
Wer eine Person loeschen wollte, die irgendwann einmal etwas
eingetragen hatte, bekam 'monat_gesperrt' -- und die ganze
Personenverwaltung in workspace-personen.js waere daran
gescheitert, an einer Stelle, die mit Monatszielen nichts zu
tun hat.
Erlaubt ist deshalb genau EINE Aenderung an einem alten Monat:
dem Eintrag seinen Besitzer zu nehmen. Alles andere -- Datum,
Name, Link, Notiz -- bleibt gesperrt.
ALS BEDINGUNG UND NICHT ALS SPALTENLISTE (UPDATE OF ...):
Eine Liste muesste jemand pflegen, und beim Hinzufuegen der
naechsten Spalte wuerde sie vergessen -- dann waere die Sperre
dort still unwirksam. Diese Bedingung beschreibt, WAS erlaubt
ist, und gilt damit auch fuer jede Spalte, die es noch nicht
gibt. */
CREATE TRIGGER IF NOT EXISTS mz_kein_alter_update
BEFORE UPDATE ON mz_eintrag
WHEN OLD.monat <> (SELECT monat FROM mz_lage WHERE eins = 1)
AND NOT (NEW.person_id IS NULL AND OLD.person_id IS NOT NULL)
AND NOT ((SELECT offen FROM mz_freigabe WHERE eins = 1)
AND (SELECT bis FROM mz_freigabe WHERE eins = 1) > datetime('now'))
BEGIN
@@ -313,6 +493,7 @@ export function managerZieleTabellen(d) {
const fehlt = [
["name_klein", "TEXT"], ["link_klein", "TEXT"],
["doppelt_bei", "INTEGER REFERENCES personen(id) ON DELETE SET NULL"],
["von_name", "TEXT"], ["von_rolle", "TEXT"],
].filter(([spalte]) => !da.has(spalte));
for (const [spalte, typ] of fehlt) {
d.exec(`ALTER TABLE mz_eintrag ADD COLUMN ${spalte} ${typ}`);