Spicy Media sah die Zeilen der Modis -- drei Tabellen, ein Loch

GEMESSEN, NICHT VERMUTET, und es war live: Aufgaben, Bereichs-Eintraege
und Dateien eines Modis waren fuer Spicy Media sichtbar. Die NAMEN der
Modis waren ueberall sauber verborgen -- ihre ZEILEN nicht. Eine halbe
Verborgenheit ist keine.

WARUM ES PASSIEREN KONNTE: Fuer Personen gibt es die Regel EINMAL
zentral (verborgeneIds). Fuer Zeilen gibt es sie DREIMAL -- in
workspace-aufgaben.js, workspace-bereiche.js und workspace-dateien.js --
und alle drei geben Spicy Media dasselbe: "alles ausser dem, was
DogFather gehoert" (ohneDogFather). Ein Modi-Eintrag gehoert ihm nicht,
also fiel er durch.

Manager, Scout und Creator waren nie betroffen, ihre Regeln sind enger.
Der Kalender auch nicht: termineSichtbar() gibt jedem nur Eigenes.
Beides nachgesehen, nicht angenommen.

GEFUNDEN HAT ES KEINE UEBERLEGUNG, sondern eine Pruefung, die etwas
ANLEGT und danach mit fremden Augen nachsieht. Vorher hatte ich nur
Namenslisten geprueft -- und die waren die ganze Zeit gruen. Der Anlass
war nicht einmal Misstrauen gegen diese Stelle: Ich wollte ein
Ideen-Board auf die Eintraege setzen und dabei wissen, wer sie sieht.

BEHOBEN mit ohneModi() als Gegenstueck zu ohneDogFather -- und zwar als
UMHUELLUNG um die drei Regeln, nicht als Flicken darin. Ein Flicken
haette den einen bekannten Zweig geschlossen und den naechsten
Rollenzweig wieder offen gelassen; gemerkt haette es niemand, weil an
der geaenderten Stelle nichts davon steht.

Dazu die `fuerAlle`-Ausnahme bei den Eintraegen: Sie haengt ein ODER an
und haette die Bedingung sonst wieder aufgemacht. Heute hat kein Modi
eine Kachel in einen solchen Bereich -- ein Aufruf an der Oberflaeche
vorbei braucht sie aber nicht. Eine Regel, die nur im Formular gilt,
ist keine Regel.

Nachgesehen, dass die Umhuellung nirgends das falsche Tabellenkuerzel
setzt: Alle Aufrufstellen in workspace-hinweise.js und workspace-suche.js
fuehren die Tabellen als a, d und e -- genau so, wie es dasteht.

NEBENBEI: Das Modi-Team teilt sich jetzt auch die Bereichs-Eintraege,
nicht nur die Aufgaben (Entscheidung Filipe, 09.09.2026: "sie sind
untereinander ein Team"). Ohne diesen Zweig saehe jeder Modi nur, was er
selbst geschrieben hat -- eine gemeinsame Sammlung waere keine.

ZWEI EIGENE FEHLER AUF DEM WEG DAHIN, beide festgehalten:

  * Die neue Messung stand HINTER der Gegenprobe. Die macht eine Person
    absichtlich zur Creatorin -- die Messung bekam 403 und meldete
    "kann nichts anlegen". Gemessen wurde ein Zustand, den es im
    Betrieb nicht gibt. Genau davor warnt der Kommentar, den ich selbst
    zwei Tage vorher an diese Gegenprobe geschrieben hatte.
  * Das "konnte nicht nachsehen" nannte KEINEN Grund. Damit ist der
    dritte Ausgang nur dem Namen nach da -- man weiss danach so wenig
    wie vorher. Erst mit der Fehlermeldung im Text kam ich auf die Spur.

GEPRUEFT: pruef-modi-verborgen (75, davon 18 neu ueber drei Tabellen und
fuenf Rollen), pruef-spicy (60), pruef-bereiche-lesend,
pruef-aufgabenbrett, pruef-modi-katalog (29).

Co-Authored-By: Claude Opus 5 <[email protected]>

server/workspace.js

@@ -165,6 +165,51 @@ export function ohneDogFather(praefix, spalten = ["creator_id", "erstellt_von"])
       + `(SELECT id FROM personen WHERE rolle = 'admin'))`)
     .join(" AND ");
 }
+/* =====================================================================
+   WAS EINEM MODI GEHOERT, SIEHT SONST NIEMAND (10.09.2026)
+
+   Das Gegenstueck zu ohneDogFather() -- und es entstand aus einem
+   gemessenen Leck, nicht aus einer Ueberlegung.
+
+   WAS PASSIERT WAR: Fuer PERSONEN ist die Regel zentral
+   (verborgeneIds). Fuer ZEILEN gibt es sie dreimal -- in
+   workspace-aufgaben.js, workspace-bereiche.js und
+   workspace-dateien.js -- und alle drei geben Spicy Media dasselbe:
+   "alles ausser dem, was DogFather gehoert". Ein Modi-Eintrag gehoert
+   ihm aber nicht. Also sah Spicy Media die Aufgaben, die Eintraege und
+   die Dateien der Modis, waehrend die Modis selbst in jeder Namensliste
+   sauber verborgen waren. Die halbe Verborgenheit ist keine.
+
+   Aufgefallen ist es nicht beim Lesen des Codes, sondern durch eine
+   Pruefung, die etwas ANLEGT und danach mit fremden Augen nachsieht.
+   Manager, Scout und Creator waren nie betroffen -- ihre Regeln sind
+   ohnehin enger. Der Kalender auch nicht: termineSichtbar() gibt jedem
+   nur Eigenes. Nachgemessen, nicht angenommen.
+
+   SPALTEN MUESSEN BEIDE RICHTUNGEN ABDECKEN. `creator_id` sagt, UM WEN
+   es geht; `erstellt_von`/`hochgeladen_von`/`verantwortlich_id` sagen,
+   an WEM es haengt. Eine Modi-Aufgabe hat gar keine creator_id -- sie
+   haengt allein an verantwortlich_id. Wer nur eine Spalte prueft, hat
+   nichts geprueft.
+
+   `IS NULL OR NOT IN` und nicht bloss `NOT IN`: In SQL ist
+   `NULL NOT IN (...)` weder wahr noch falsch, sondern NULL -- die Zeile
+   fiele stillschweigend heraus. Genau so verschwinden Daten, ohne dass
+   jemand einen Fehler sieht. (Dieselbe Falle steht schon im Kommentar
+   von ohneDogFather; sie ist es wert, zweimal dazustehen.)
+   ===================================================================== */
+export function ohneModi(praefix, spalten = ["creator_id", "erstellt_von"]) {
+  return spalten
+    .map((sp) => `(${praefix}.${sp} IS NULL OR ${praefix}.${sp} NOT IN `
+      + `(SELECT id FROM personen WHERE rolle = 'modi'))`)
+    .join(" AND ");
+}
+
+/** Darf diese Person ueberhaupt etwas sehen, das einem Modi gehoert?
+ *  Nur die DogFather-Rolle und die Modis selbst. */
+export const siehtModis = (person) => !!person
+  && (person.rolle === "admin" || person.rolle === "modi");
+
 export const siehtAlles = (person) => !!person
   && (person.rolle === "admin" || person.rolle === "spicy");