Commit Graph
8 Commits
Author SHA1 Message Date
DogFatherGitandClaude Opus 5 7acd7a7674 Das Suchfeld nimmt wieder Eingaben, eigene Kanalnamen, Community in Kanälen
screen1, drei Teile.

=== 1. „bei suchen kann man nichts reinschreiben" ===

MEIN FEHLER VOM SELBEN TAG. Beim Popover-Umbau heute frueh hing die
Liste am <body>, damit sie nicht hinter dem modalen Dialog
verschwindet. Gemessen: Das Suchfeld war da, der Fokus landete nicht
darin, ein getipptes Zeichen kam nicht an.

DER GRUND IST DER FOKUS-KAEFIG. Ein Dialog aus showModal() sperrt den
Fokus auf seinen eigenen DOM-Baum ein. Die Liste lag im Top Layer --
sichtbar und anklickbar, aber ausserhalb des Kaefigs. Klicken braucht
keinen Fokus, Tippen schon. Deshalb fiel es niemandem auf: Die Liste
stand da, sie filterte auf Knopfdruck, nur eine Eingabe kam nicht an.

DIE LOESUNG WAR EINE KOMBINATION, die ich vorher fuer unmoeglich
hielt. Im Dialog wurde die Liste vom clip-path der abgeschraegten
Ecke abgeschnitten, draussen war sie nicht bedienbar. Ein POPOVER
wird aber in die Top Layer gehoben und dort gezeichnet -- der
Beschnitt des Elternteils erreicht es nicht mehr, waehrend der
DOM-Baum (und damit der Fokus) der des Dialogs bleibt. Jetzt haengt
sie wieder im Dialog UND ist ein Popover: bedienbar und unbeschnitten.

Gemessen beides gegeneinander: „comm" getippt -> kommt an, filtert auf
1 Treffer; und die LETZTE Zeile der vollen Liste ist wirklich
anklickbar (elementFromPoint trifft sie selbst, nicht den Dialog).
Daraus ist pruef-suchfeld geworden -- der Fehler war von aussen nicht
zu sehen, und gefunden hat ihn Filipe, nicht ich.

=== 2. „einen neuen namen erstellen den es noch nicht gibt" ===

`data-frei="ja"` war in wahl.js seit langem gebaut und wurde NIE
GESETZT -- dieselbe Sorte Lueue wie `grund_min` heute Morgen. Jetzt
gesetzt; der getippte Text erscheint als eigener Eintrag ganz oben.

Der Server nahm bisher nur die neun festen Zustaendigkeiten. Jetzt
auch einen eigenen Namen: Der SCHLUESSEL wird daraus abgeleitet
(„Technik & Ton" -> "eigen-technik-ton"), der ANGEZEIGTE Name bleibt
wie geschrieben. Das Praefix ist kein Schmuck -- ohne es entstuende
aus dem Namen „Community" derselbe Schluessel wie beim festen Thema,
und der eindeutige Index lehnte ihn ab, obwohl der Kanal nicht
existiert. Gemessen: genau dieser Fall antwortet jetzt mit 201.

Der alte Kommentar sprach sich gegen freie Namen aus („der sichere
Weg zu Clipping neben Clipping-Team"). Das Risiko bleibt und wird
begrenzt: Derselbe Name zweimal ergibt denselben Schluessel und damit
409.

=== 3. „kanäle mit den leuten mit der community rolle" ===

Seit dem 19.09. nimmt `ohneAussen()` die Community aus den Listen
aller anderen. Die Begruendung dort ist ausdruecklich: „Ein
Zweier-Gespraech ist kein Kanal. Es hat keine Nachtruhe, kein Modi
liest mit, und niemand koennte moderieren."

Genau diese Begruendung laesst den Kanal offen. Die Sperre bleibt
fuer GESPRAECHE und faellt fuer KANAELE -- `?fuer=kanal` an der
Partnerliste, und nur fuer den, der Kanaele ueberhaupt aufmachen
darf. Sonst waere der Parameter ein Weg, an `ohneAussen` vorbei Namen
zu erfahren.

Gemessen: DogFather sieht im Gespraech VanVan und Miss, im Kanal
zusaetzlich Kessi und Tom (beide Community). Ein Modi bekommt die
erweiterte Liste auch mit dem Parameter nicht.

Gruen: pruef-suchfeld (8, neu), pruef-chat-kanaele (81),
pruef-treffchat, pruef-chat-neu, pruef-freie-namen (32),
pruef-nachfrage (53), pruef-css-klassen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-24 11:37:03 +02:00
DogFatherGitandClaude Opus 5 08ff3e5e40 Die Liste im Dialog rollt, das Anschlagbrett schreibt nicht mehr ab
Zwei Dinge aus Filipes Durchgang.

ERSTENS: "das hoch und runter scollen geht nicht in der liste da."
Die Auswahlliste im Kanal-Dialog liegt seit dem Popover-Umbau in der
obersten Ebene. Das loest das Abschneiden -- aber der Zeiger steht
danach ueber dem Dialog, nicht ueber der Liste, und das Mausrad rollt
den Dialog. Der Horcher haengt jetzt am Dokument (capture) und fragt
selbst, ob der Zeiger im Rechteck der Liste steht. Gemessen:
5 Messungen, 0 Befunde.

ZWEITENS: "gestalte diese seite auch anders ... viel uebersichtlicher."
Am Anschlagbrett stand die Herkunft als vollstaendige Abschrift des
Titels darueber -- derselbe Satz zweimal, direkt untereinander. Jetzt
nennt sie nur noch das Brett, wenn der Titel uebernommen wurde, und
kuerzt sonst auf 60 Zeichen an der Wortgrenze. Dazu Karten mit
620 px Hoechstbreite, zwei nebeneinander statt einer Zeile ueber die
ganze Breite -- lesbar bleibt, was eine begrenzte Zeilenlaenge hat.
Gemessen: 11 Messungen, 0 Befunde; Titel von 352 px statt voller
Breite, zwei Spalten a 571 px.

Geprueft: pruef-anschlagbrett (12, 0), pruef-css-klassen,
pruef-highlights, pruef-chat-kanaele (81, 0), pruef-freie-namen (32, 0).

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-24 00:18:04 +02:00
DogFatherGitandClaude Opus 5 f2f3586b5b Die Auswahlliste lag hinter dem Dialog
Filipe: "wenn ich auf zustaendigkeit druecke dan erscheint die auswahl
im hintergrund kontrollier das."

KONTROLLIERT, UND ER HAT RECHT. Gemessen im Browser: Der Kanal-Dialog
ist modal, die Liste hing an BODY, und ein Klick in ihre Mitte traf
DIALOG.dialog -- also den Dialog, nicht die Liste. Sie war da, sichtbar
war sie nicht, bedienbar erst recht nicht.

DER GRUND IST EINE EBENE, KEINE ZAHL. Ein Dialog aus showModal() liegt
in der TOP LAYER, einer Schicht ueber dem ganzen Dokument. Kein
z-index holt etwas aus dem Body davor; die Ebene entscheidet.

DER ERSTE VERSUCH WAR FALSCH, und das Bildschirmfoto hat es gezeigt:
Die Liste IN den Dialog zu haengen bringt sie zwar nach vorn -- und
laesst sie am unteren Rand abschneiden. `.dialog` traegt ein
clip-path fuer die abgeschraegte Ecke, und ein clip-path beschneidet
ALLE Nachkommen, auch "position: fixed". Die Liste endete mitten im
Wort "Events".

Damit ging beides nicht: draussen dahinter, drinnen beschnitten.

DER POPOVER IST GENAU DAFUER GEMACHT. Er hebt ein Element in dieselbe
Ebene wie den Dialog, ohne es zu seinem Kind zu machen: kein Beschnitt,
kein z-index-Wettlauf, und der Browser raeumt ihn beim Schliessen
selbst weg. Fehlt er im Browser, bleibt alles wie bisher -- ausserhalb
eines Dialogs aendert sich ohnehin nichts.

Die drei Zeilen in gate.css nehmen die Vorgaben zurueck, die ein
Popover mitbringt (Rahmen, Polster, und "inset: 0" plus "margin: auto",
was ihn in die Bildmitte stellt).

UND MEINE MESSUNG WAR ZUERST FALSCH, nicht der Code: Sie fragte
document.elementFromPoint und bekam DIALOG -- auch als die Liste
sichtbar darueber lag. Top-Layer-Elemente erfasst elementFromPoint
nicht verlaesslich. Gemessen wird jetzt, was ein Mensch tut: auf einen
Eintrag tippen und nachsehen, ob er ankommt. Er kommt an
("chat -> events"), und die Liste schliesst sich danach.

DAZU EINE EIGENE SCHLAMPEREI VON VORHIN: Die neuen Handy-Kacheln auf
"Eure Aufgaben" hatten .7rem = 11,2 px. Die Grenze des Hauses liegt
bei 11,5 px, und sie steht dort aus einem Grund -- Augenschonung ist
Pflicht, nicht Geschmack. pruef-css-klassen hat es gefangen ("43
Stellen unter 11,5 px, eine mehr als die Grundlinie 42"). Genau dafuer
zaehlt sie mit. Jetzt .75rem, und die Zahl steht wieder bei 42.

Gemessen: 7 Messungen am Dialog ohne Befund, css-klassen wieder in
Ordnung.

NICHT VON HEUTE ABEND, aber gefunden: pruef-chatkachel meldet "mit
allen 13 Toenen (2)". Seit Commit 7a674963 liegen die meisten Toene
auf einem Ring und nur der Rest im Gitter; die Pruefung zaehlt nur das
Gitter. Sie ist damit dauerhaft rot und gehoert nachgezogen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-23 23:22:05 +02:00
DogFatherGitandClaude Opus 5 df0e74f751 Bearbeiten zeigt jetzt, was schon eingetragen war -- und loescht es nicht mehr
Filipe, screen19: "wenn ich auf bearbeiten drücke will ich dass mir immer
die daten angezeigt werden die schon ausgewählt wurden, damit ich auch
immer sehe okee das war alles und das änder ich."

Das war nicht nur unbequem, es war ein DATENVERLUST. Das Feld "Mit wem"
wurde beim Bearbeiten nie gefuellt und stand leer da. Beim Speichern wird
`teilnehmer_extern` aber trotzdem mitgeschickt -- der leere Wert
ueberschrieb also den vorhandenen. Wer einen Termin mit einem frei
eingetragenen Namen ("BananaStift") bearbeitete und speicherte, hatte den
Namen danach verloren, ohne ihn je gesehen zu haben. Nichts stuerzte ab,
nichts meldete sich; er war einfach weg.

DIE URSACHE lag tiefer als im Kalender: `window.personenwahl` konnte
lesen (`wert`, `extern`) und leeren (`zuruecksetzen`), aber NICHT
fuellen. Ein Bearbeiten-Formular hatte gar keine Moeglichkeit, einen
freien Namen anzuzeigen. Deshalb kommt die Reparatur in zwei Teilen:

  wahl.js      neue Funktion `setzen(wert, externText)`. Sie behandelt
               die beiden Faelle als das, was sie sind: entweder eine
               Person aus der Liste ODER ein freier Name -- nie beides.
               Das eine setzt das andere zurueck.

  kalender.js  belegt das Gegenueber beim Bearbeiten vor, aus
               creator_id / teilnehmer_id / teilnehmer_extern. Nur fuer
               die Leitung, wie beim Speichern auch -- fuer die anderen
               Rollen gibt es das Feld gar nicht.

Der Server lieferte die noetigen Felder die ganze Zeit mit
(t.teilnehmer_extern, t.creator_id, t.teilnehmer_id) -- es hat sie nur
niemand abgeholt.

Nachgemessen: `personenwahl('f-teilnehmer').setzen('', 'BananaStift')`
ergibt extern="BananaStift", wert="" -- der freie Name steht im Feld,
die Personennummer ist leer. pruef-kalender EXIT=0 (84),
pruef-serien EXIT=0 (69).

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-08 11:54:39 +02:00
DogFatherGitandClaude Opus 5 e8478c9cae Spicy sieht DogFathers Sachen nicht mehr -- und sechs Fehler dazu
VIER DINGE AUS DEN BILDSCHIRMFOTOS, jedes ein echter Fehler:

1. SPICY MEDIA SAH DOGFATHERS DATEN. Beim ersten Anlauf bekam die Rolle
   dieselbe Regel wie DogFather (`1=1`) -- damit stimmte der Ueberblick
   ueber Manager, Scouts und Creator, und nebenbei standen seine eigenen
   Termine, Aufgaben, Dateien und Eintraege mit drin. Jetzt gibt es
   ohneDogFather() als EINE Stelle dafuer: Zwei Spalten werden geprueft,
   `creator_id` (um wen geht es) und `erstellt_von` (wer hat es
   geschrieben) -- ein Termin, den er sich selbst anlegt, haengt nur an
   der zweiten. `IS NULL OR NOT IN` und nicht bloss `NOT IN`: In SQL ist
   `NULL NOT IN (...)` weder wahr noch falsch, die Zeile fiele
   stillschweigend heraus.

2. "PERSOENLICHER ZUGANGSCODE · undefined" auf der Anmeldeseite. Eine
   zweite Namensliste im Browser, die beim Hinzufuegen der Rolle
   niemand gepflegt hat. Ein unbekannter Schluessel faellt jetzt auf
   sich selbst zurueck statt auf `undefined` -- haesslich, aber
   sichtbar.

3. SPICY KAM NICHT IN DIE PERSONENVERWALTUNG. Der Server liess sie
   herein, das Skript warf sie wieder hinaus: zwei Listen fuer dieselbe
   Frage, gepflegt wurde nur die erste.

4. DIE ANMELDEKARTE WAR ZU KLEIN FUER FUENF ROLLEN. Der Kommentar an
   genau dieser Stelle warnt woertlich davor -- und ich habe getan,
   wovor er warnt: eine Rolle eingefuegt und die Zahl daneben nicht
   angefasst. Gemessen: Inhalt 573 px in einer 526 px hohen Tafel, die
   Fusszeile stand unter dem Rahmen. Schrift kleiner half nicht (sie lag
   schon auf dem Anschlag), also sind die Abstaende an neun Stellen
   enger. Nachgemessen auf fuenf Groessen: passt ueberall.

DIE ZEIT WAR WIRKLICH FALSCH. Nicht nur in meinem Satz: `datum()` in
personen.js schnitt die ISO-Zeichenkette ab -- und die ist UTC. Im
Protokoll stand 03:00, wo 05:00 war. Das Tueckische daran ist, dass es
nie kaputt aussieht: Eine Uhrzeit ist immer plausibel.

PROFILBILDER WERDEN JETZT GEZEICHNET. Der Server lieferte sie seit
gestern mit, gezeichnet wurden sie nirgends -- deshalb aenderte sich
nichts. Jetzt in der Personenauswahl (Aufgaben, Termine, Dateien,
Bereiche), in der Gespraechsliste und an jeder Nachricht. Der
Anfangsbuchstabe bleibt als Unterlage LIEGEN: Faellt das Bild aus, steht
dort weiter etwas Sinnvolles.

DER CHAT: Gesichter mit Rollenfarbe, Blasen mit Richtung (die erste
einer Folge eckig, die naechsten rund -- so sieht man, wo ein Gedanke
anfaengt), das offene Gespraech mit Schiene, Ungelesenes hervorgehoben,
und das Eingabefeld in einer eigenen Leiste, die sich beim Schreiben
hebt.

ZWEI EIGENE PATZER, beide von Pruefungen gefunden:
  - `o is not defined`: Mein Suchmuster hat die zwei Zeilen fuer das
    Bild ans DATEIENDE gesetzt statt in die Schleife -- und in
    kalender.js an einen <span> statt ans <option>. Gemeldet von
    pruef-sicht, das die Browserkonsole mitliest.
  - Ein Kommentar mit `bild` in schraegen Anfuehrungszeichen stand INNEN
    in einer Vorlagenzeichenkette und hat sie geschlossen. Die halbe SQL
    wurde zu Programmtext.
Dazu: `.chat-neu` gibt es nicht (heisst `.chat__eingabe`), und der
Rollenknopf hatte fuer den Manager keinen sichtbaren Fokus -- ein
box-shadow wird von `overflow: hidden` abgeschnitten, ein outline nicht.

Gruen: spicy (43), creator-anlegen (29), personen-liste (33), sicht (48),
chat (48), chat-optik (24), buehne (38), struktur (32), css-klassen (15),
handy (59), breiten (23), formulare (19), start-ansicht (136),
lesbarkeit (14), barrierefrei (18), tempo (8), kopf-messen (3),
glocke (26), haerte (20), manager-sicht (43), alle-wege (19),
aufgabenbrett (44), kalender (84).

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-07 05:46:19 +02:00
Claudian b941080694 Die Namensliste ging beim Scrollen zu
FILIPE, mit Bildschirmfoto der Personenauswahl: "wenn ich da scollen will geht das immer zu"

Er hatte recht, und es war eine einzige Zeile in workspace/assets/js/wahl.js:

    addEventListener('scroll', schliessen, true);

Das dritte Argument bedeutet "in der Einfangphase lauschen" -- und damit auf JEDES
Scroll-Ereignis im ganzen Dokument, auch auf das in der Liste selbst. Wer die Namensliste
herunterrollen wollte, schloss sie im selben Moment. Bei acht Eintraegen faellt das kaum
auf; beim ganzen Manager- und Scout-Team ist die Liste unbedienbar.

Zumachen MUSS sie trotzdem, wenn die Seite scrollt: Sie haengt an position:fixed und
schwaemme sonst neben ihrem Knopf davon. Deshalb wird jetzt unterschieden, WO gescrollt
wurde -- ein Scroll-Ereignis der Seite hat document als Ziel, das ist nicht in der Liste
enthalten, also schliesst sie wie bisher.

Dazu overscroll-behavior: contain in gate.css. Ohne das reicht der Browser das Rollen am
Listenende an die Seite weiter, die Seite bewegt sich -- und daran schliesst die Liste zu
Recht. Der Fehler waere zur Haelfte zurueck gewesen.

GEPRUEFT im echten Browser am echten wahl.js und gate.css (pruef-wahl-scrollen.mjs, 7
Pruefungen), und zwar BEIDE Haelften der Zusage: Liste scrollt -> bleibt offen, Seite
scrollt -> geht zu. Eine Reparatur, die nur die eine Richtung sichert, waere die naechste
Ueberraschung.

Gegenprobe: alte Zeile testweise eingesetzt -> 2 Pruefungen fallen durch. Reparatur ->
alle 7 gruen.

Die Pruefung hat sich beim Bauen DREIMAL geweigert, etwas zu bestaetigen, das sie nicht
gemessen hatte -- "die Liste ist gar nicht laenger als ihr Fenster", "scrollTop = 0". Jedes
Mal lag es an meinem Aufbau (zu hohes Fenster, fehlende Stylesheets, Mausrad ohne Wirkung),
nie an der Reparatur. Gruen gemeldet haette sie es nie.

Der Versionsstempel muss mit: Cloudflare haelt JS und CSS vier Stunden im Browser fest.
Ohne neue Adresse saehe Filipe die Reparatur bis zu vier Stunden lang nicht.

HINWEIS ZUM COMMIT: In diesem Verzeichnis lag zum Zeitpunkt der Arbeit fremde,
uncommittete Arbeit -- vier Server-Dateien (heute 16:41-16:53 geaendert), sieben neue
Pruefdateien, ~110 Bildschirmfotos, eine Fokusring-Korrektur in gate.css und eine
Beschriftung in profil.html. Nichts davon ist hier drin. Bereitgestellt wurde ausdruecklich
nach Pfad, und die beiden Dateien mit gemischtem Inhalt (gate.css, profil.html) wurden dafuer
aus HEAD geholt und nur um den eigenen Anteil ergaenzt. Die fremde Arbeit steht unveraendert
im Arbeitsstand.
2026-09-04 19:18:02 +02:00
DogFatherGitandClaude Opus 5 540b5d8838 Freie Namen, ein Call-Knopf, und drei Seiten, die fuer Scouts kaputt waren
DREI SACHEN AUF EINMAL, alle aus derselben Sitzung.

1. AUSSUCHEN ODER SELBST EINTRAGEN
   Wunsch: "ich will da auch sachen selber noch eintragen koennen, also
   aussuchen und selbst eintragen."

   Jede Personenauswahl (Kalender, Aufgaben, Bereiche, Content, Dateien)
   nimmt jetzt auch einen getippten Namen an -- eine Agentur, eine Marke,
   einen Gast ohne Konto. Dazu bekommt JEDE Auswahl ab acht Eintraegen
   ein Suchfeld: tippen statt scrollen.

   Gebaut IM vorhandenen Auswahl-Bauteil (wahl.js), nicht daneben. Der
   erste Anlauf war ein zweites Bauteil -- es hat sich prompt mit dem
   ersten gebissen, beide haben denselben <select> eingepackt. Ein
   zweites haette ausserdem anders ausgesehen und waere beim naechsten
   Umbau nur an einer von zwei Stellen nachgezogen worden.

   Der freie Name steht in einer EIGENEN Spalte je Feld; die Verknuepfung
   bleibt leer. Entweder eine Person ODER ein Name, nie beides.

   Filipe hat ausdruecklich auch bei den Creator-Feldern freie Namen
   gewollt, nachdem der Nachteil benannt war: Der Eintrag gehoert dann zu
   keinem Konto. Damit daraus kein STILLER Ausfall wird, faellt jede
   Abfrage, die bisher den Namen der verknuepften Person las, jetzt auf
   den freien Text zurueck (externSql) -- gekennzeichnet als "(extern)".
   Der Eintrag verschwindet dadurch aus keiner Liste, keiner Suche und
   keiner Uebersicht.

2. WO FUEHRE ICH DEN CALL?
   Den Knopf gab es, aber nur wenn jemand von Hand einen Link ins
   Ortsfeld getippt hatte UND das Gespraech noch bevorstand. Stand dort
   "Hier", war nichts zum Anklicken da.

   Jetzt hat das Team einen festen Call-Raum (Discord-Sprachkanal), den
   das Management einmal hinterlegt. Danach hat JEDER Call den Knopf --
   und er bleibt, solange das Gespraech laufen kann, nicht nur bis zur
   Startzeit. Ein eigener Link am Termin schlaegt den festen Raum.

3. WAS EINE ROLLE SIEHT, MUSS AUCH FUNKTIONIEREN
   Gemeldet: "cigdem kriegt als manager gewisse sachen nicht auf die sie
   sieht, check jede rolle ab."

   Neue Pruefung server/pruef-rollen.mjs schickt SECHS Rollen-Zustaende
   ueber alle 16 Seiten und misst Konsolenfehler, fehlgeschlagene
   Serveraufrufe, tote Verweise, haengende Ladeanzeigen und wortlos leere
   Seiten. 96 Durchgaenge.

   Der sechste Zustand ist der wichtige: eine Rolle OHNE zugeteilte
   Creator -- der Normalfall am ersten Tag und Cigdems echte Lage.
   Genau dort fielen die Seiten durch, waehrend dieselben Seiten MIT
   Zuteilung tadellos waren.

   VIER ECHTE FEHLER GEFUNDEN UND BEHOBEN:

   a) Eine Aufgabe, die eine Managerin ohne Creator anlegte, war fuer sie
      im selben Moment unsichtbar -- creator_id und verantwortlich_id
      leer, und "von mir selbst angelegt" stand in keiner
      Sichtbarkeitsregel. Nur DogFather sah sie noch. Kein Fehler, keine
      Meldung, die Aufgabe war einfach weg. Dasselbe bei den
      Bereichseintraegen. Beide Regeln kennen jetzt erstellt_von.
      Niemand sieht dadurch etwas Fremdes -- nur das Eigene.

   b) Ein Scout ohne zugeteilten Creator bekam auf die GESAMTE
      Report-Seite 404, obwohl sie fuer ihn verlinkt ist. Die Seite
      antwortet jetzt sauber und leer, statt sich zu verweigern.

   c) Start-Check und Report blieben fuer immer auf "wird geladen"
      stehen, wenn es nichts zu laden gab.

   d) Das Creator-Profil war fuer Scouts ohne Zuteilung wortlos leer --
      der erklaerende Satz stand nur in der grauen Unterzeile.

   Ausserdem meldete die bestehende Lesbarkeitspruefung zwei neue
   Beschriftungen von mir als zu klein fuers Handy (10,88 statt 11,5 px).
   Behoben, und dieselbe Groesse an der Serien-Karte gleich mit -- dort
   waere es erst aufgefallen, sobald jemand eine Wiederholung anlegt.

GEPRUEFT: pruef-rollen 97, pruef-freie-namen 32 (mit Gegenproben:
Ben sieht Cigdems Aufgabe NICHT; die Saeulen-Zuordnung nimmt
ausdruecklich KEINEN freien Namen). Alle bestehenden Laeufe gruen:
Startansicht 133, Kalender 84, Serien 67, Protokoll 52, Handy 50, Sicht
48, Ampel 47, Content 45, Aufgabenbrett 44, Sprung 43,
Personen-Loeschen 40, Bereiche 37, Uebersicht 33, Workspace-Seiten 32,
Formulare 19, Betreuung 18, Grosscheck 15, Lesbarkeit 14.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-02 20:10:09 +02:00
DogFatherGit 7c81b17f9c Workspace: alle Auswahlfelder ohne Systemmenue
Filipe: "die kisten wo die namen drin stehen um auszuwaehlen -- kannst
du doch ueberall besser aussehen lassen". Betraf nicht eine Stelle,
sondern 28 Auswahlfelder auf zehn Seiten.

Deshalb EIN Baustein (assets/js/wahl.js) statt zehn Einzelloesungen.

WIE ER ARBEITET:
Das echte <select> bleibt im Dokument und behaelt seinen Wert -- es wird
nur unsichtbar. Darueber liegt ein eigener Knopf mit eigener Liste.
Damit funktioniert alles weiter, was schon da war: jedes `feld.value`,
jedes `change`-Ereignis, jedes Formular. Ich musste keine einzige der
zehn Seiten in ihrer Logik anfassen.

Faellt das Skript aus, ist wieder das gewohnte Systemmenue da.

DREI ENTSCHEIDUNGEN, DIE WICHTIG WAREN:

1. Nicht display:none fuer das echte Feld, sondern ein Pixel und
   durchsichtig. Ein per display:none verstecktes Feld faellt aus der
   Formularpruefung des Browsers heraus -- `required` wuerde stumm nicht
   mehr greifen.

2. Die Liste haengt an position:fixed, nicht am Elternelement. In einer
   Karte mit overflow:hidden waere sie sonst abgeschnitten. Passt sie
   nach unten nicht mehr hin, klappt sie nach oben.

3. Ein MutationObserver erfasst Felder, die erst spaeter entstehen, und
   Eintraege, die nachgeladen werden. Neu gezeichnet wird im naechsten
   Bild -- so wird ein direkt nach dem Fuellen gesetztes `feld.value`
   noch mitgenommen. Geprueft an der Scout-Pipeline: Prioritaet und
   Stufe entstehen erst beim Aufklappen, beide werden aufgewertet, der
   gewaehlte Wert kommt beim Speichern richtig an.

Tastatur wie gewohnt: Pfeile oeffnen und blaettern, Buchstaben springen
zum passenden Eintrag, Esc schliesst, Klick daneben auch. Gruppen
(optgroup) werden als Zwischenueberschrift dargestellt.

Geprueft ueber zehn Seiten: 28 Felder, KEINES mehr als Systemmenue,
Werte kommen an, Seite reagiert auf die Auswahl, Handy ohne Ueberlauf,
0 Konsolenfehler.
2026-08-31 12:23:49 +02:00