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. perfektionier den ganzen weg und mit dem gedanken das manchmal sachen mehrmal nicht sofort perfekt sein werden." DER GANZE WEG, nicht nur der Schlusspunkt: 1. Die Leitung drueckt "Behoben - nachfragen ...". Der Knopf hiess vorher "Erledigt ..." und tat auch das; jetzt stellt er eine Frage, also heisst er auch so. Eine Beschriftung, die etwas anderes sagt als der Knopf tut, glaubt man genau einmal. 2. Die Meldung steht auf "wartet" -- ein vierter Stand zwischen "wird bearbeitet" und "erledigt". Beim Melder heisst er "geht es wieder?", weil er aus SEINER Sicht keine Wartezeit ist, sondern eine Frage. 3. Er sieht die Notiz und zwei Knoepfe. "Geht wieder" ohne Rueckfrage (der haeufige, harmlose Fall). "Noch nicht" verlangt ein Wort -- sonst faengt die Suche von vorn an und die naechste Runde waere dieselbe wie die letzte. 4. "Noch nicht" ist keine Beschwerde, sondern Runde 2: zurueck in Arbeit, Rundenzahl plus eins, Leitung bekommt eine Nachricht, und der Verlauf behaelt, was beim letzten Mal versucht wurde. Niemand faengt von vorn an -- genau der Fall, den Filipe genannt hat. 5. Erst sein "Geht wieder" schliesst die Meldung. Danach kann weder er noch die Leitung sie wieder aufmachen (409). NUR DER MELDER darf bestaetigen, ausdruecklich nicht die Leitung (`person_id !== req.person.id`, nicht "ist Leitung") -- sonst nickt sie ihre eigene Arbeit ab und der ganze Umweg waere Zierde. Eine fremde Meldung gibt 404, nicht 403: Wer sie nicht sehen darf, soll auch nicht erfahren, dass es sie gibt. DER VERLAUF STEHT UNTEREINANDER statt nur der letzten Antwort. Bei Runde drei war sonst nicht mehr zu sehen, was beim ersten Mal versucht wurde, und genau das loest einen wiederkehrenden Fehler. Meldungen von vor diesem Umbau haben keinen Verlauf -- die zeigen wie bisher ihre blosse Antwort, ein leerer Kasten waere schlechter als der alte Satz. DIE KACHEL SIEHT ANDERS AUS (zweiter Wunsch: "viel geiler viel profissioneller ... die hauptfarbe soll babyblau sein mit bissl lila"). `support-seite` traegt den Stil; alle Regeln haengen daran und gelten damit nur hier. Zwei weiche Lichter, Pillen statt Kaesten als Filter, eine leuchtende Naht ueber dem Meldefeld. Augenschonend: gedeckt, kein Neon, Kontrast geprueft. GEMESSEN: - pruef-support: 45 -> 58 Pruefungen, 0 Fehler. Der ganze Weg einmal durch, MIT einer Runde, die schiefgeht. Dazu drei Gegenproben: die Leitung kann nicht fuer den Melder bestaetigen (404), "noch nicht" ohne Wort wird abgelehnt (400), eine geschlossene Meldung bleibt zu (409, aus beiden Richtungen). - Die Schemaaenderung auf einer KOPIE der echten Datenbank durchgespielt: 72 Tabellen, keine Zeile und keine Spalte verloren, support_runden und `runde` da, 'wartet' in der CHECK-Regel. - pruef-css-klassen, pruef-deutsche-texte, pruef-code, pruef-glocke: alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]>
196 lines
8.9 KiB
JavaScript
196 lines
8.9 KiB
JavaScript
/* =====================================================================
|
|
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
|
|
);
|
|
CREATE INDEX IF NOT EXISTS idx_support_runden_meldung
|
|
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);
|
|
`);
|
|
}
|