ZWEI WUENSCHE VON FILIPE.
1) KACHELN BESSER SICHTBAR
Erster Versuch war zu zaghaft: die Flaeche ging nur von RGB(17,24,37)
auf (27,36,51), der sichtbare Gewinn kam fast nur vom staerkeren Rand.
Nachgemessen an echten Bildpunkten -- Seite liegt bei RGB(5,7,13).
Jetzt RGB(38,49,67), dazu kraeftigerer Rand und hellerer Symbolring.
Der Beschreibungstext stand auf --text-still und lag damit bei 3,6:1 auf
der neuen Flaeche -- zu blass fuer laufenden Text. Jetzt --text-leise,
gemessen 6,2:1.
Leere Kategorien waren mit opacity .55 fast unlesbar. Jetzt .82 -- sie
sollen erkennbar bleiben, nur zurueckhaltender.
2) DATEIEN AN MEHRERE PERSONEN GEZIELT FREIGEBEN
Bisher hatte eine Datei genau EINEN Bereich (creator_id). Damit liess
sie sich nicht zweien geben, ohne sie zweimal hochzuladen.
Neue Tabelle datei_personen (datei_id + person_id). creator_id bleibt
und behaelt seine Bedeutung: Es sagt, zu wessen BEREICH eine Datei
gehoert -- die neue Tabelle sagt, WER sie sehen darf. Zwei verschiedene
Fragen, deshalb zwei Felder.
Auswahl als einzelne Schalter, nicht als <select multiple>: Dort
verliert man mit einem Fehlklick die ganze Auswahl, und auf dem Handy
ist sie kaum bedienbar. Jeder Name ist ein Schalter, der sichtbar an
oder aus ist, eingefaerbt nach Rolle -- man sieht auf einen Blick, ob
eine Datei an Creator, Scouts oder beide geht.
Wer wen auswaehlen darf:
- DogFather jeden aktiven Menschen ausser sich selbst
- ein Scout NUR die Creator, die er betreut -- sonst koennte er sich
ueber eine Freigabe Zugang zu fremden Bereichen verschaffen
- ein Creator gar niemanden
Jede Id wird beim Speichern erneut gegen die erlaubte Auswahl geprueft.
Geprueft: Sam schickt die Ids 3, 6 und 7 mit (alles Creator, die er
NICHT betreut) -- die Datei landet bei niemandem. Kein Fehler, kein
Zugang: die Ids fallen still durch das Raster.
Weiter geprueft:
- Chef sieht alle drei Testdateien, Luna nur ihre, Sam nur seine,
Patrick keine
- Creator bekommt 403 beim Aendern von Freigaben
- Freigaben sind an jeder Datei sichtbar ("Sichtbar fuer ..."), auch
fuer die, die sie nicht aendern duerfen -- niemand soll raten muessen
- Die Auswahl wird nach dem Hochladen geleert, sonst bekaeme die
naechste Datei stillschweigend dasselbe Publikum
Filipe sah die neue Kachel nicht, obwohl sie live war. Ursache gemessen,
nicht vermutet:
Node liefert : Cache-Control: no-cache (richtig)
Cloudflare macht: Cache-Control: max-age=14400 (ueberschreibt es)
cf-cache-status: REVALIDATED, Server: cloudflare
Cloudflares voreingestellte Browser-Cache-Zeit von vier Stunden setzt
sich ueber das no-cache des Servers hinweg -- aber NUR bei JS und CSS.
HTML kommt mit DYNAMIC und no-cache immer frisch durch (geprueft an
/creator.html und /workspace/).
Genau deshalb genuegt ein Stempel in der HTML: neue Seite -> neue
Adresse -> Cloudflare kennt sie nicht -> frische Datei. Keine
Cloudflare-Einstellung noetig, nichts, worauf ich warten muss.
tools/workspace-stempel.mjs setzt den Stempel auf alle 71 Verweise in
13 Dateien. Der Lauf ist wiederholbar: ein vorhandener Stempel wird
ersetzt, nicht angehaengt (geprueft).
Gehoert ab jetzt vor jeden Deploy, der JS oder CSS im Workspace anfasst.
Ich verlasse mich damit nicht mehr aufs Erinnern -- das war der
eigentliche Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
Fuenf Bereiche auf einmal, aber NICHT fuenf Module. Im Deck haben sie
dieselbe Grundform: Eintraege zu einem Creator mit Art, Datum, Titel,
Text und Status. Sie unterscheiden sich nur darin, welche Arten es gibt
und ob eine Bewertung oder eine Dringlichkeit dazugehoert.
Deshalb ein gemeinsamer Unterbau: eine Tabelle, eine Sichtbarkeitsregel,
eine Pruefung, eine Ansichtsseite (bereich.html?b=live). Ein Fehler
laesst sich damit an EINER Stelle beheben statt an fuenf, und ein
weiterer Bereich waere ein Eintrag in BEREICHE -- kein neues Modul.
Arten woertlich aus dem Deck (Seiten 7-12):
live Vorbereitung / Waehrend LIVE / Auswertung + Bewertung 1-5
content Idee / Produktion / Veroeffentlicht
technik Setup / Problem / Loesung / Anleitung + Dringlichkeit
community Moderation / Aktion / Konflikt + Dringlichkeit
schutz Richtlinie / Vorfall / Eskalation / Gelernt + Dringlichkeit
Die Oberflaeche kennt die Bereiche nicht auswendig -- welche Arten und
Zusatzfelder es gibt, sagt der Server in der Antwort.
Geprueft, und zwar fuer alle fuenf gleichzeitig:
- Sichtbarkeit: Chef sieht alles, Luna nur ihren Bereich, Mika nur
seinen, Sam (Scout) gar nichts (404 -- Scouts haben mit der
Creator-Betreuung nichts zu tun)
- Luna legt Eintrag mit creator_id=Mika an: landet still in ihrem
eigenen Bereich, Mika sieht ihn nicht
- Luna auf Mikas Eintrag: 404; Luna loescht Chefs Eintrag ueber ihren
Bereich: 403 (loeschen darf das Management und wer ihn schrieb --
sonst koennte ein Creator eine Notiz ueber sich verschwinden lassen)
- Eintrag ueber den falschen Bereich in der Adresse ansprechen: 404
- unbekannte Art 400, Bewertung 9 (erlaubt 1-5) 400, unbekannter
Bereich 404, fremde Herkunft 403
Beim Testen sahen Umlaute zunaechst zerstoert aus (efbfbd, das
Unicode-Ersatzzeichen). Ursache war der curl-Aufruf: Git Bash kodiert
$'\xc3\xbc' nach Locale um. Ueber den echten Weg (Browser) kommen
Umlaute, ss und Gedankenstrich unveraendert an und liegen sauber in der
Datenbank -- gegengeprueft auf Byte-Ebene.
DogFatherGit
