/* ===================================================================== DER SUPPORT — Tabellen (24.09.2026) Filipe: „da fehlt auch eine support kachel. die jeder sieht. jeder benutzen kann. jeder kann da probleme von der seite melden und hinweisen. fotos mit schicken mit einem text. … es geht drum dass die leute einfach ein text mit einem foto schicken und dan die rechte hand und dogfather es bekommen. es sehen in dieser support kachel. also bei dogfather und der rechten hand soll die kachel anders gebaut sein weil die sind die die sich um die probleme kümmern." --------------------------------------------------------------------- WARUM DAS NICHT DER VERTRAULICHE MELDEWEG IST Es gibt ihn schon (hilfe.html, hilfe_faelle) und er sieht auf den ersten Blick gleich aus. Drei Unterschiede machen ihn zu etwas anderem: 1. ER IST NICHT FÜR ALLE. In rechte.js steht `"/workspace/hilfe.html": ["gast", "hand", "admin"]` — Modis, Creator, Scouts, Manager und die linke Hand haben ihn nicht. Das Team selbst hatte damit gar keinen Weg, einen kaputten Knopf zu melden. 2. ER KANN KEINE BILDER. Bei „der Knopf oben rechts tut nichts" ist ein Bildschirmfoto die halbe Antwort. Ein Meldeweg ohne Bild führt zu drei Rückfragen. 3. ER IST BEWUSST SCHWER. Strikter Wechsel (melden → warten → antworten → warten), drei offene Fälle höchstens, ein Betreff. Das ist richtig, wenn es um einen Vorfall zwischen Menschen geht. Für „das Datum steht falsch da" ist es zu viel. Deshalb eine eigene, sehr kurze Sache: EIN Feld, EIN Bild, fertig. Kein Betreff, keine Kategorie, keine Dringlichkeitsstufe. Wer ein Formular mit fünf Feldern sieht, meldet den kleinen Fehler nicht — und genau die kleinen sind es, die sonst niemand erfährt. --------------------------------------------------------------------- DREI STÄNDE, NICHT FÜNF „neu" Niemand hat es angesehen. „in_arbeit" Jemand kümmert sich — sichtbar auch für den Melder, damit er weiß, dass es angekommen ist. „erledigt" Zu. Mit einer Antwort, wenn es etwas zu sagen gab. Eine vierte Stufe („abgelehnt") gibt es absichtlich nicht. Ein Hinweis, den man nicht umsetzt, wird trotzdem erledigt — mit einem Satz warum. „Abgelehnt" ist eine Tür, die man dem zuschlägt, der sich die Mühe gemacht hat. --------------------------------------------------------------------- DAS BILD LIEGT AUF DER PLATTE, NICHT IN DER DATENBANK Dieselbe Entscheidung wie bei Chat-Anhängen und der Dateiablage: Ein Bildschirmfoto sind ein bis fünf Megabyte, und eine SQLite-Datei, die man täglich sichert, soll das nicht tragen. In der Tabelle steht nur der Dateiname; der Ordner steht in workspace-support.js über `join(DATEN_ORDNER, …)` — genau dieses Muster liest tools/wiederherstellung-proben.mjs, um zu prüfen, ob die Sicherung ihn mitnimmt. DIESE DATEI IMPORTIERT NICHTS — derselbe Grund wie bei hilfe-tabellen.js und treff-tabellen.js: Sie wird aus dem Bauplan in workspace.js aufgerufen und darf keinen Kreis erzeugen. ===================================================================== */ /** Die drei Stände einer Meldung. * * Hier und nicht als Zeichenkette an zwanzig Stellen — ein Tippfehler * in einem `WHERE stand = 'neu'` findet lautlos nichts. */ export const SUPPORT_STAND = { neu: "neu", inArbeit: "in_arbeit", /* ==== DER MELDER HAT DAS LETZTE WORT (25.09.2026) ================ Filipe: „ich will dass die leute die mir was geschickt haben im support, auch meine notiz bekommen wenn ich fertig bin. damit die bescheid wissen und dan anklicken koennen, es funktioniert, oder noch nicht. und erst wenn es funktioniert gedrueckt wird, will ich dass alles richtig fertig ist." WAS VORHER FEHLTE, und es ist der haeufigste Ausgang einer Fehlermeldung: Die Leitung macht zu, und niemand weiss, ob es beim Melder wirklich geht. Der merkt es beim naechsten Mal -- und meldet es nicht noch einmal, weil er denkt, es interessiert ja doch niemanden. „wartet" heisst: die Leitung hat geantwortet, und die Sache liegt beim MELDER. Er drueckt „geht wieder" (dann ist sie erledigt) oder „noch nicht" (dann geht sie zurueck in Arbeit -- und zwar in die naechste Runde, nicht an den Anfang). WARUM EINE VIERTE STUFE UND NICHT EIN HAEKCHEN AN „erledigt": Eine Meldung, die auf eine Antwort wartet, ist ein anderer Zustand als eine, die niemand angesehen hat -- sie gehoert in eine eigene Spalte und in eine eigene Zahl. Ein Merkmal an „erledigt" waere die Sorte Zustand, die man beim Zaehlen vergisst. */ wartet: "wartet", erledigt: "erledigt", }; /** Wie lange eine erledigte Meldung aufbewahrt wird. * * Neunzig Tage. Lang genug, um ein wiederkehrendes Problem zu * erkennen („das hatten wir im Juli schon"), kurz genug, dass * Bildschirmfotos aus dem Arbeitsalltag nicht ewig herumliegen. * Aufgeräumt wird im Rundgang, nicht beim Lesen — sonst hängt das * Löschen davon ab, dass jemand die Seite öffnet. */ export const AUFBEWAHRUNG_TAGE = 90; export function supportTabellen(d) { d.exec(` CREATE TABLE IF NOT EXISTS support_meldungen ( id INTEGER PRIMARY KEY AUTOINCREMENT, /* ON DELETE SET NULL und nicht CASCADE: Wird ein Zugang gelöscht, ist der gemeldete Fehler immer noch da. Die Meldung verliert ihren Absender, nicht ihren Inhalt. */ person_id INTEGER REFERENCES personen(id) ON DELETE SET NULL, /* Der Name wird MITGESCHRIEBEN, nicht nur verknüpft. Sonst steht nach einem Rollenwechsel oder einer Löschung „—" neben einer Meldung, zu der jemand etwas fragen möchte. */ von_name TEXT, von_rolle TEXT, text TEXT NOT NULL, /* WO ES PASSIERT IST. Kommt nicht aus einem Auswahlfeld, sondern aus der Adresse, von der aus gemeldet wurde — eine Angabe, die niemand tippen muss und die trotzdem stimmt. */ seite TEXT, /* Was der Browser über sich sagt, gekürzt. Bei „geht bei mir nicht" ist das die erste Frage, und sie erübrigt sich damit. */ geraet TEXT, bild_datei TEXT, bild_typ TEXT, bild_breite INTEGER, bild_hoehe INTEGER, stand TEXT NOT NULL DEFAULT 'neu' CHECK (stand IN ('neu','in_arbeit','wartet','erledigt')), /* DIE WIEVIELTE RUNDE (25.09.2026). Filipe: „mit dem gedanken das manchmal sachen mehrmal nicht sofort perfekt sein werden." Manches ist beim zweiten Anlauf immer noch nicht behoben. Die Zahl steht deshalb an der Meldung und auf dem Bildschirm -- „Runde 3" ist eine Auskunft, die man beim Lesen braucht, und sie sagt ohne Vorwurf, dass hier etwas haengt. */ runde INTEGER NOT NULL DEFAULT 1, antwort TEXT, erstellt TEXT NOT NULL, geaendert TEXT NOT NULL, erledigt_am TEXT, erledigt_von INTEGER REFERENCES personen(id) ON DELETE SET NULL ); /* ==== DER VERLAUF EINER MELDUNG (25.09.2026) ==================== Je Runde eine Zeile: was die Leitung geantwortet hat, und was der Melder daraufhin gesagt hat. WARUM NICHT EINFACH DAS FELD antwort UEBERSCHREIBEN: Dann staende bei der dritten Runde nur noch die dritte Antwort da -- und die Frage „was haben wir beim ersten Mal versucht?" waere nicht mehr zu beantworten. Genau die ist es, die einen wiederkehrenden Fehler loest. DIE ZEILE ENTSTEHT BEIM ANTWORTEN, nicht beim Melden: Runde 1 beginnt, wenn die Leitung das erste Mal sagt „so, probier mal". */ CREATE TABLE IF NOT EXISTS support_runden ( id INTEGER PRIMARY KEY AUTOINCREMENT, meldung_id INTEGER NOT NULL REFERENCES support_meldungen(id) ON DELETE CASCADE, nr INTEGER NOT NULL, antwort TEXT NOT NULL, von_id INTEGER REFERENCES personen(id) ON DELETE SET NULL, von_name TEXT, am TEXT NOT NULL, /* Was der Melder gesagt hat: 'geht' oder 'nicht'. NULL heisst „er hat noch nicht geantwortet" -- und das ist ein eigener, gueltiger Zustand, kein fehlender Wert. */ urteil TEXT CHECK (urteil IN ('geht','nicht')), urteil_text TEXT, urteil_am TEXT, /* ==== DAS BILD ZUR ANTWORT (02.10.2026) ==================== VanVan: „Wenn man hier im Support auf deine Frage 'geht es wieder' reagiert und antwortet, kann man auch kein Bild hinzufuegen. Das muesstest du auch noch hinzufuegen, damit man nochmal ein Bild anhaengen kann, wenn das Problem noch besteht oder sich durch die Aenderung ein neues Problem ergeben hat." Beim MELDEN gab es ein Bild von Anfang an, beim ANTWORTEN nicht. Dabei ist es dort mehr wert: „geht noch nicht" mit Bildschirmfoto sagt in einer Sekunde, was drei Saetze nicht treffen -- und ihr zweiter Satz nennt den Fall, an den ich nicht gedacht haette: durch die Aenderung ein NEUES Problem. AN DER RUNDE UND NICHT AN DER MELDUNG. Die Meldung hat schon ein Bild: das vom ersten Mal. Wuerde das hier ueberschrieben, waere nach Runde drei nicht mehr zu sehen, womit es angefangen hat -- genau die Frage, die einen wiederkehrenden Fehler loest. Es ist dieselbe Ueberlegung, aus der es diese Tabelle ueberhaupt gibt (siehe oben). */ urteil_bild_datei TEXT, urteil_bild_typ TEXT, urteil_bild_breite INTEGER, urteil_bild_hoehe INTEGER ); /* EINDEUTIG, NICHT NUR SCHNELL (25.09.2026). Hier stand ein gewoehnlicher Index. Dann faellt auf: Antwortet die Leitung ein zweites Mal, waehrend die Meldung schon beim Melder liegt, entsteht eine ZWEITE Zeile mit derselben Nummer -- und sein spaeteres „geht wieder" beschriftet dann beide auf einmal (das UPDATE trifft ueber meldung_id und nr -- KEINE Schraegstriche drum herum: Dieser Text steht in einem Template-Literal, und ein Gegen-Apostroph darin beendet es. Das hat heute Nacht schon einmal den Start gekostet). Der Verlauf zeigte zweimal „Runde 1" mit demselben Urteil. Der Index macht das unmoeglich, statt es zu verbieten. Die Route traegt seither mit ON CONFLICT nach: Wer nachlegt, ERSETZT seine Antwort in derselben Runde. Beides zusammen -- ohne den Index waere ON CONFLICT wirkungslos, ohne ON CONFLICT wuerde der Index das Nachlegen mit einem Fehler beantworten. UNBEDENKLICH BEIM UMSTELLEN: Die Tabelle ist in derselben Nacht entstanden; es gibt nur einen Weg, der sie fuellt. Gaebe es doch eine Dublette, schluege der Aufbau LAUT fehl statt still. UND WARUM DER NAME EIN ANDERER IST -- der eigentliche Fund: Hier stand zuerst CREATE UNIQUE INDEX IF NOT EXISTS unter dem ALTEN Namen. Lokal war alles gruen, weil jede Pruefung ihre Datenbank frisch anlegt. Auf dem Server gab es den Namen aber schon, als gewoehnlichen Index -- und IF NOT EXISTS sieht nur den NAMEN, nicht die Bauart. Der Index waere also nie eindeutig geworden, ON CONFLICT haette kein Ziel gefunden, und das Nachlegen waere mit einem Fehler abgebrochen. GENAU DORT, wo lokal alles gruen ist. Aufgefallen beim Durchspielen auf einer Kopie der echten Datenbank, nicht in der Pruefung. Deshalb: den alten ausdruecklich wegnehmen, den neuen unter eigenem Namen anlegen. Beides vertraegt jede Wiederholung. */ DROP INDEX IF EXISTS idx_support_runden_meldung; CREATE UNIQUE INDEX IF NOT EXISTS idx_support_runden_einmal ON support_runden (meldung_id, nr); /* Die Leitung fragt „was ist offen?", der Melder „was ist meins?". Zwei Indizes für zwei Fragen. */ CREATE INDEX IF NOT EXISTS idx_support_stand ON support_meldungen(stand, id DESC); CREATE INDEX IF NOT EXISTS idx_support_person ON support_meldungen(person_id, id DESC); /* ==== MEHRERE BILDER JE MELDUNG (02.10.2026) ================== VanVan im Support, Meldung #11 -- VIERMAL gemeldet: „Hier im Supportbereich kann man immer nur ein Bild hinzufügen bei einer Meldung. 2-3 wären besser." Und in Runde 2: „wenn man es nacheinander versucht hinzuzufügen wird das Bild immer nur ersetzt." KEINE GEGEN-APOSTROPHE IN DIESEM TEXT. Er steht in einem Template-Literal, und einer davon beendet es -- der Server startet dann gar nicht mehr. Genau das ist in der Nacht zum 25.09. schon einmal passiert, zwanzig Zeilen weiter unten steht die Warnung dazu, und beim Schreiben dieses Kommentars ist es trotzdem wieder passiert. Ein Kommentar, der vor einem Fehler warnt, verhindert ihn nicht. EINE TABELLE FUER ALLE SUPPORTBILDER, nicht drei Spaltensaetze nebeneinander. Die Alternative waere gewesen, bild2_datei, bild3_datei danebenzustellen -- und beim vierten Bild wieder. Eine Zeile je Bild kennt keine Obergrenze im Schema; die Grenze steht an EINER Stelle im Code (BILDER_MAX) und laesst sich dort aendern, ohne die Datenbank anzufassen. runde_nr SAGT, WOZU ES GEHOERT: NULL heisst „zur Meldung selbst", eine Zahl heisst „zur Antwort in dieser Runde". Damit braucht es keine zweite Tabelle fuer die Runden -- es ist dieselbe Frage („welches Bild gehoert hierhin?"), und zwei Tabellen waeren zwei Antworten darauf. DIE REIHENFOLGE IST DIE DES HOCHLADENS (die id). Eine eigene Spalte nr waere eine Zahl, die jemand pflegen muss, sobald ein Bild dazwischen weggeht. */ CREATE TABLE IF NOT EXISTS support_bilder ( id INTEGER PRIMARY KEY AUTOINCREMENT, meldung_id INTEGER NOT NULL REFERENCES support_meldungen(id) ON DELETE CASCADE, runde_nr INTEGER, datei TEXT NOT NULL, typ TEXT, breite INTEGER, hoehe INTEGER, erstellt TEXT NOT NULL ); CREATE INDEX IF NOT EXISTS idx_support_bilder ON support_bilder (meldung_id, runde_nr, id); `); /* ==== NACHTRAGEN, WAS `IF NOT EXISTS` NICHT NACHTRAEGT ============ (02.10.2026) Die Tabelle oben entsteht nur beim ERSTEN Mal. Auf einer Datenbank, die es schon gibt -- also auf dem Server -- sieht `CREATE TABLE IF NOT EXISTS` den Namen, findet ihn, und ist fertig. Die vier neuen Spalten fuer das Bild zur Antwort kaemen dort nie an: Lokal waere alles gruen, weil jede Pruefung ihre Datenbank frisch anlegt, und live schluege das Schreiben fehl. GENAU DIESER FEHLER steht zwanzig Zeilen weiter oben schon einmal beschrieben -- dort war es ein Index, der live nie eindeutig wurde, weil `IF NOT EXISTS` nur den NAMEN sieht und nicht die Bauart. Es ist dieselbe Falle, nur eine Tuer weiter. ABGELEITET STATT ABGESCHRIEBEN: Gefragt wird die Tabelle selbst (`PRAGMA table_info`), nicht eine gepflegte Liste. Eine Liste, die niemand pflegt, kann nicht veralten -- die am 11.09. hat drei Spalten gekostet. */ for (const [spalte, typ] of [ ["urteil_bild_datei", "TEXT"], ["urteil_bild_typ", "TEXT"], ["urteil_bild_breite", "INTEGER"], ["urteil_bild_hoehe", "INTEGER"], ]) { try { const vorhanden = d.prepare("PRAGMA table_info(support_runden)").all() .map((s) => s.name); if (vorhanden.length && !vorhanden.includes(spalte)) { d.exec(`ALTER TABLE support_runden ADD COLUMN ${spalte} ${typ}`); console.log(`[support] Spalte '${spalte}' in support_runden ergaenzt.`); } } catch (fehler) { console.error(`[support] Spalte '${spalte}':`, fehler?.message); } } /* ==== DIE VORHANDENEN BILDER WANDERN MIT (02.10.2026) ============ Ohne diesen Schritt haette die neue Tabelle ab heute recht und die acht Bilder von vorher waeren unsichtbar -- ein Umbau, der Daten verliert, ohne dass etwas rot wird. Genau die Sorte, die am 11.09. drei Spalten gekostet hat. ERST HIER, NICHT WEITER OBEN. Gelesen wird `urteil_bild_datei` aus `support_runden` -- und diese Spalte gibt es in einer bestehenden Datenbank erst, nachdem die Nachruestung direkt darueber gelaufen ist. Haette der Umzug oben gestanden, waere er genau dort gescheitert, wo es darauf ankommt: live. Lokal waere nichts aufgefallen, weil jede Pruefung ihre Datenbank frisch anlegt und `CREATE TABLE` die Spalte dann gleich mitbringt. ZWEIMAL AUSFUEHRBAR: Eingetragen wird nur, wo es noch keine Zeile gibt. Ein zweiter Start darf nichts verdoppeln. DIE ALTEN SPALTEN BLEIBEN STEHEN und werden ab jetzt nicht mehr GESCHRIEBEN. Sie wegzunehmen hiesse, die Tabelle neu zu bauen -- und genau dabei gingen am 11.09. die drei Spalten verloren. Gelesen wird ab jetzt nur noch `support_bilder`; die alten Felder sind Geschichte, kein zweiter Weg daneben. */ try { const n = new Date().toISOString(); const ausMeldung = d.prepare(` INSERT INTO support_bilder (meldung_id, runde_nr, datei, typ, breite, hoehe, erstellt) SELECT m.id, NULL, m.bild_datei, m.bild_typ, m.bild_breite, m.bild_hoehe, COALESCE(m.erstellt, ?) FROM support_meldungen m WHERE m.bild_datei IS NOT NULL AND NOT EXISTS (SELECT 1 FROM support_bilder b WHERE b.meldung_id = m.id AND b.runde_nr IS NULL AND b.datei = m.bild_datei)`).run(n); const ausRunde = d.prepare(` INSERT INTO support_bilder (meldung_id, runde_nr, datei, typ, breite, hoehe, erstellt) SELECT r.meldung_id, r.nr, r.urteil_bild_datei, r.urteil_bild_typ, r.urteil_bild_breite, r.urteil_bild_hoehe, COALESCE(r.urteil_am, ?) FROM support_runden r WHERE r.urteil_bild_datei IS NOT NULL AND NOT EXISTS (SELECT 1 FROM support_bilder b WHERE b.meldung_id = r.meldung_id AND b.runde_nr = r.nr AND b.datei = r.urteil_bild_datei)`).run(n); const mit = (ausMeldung.changes || 0) + (ausRunde.changes || 0); if (mit) console.log(`[support] ${mit} vorhandene Bilder nach support_bilder uebernommen.`); } catch (fehler) { console.error("[support] BILDER NICHT UEBERNOMMEN:", fehler?.message); } }