/* ===================================================================== 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 ); /* 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); `); }