DogFatherGit
3a1ab64c26
Auf JEDER Seite, nicht auf einer eigenen. kopf.js baut sie selbst in die Kopfleiste ein -- eine Suche, die man nur auf einer Extraseite findet, benutzt niemand. Mit "/" oeffnen, mit Esc schliessen. Durchsucht: Aufgaben, Termine, Calls, Gespraechsprotokolle, Dateien, die fuenf Betreuungsbereiche, die Scout-Pipeline und die offenen Felder der Creator-Profile. Zwei Dinge machen den Unterschied zwischen einer Suche und einer brauchbaren Suche: 1. SIE DARF NICHTS FINDEN, WAS DIE SEITE VERBERGEN WUERDE. Eine Suche ist die verlockendste Stelle fuer ein Datenleck: Man tippt einen Namen und bekommt Treffer aus Bereichen, die man nie oeffnen duerfte. Jede Quelle wird deshalb mit der Sichtbarkeitsregel ihres eigenen Moduls abgefragt -- importiert, nicht abgeschrieben. Die management-internen Profilfelder (admin_notiz, plan_start, naechster_review) werden GAR NICHT durchsucht, auch nicht fuer das Management: Ein Treffer daraus taucht sonst spaeter in einer Ansicht auf, die diese Felder nicht zeigen darf. Wer die Notiz lesen will, oeffnet das Profil. Geprueft mit einem eigenen Leck-Test: "GEHEIM" (Inhalt einer internen Notiz) findet niemand, auch der Chef nicht. Die Lead-Notiz eines Scouts findet nur er selbst und das Management, nicht der andere Scout. 2. SIE MUSS SAGEN, WO ETWAS STEHT. Jeder Treffer traegt einen Ausschnitt RUND UM die Fundstelle, nicht die ersten Zeichen des Feldes -- man sieht sofort, warum etwas gefunden wurde. Bei Profiltreffern steht dabei, welches Feld getroffen hat, bei Protokollen ob es unter "Besprochen" oder "Entscheidung" stand. Und jeder Treffer fuehrt an die Stelle, an der man weiterarbeiten kann. LIKE-Sonderzeichen werden maskiert. Ohne das waere die Suche nach "100%" eine Suche nach "100 gefolgt von irgendwas" und "a_b" faende auch "axb" -- beides falsch und beides faellt erst spaet auf. Geprueft: "100%" und "a_b" finden genau ihren Eintrag, "axb" findet nichts. Bewusst kein Volltextindex (FTS5): Die Datenmengen sind klein, und LIKE braucht keinen zweiten Datenstand, der irgendwann auseinanderlaeuft. Kleinigkeiten aus dem Test: - Das Overlay stand auf voller Hoehe, auch bei zwei Treffern -- der Schleier ist flex und stand auf dem voreingestellten stretch. Jetzt flex-start, das Fenster waechst mit dem Inhalt (417 statt 780 px bei drei Treffern). - Das eingebaute Kreuz von type="search" sass direkt neben dem Esc-Knopf: zwei Wege fuer dasselbe, dicht nebeneinander. Entfernt. - Das CSS liegt in gate.css, nicht in einer Seiten-Datei -- genau der Fehler, der bei .knopf-still schon einmal passiert ist.
