Support: Babyblau mit Lila, und der Melder bekommt seine Knoepfe wirklich

Nachtrag zu cebdd88e. Ein Bildschirmfoto der fertigen Seite hat drei
Dinge gezeigt, die keine Pruefung sehen konnte.

1. DIE KACHEL WAR IMMER NOCH ORANGE.

   Filipe: "die hauptfarbe der kachel soll auch babyblau sein mit bissl
   lila." Die Seite trug zwar `--akzent: #a8d8ff`, aber der Kopf faerbt
   sich ueber `--ton` -- und der stand am body auf Ton 44, dem Orange
   vom 24.09. Die Variable war gesetzt und wirkungslos.

   Ton 44 ist jetzt #a8d8ff. WEIL DIE FARBE DIESMAL AUS EINEM WUNSCH
   kam und nicht aus einer Rechnung, wurde sie nachgemessen:

     Kontrast gegen den dunklen Grund   12,46:1   (Hausgrenze 4,5)
     Abstand zur naechsten Kachelfarbe  0,1125    (Ton 15)
     Engstes Paar im Haus ohnehin       0,0154
     -> 7,3-fach weiter weg als das schwaechste Glied

   Babyblau haelt die Buntheitsgrenze (0,12) NICHT und kann sie nicht
   halten -- das liegt am Wort. Nachgemessen mit einer Suche ueber den
   ganzen Blaubereich: Es gibt KEINE Farbe, die gleichzeitig babyblau
   aussieht, Buntheit >= 0,12 und Abstand >= 0,09 schafft; der beste
   Kandidat kommt auf 0,075 Abstand. Der Blaubereich ist von sechs
   Toenen besetzt.

   DIE GRENZE WURDE DESHALB NICHT GESENKT, sondern BENANNT ausgenommen
   (`blassErlaubt` in pruef-kachelfarben). Eine gesenkte Grenze gaelte
   fuer alle 45 Toene; eine benannte gilt fuer eine und steht mit
   ihrem Grund da. Und sie kostet etwas: Wer blass sein darf, muss
   beim Abstand >= 0,10 halten -- gemessen, nicht versprochen, mit
   Gegenprobe.

   NEBENBEI ZWEI ALTE ROTE BEHOBEN: Die Prüfung war seit dem 24.09.
   rot (engstes Paar 0,0862 zwischen Ton 41 und 45, und zwei Farben in
   der Regenbogenkachel stimmten nicht mehr). Ton 45 neu gerechnet
   (0,0914) und die Kachel nachgezogen. 22 -> 26 Pruefungen, 0 Fehler.

2. DIE LEITUNG SAH DIE KNOEPFE DES MELDERS.

   Der Server lehnte sie richtig mit 404 ab -- die Karte bot sie ihr
   trotzdem an. `darf_bestaetigen` war eine Aussage ueber die MELDUNG
   statt ueber den BETRACHTER. Zwei Knoepfe, die nur eine Fehlermeldung
   koennen, sind schlimmer als gar keine.

   Jetzt fragen Route UND Anzeige dieselbe Funktion `darfBestaetigen`.
   Es ist ausdruecklich "ist der Melder" und nicht "ist nicht Leitung":
   Die Leitung darf ihre EIGENE Meldung bestaetigen, nur keine fremde.

   Und die Leitung sieht bei "wartet" jetzt, wer dran ist -- "Liegt bei
   Miss" mit ruhig atmendem Punkt, dazu "Noch etwas nachschicken ..."
   statt "Behoben - nachfragen ...". Sie hat ja schon nachgefragt.

3. NACHLEGEN HAETTE DEN VERLAUF VERDOPPELT.

   Antwortet die Leitung ein zweites Mal, waehrend die Meldung beim
   Melder liegt, entstand eine ZWEITE Zeile "Runde 1" -- und sein
   spaeteres Urteil haette beide gleichzeitig beschriftet. Jetzt
   ersetzt ON CONFLICT die Antwort in derselben Runde.

   DER EIGENTLICHE FUND STECKTE IM INDEX: `CREATE UNIQUE INDEX IF NOT
   EXISTS` unter dem alten Namen tut auf dem Server NICHTS -- dort gibt
   es den Namen schon, als gewoehnlichen Index, und IF NOT EXISTS
   sieht nur den Namen, nicht die Bauart. Der Index waere nie eindeutig
   geworden, ON CONFLICT haette kein Ziel gefunden, und das Nachlegen
   waere abgebrochen -- genau dort, wo lokal alles gruen ist, weil jede
   Pruefung ihre Datenbank frisch anlegt. Gefunden beim Durchspielen
   auf einer KOPIE der echten Datenbank. Der alte Index wird jetzt
   ausdruecklich weggenommen, der neue heisst anders.

GEMESSEN:
- pruef-support 59 -> 63 Pruefungen, 0 Fehler (darunter: die Leitung
  bekommt die Knoepfe NICHT, und Nachlegen laesst EINE Runde stehen).
- Die Index-Umstellung auf einer Kopie der echten Datenbank
  durchgespielt: alter Index weg, neuer eindeutig, ON CONFLICT trifft.
- pruef-kachelfarben 26/0, pruef-css-klassen, pruef-deutsche-texte: gruen.
- server/mess-support-runde.mjs (neu) macht vier Bilder: Leitung,
  Melder, Melder auf dem Handy, und den Verlauf nach zwei Runden.
  Es misst den "wer ist dran"-Hinweis ausdruecklich mit -- der war
  einmal stumm ausgefallen (before() auf einem Element ohne
  Elternknoten tut nichts, ohne Fehlermeldung).

Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
2026-09-25 05:10:58 +02:00
co-authored by Claude Opus 5
parent cebdd88e8d
commit 257c01b8f0
49 changed files with 1158 additions and 688 deletions
+46 -9
View File
@@ -111,6 +111,23 @@ function meldungFuer(person, id) {
return m.person_id === person?.id ? m : null;
}
/** Darf DIESE Person bei DIESER Meldung jetzt bestätigen?
*
* AN EINER STELLE, weil es zwei Stellen gibt, die es wissen müssen:
* die Route, die die Antwort annimmt, und die Anzeige, die die
* Knöpfe zeigt. Standen sie getrennt da, driften sie — und genau das
* ist am 25.09.2026 im ersten Anlauf passiert: Der Server lehnte die
* Leitung richtig mit 404 ab, die Karte zeigte ihr die Knöpfe
* trotzdem. Zwei Knöpfe, die nur eine Fehlermeldung können, sind
* schlimmer als gar keine.
*
* ES IST DER MELDER, NICHT „WER NICHT LEITUNG IST": Die Leitung darf
* ihre eigene Meldung sehr wohl selbst bestätigen — sie hat sie ja
* geschrieben. Verboten ist nur, FREMDE Arbeit abzunicken. */
function darfBestaetigen(m, personId) {
return !!m && m.person_id === personId && m.stand === SUPPORT_STAND.wartet;
}
/** Wie eine Meldung nach draußen aussieht.
*
* AN EINER STELLE, weil vier Routen sie ausgeben. Vier Stellen wären
@@ -119,8 +136,13 @@ function meldungFuer(person, id) {
*
* `fuerLeitung` entscheidet nur über die Zusatzangaben, nicht über
* den Inhalt: Wer meldet, sieht seine eigene Meldung vollständig,
* auch den Namen, den er selbst trägt. */
function nachDraussen(m, fuerLeitung) {
* auch den Namen, den er selbst trägt.
*
* `werFragtId` ist Pflicht, seit es die Knöpfe des Melders gibt —
* ohne sie ist `darf_bestaetigen` eine Aussage über die Meldung
* statt über den Betrachter, und die Leitung bekommt Knöpfe, die sie
* nicht drücken darf. */
function nachDraussen(m, fuerLeitung, werFragtId) {
return {
id: m.id,
text: m.text,
@@ -162,7 +184,7 @@ function nachDraussen(m, fuerLeitung) {
/* DARF ICH JETZT BESTAETIGEN? Vom Server beantwortet, nicht im
Browser nachgerechnet: Dort stuende die Regel ein zweites Mal,
und die zweite Fassung waere ab der naechsten Aenderung falsch. */
darf_bestaetigen: m.stand === SUPPORT_STAND.wartet,
darf_bestaetigen: darfBestaetigen(m, werFragtId),
};
}
@@ -202,7 +224,7 @@ supportRouter.get("/workspace/api/support", (req, res) => {
res.json({
leitung,
meldungen: zeilen.map((m) => nachDraussen(m, leitung)),
meldungen: zeilen.map((m) => nachDraussen(m, leitung, req.person.id)),
/* Die Zahlen stehen in der Antwort und werden nicht im Browser
nachgezählt: Die Liste ist bei 300 abgeschnitten, eine Zählung
darauf wäre ab der 301. Meldung still falsch. */
@@ -347,7 +369,9 @@ supportRouter.post("/workspace/api/support",
}
const frisch = db().prepare("SELECT * FROM support_meldungen WHERE id = ?").get(id);
res.status(201).json({ meldung: nachDraussen(frisch, istLeitung(req.person)) });
res.status(201).json({
meldung: nachDraussen(frisch, istLeitung(req.person), req.person.id),
});
} catch (fehler) {
/* DIE DATEI GEHT MIT, WENN DIE ZEILE NICHT ZUSTANDE KAM. Sonst
sammelt der Ordner Bilder an, zu denen es keine Meldung gibt —
@@ -409,7 +433,12 @@ supportRouter.post("/workspace/api/support/:id/rueckmeldung",
if (!m || m.person_id !== req.person.id) {
return res.status(404).json({ fehler: "nicht_gefunden" });
}
if (m.stand !== SUPPORT_STAND.wartet) {
/* 404 oben war die SICHTBARKEITSFRAGE, das hier ist die
STANDFRAGE -- zwei verschiedene Auskünfte, deshalb zwei Codes.
Gefragt wird mit derselben Funktion, die auch die Knöpfe
zeigt: Was der Bildschirm anbietet und was der Server annimmt,
ist damit ein Satz und nicht zwei. */
if (!darfBestaetigen(m, req.person.id)) {
return res.status(409).json({
fehler: "Hier wartet gerade nichts auf deine Antwort.",
});
@@ -468,7 +497,7 @@ supportRouter.post("/workspace/api/support/:id/rueckmeldung",
}
const frisch = db().prepare("SELECT * FROM support_meldungen WHERE id = ?").get(m.id);
res.json({ meldung: nachDraussen(frisch, false) });
res.json({ meldung: nachDraussen(frisch, false, req.person.id) });
} catch (fehler) {
console.error("[support] Rueckmeldung:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
@@ -559,9 +588,17 @@ supportRouter.patch("/workspace/api/support/:id(\\d+)", express.json(), (req, re
entsteht hier und nicht beim Melden: Runde 1 beginnt mit dem
ersten „so, probier mal", nicht mit dem Problem. */
if (stand === SUPPORT_STAND.wartet && antwort) {
/* NACHLEGEN ERSETZT, ES VERDOPPELT NICHT. Antwortet die Leitung
ein zweites Mal, waehrend die Meldung schon beim Melder liegt
(„ach, und noch etwas ..."), gehoert das in DIESELBE Runde.
Ohne diese Zeile stuenden zwei „Runde 1" untereinander, und
sein spaeteres Urteil traefe beide gleichzeitig. */
db().prepare(`INSERT INTO support_runden
(meldung_id, nr, antwort, von_id, von_name, am)
VALUES (?,?,?,?,?,?)`)
VALUES (?,?,?,?,?,?)
ON CONFLICT (meldung_id, nr) DO UPDATE
SET antwort = excluded.antwort, von_id = excluded.von_id,
von_name = excluded.von_name, am = excluded.am`)
.run(m.id, m.runde || 1, antwort, req.person.id, req.person.name, n);
}
@@ -588,7 +625,7 @@ supportRouter.patch("/workspace/api/support/:id(\\d+)", express.json(), (req, re
}
const frisch = db().prepare("SELECT * FROM support_meldungen WHERE id = ?").get(m.id);
res.json({ meldung: nachDraussen(frisch, true) });
res.json({ meldung: nachDraussen(frisch, true, req.person.id) });
} catch (fehler) {
console.error("[support] Bearbeiten:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });