dogfather-universe/server/support-tabellen.js

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

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