Dreizehn Lecks: eine Managerin sah die Creator aller anderen

Wunsch: "jeder manager soll auch immer nur seine und die seiner scouts zugeteilten creator und creator daten sehen. und nicht die der anderen." DIE KETTE WAR GEBAUT -- SIE WURDE NUR NICHT BENUTZT Manager -> seine Scouts -> deren Creator steht seit dem 01.09.2026 an genau einer Stelle (betreuteIds). Die Frage war eine andere: Benutzt sie auch JEDER Weg, der Creator-Daten herausgibt? Ueber zwanzig Stellen prueften die ROLLE statt der ZUTEILUNG -- "ist Leitung? dann alles". NICHT GELESEN, SONDERN GEMESSEN server/pruef-manager-sicht.mjs baut zwei Managerinnen mit vollstaendig getrennten Creators. Bei der fremden heisst ALLES "GEHEIM..." -- Aufgabe, Termin, Bereichseintrag, Datei, Steckbrief, Content-Saeule. Danach wird jede der 31 Leseschnittstellen abgefragt und die ganze Antwort danach durchsucht. Ein Leck faellt damit auf, egal wo es sitzt und egal, ob ich es beim Lesen uebersehen haette. GEFUNDEN: DREIZEHN. Alle geschlossen: Kalender fremde Fristen -- besonders unangenehm, weil es nicht wie ein Leck aussieht: eine kleine orange Marke mit einem Titel, in dem fremde Vorhaben stehen Personenauswahl alle Namen im Zuweisungsfeld Dateien alle Namen in der Freigabe-Auswahl Uebersicht Gesamtuebersicht ueber ALLE Creator Report Auswahl UND Auswertung ueber den ganzen Bestand Start-Check alle Creator zur Auswahl Steckbriefe Bild, Kanaele, "ueber mich" von allen Profile alle Profile, samt interner Notiz Schulung Schulungsstand aller Creator Suche Creator-Profile aller -- die unauffaelligste Stelle: Man sucht etwas anderes und bekommt fremde Namen Content-Balance Themensaeulen fremder Kanaele (die Abfrage daneben war korrekt eingeschraenkt, DIESE hatte eine eigene Bedingung) darfCreator eine einzige Zeile -- sie hing an Profil, Start-Check und Uebersicht gleichzeitig. Es reichte, eine Nummer in die Adresse zu schreiben. Die Antwort steht jetzt an EINER Stelle: sichtbareCreatorIds und sichtbarePersonenIds in workspace.js. Rueckgabe null heisst "alle" und gilt allein DogFather -- bewusst kein leeres Feld: Eine leere Liste bedeutet "niemand", und die Verwechslung der beiden macht aus einer Sperre eine Freigabe. ZWEI DINGE, DIE ICH MIR SELBST NACHTRAGEN MUSS 1. Beim Stopfen fehlte einmal ein Import. Der Weg warf einen Fehler, antwortete 503 -- und weil in einer Fehlermeldung kein "GEHEIM" steht, meldete die Pruefung "kein Leck". Sie war gruen, weil der Weg KAPUTT war. Die Pruefung zaehlt jetzt beides: nichts durchsickern UND antworten. 2. Ein Fehlalarm: Die Suche gibt den SUCHBEGRIFF in ihrer Antwort zurueck. Wer nach "GEHEIM" sucht, findet das Wort zwangslaeufig -- auch bei null Treffern. Ich haette um ein Haar ein Leck "repariert", das es nie gab. Das Echo wird jetzt entfernt, bevor gemessen wird. FOLGEN, bewusst in Kauf genommen: * Ein Manager ohne Zuteilung sieht keinen Creator. Die Uebersicht sagt ihm das jetzt in einem Satz, statt leer zu bleiben. * Er kann nur noch IN SEINEN Creator-Bereichen schreiben (darfCreator). ZWEI PRUEFUNGEN UMGEDREHT statt geloescht -- eine geloeschte Pruefung hinterlaesst keine Spur davon, dass hier einmal etwas anderes galt: pruef-uebersicht ("Manager sieht dasselbe" -> "nur seine zugeteilten", mit beiden Faellen) und pruef-scout-zuteilung ("sieht die ganze Personenliste" -> "landet auf der Startseite"). GEPRUEFT: 43 neue Pruefungen, dazu 23 bestehende Laeufe gruen -- Startansicht 133, Rollen 97, Kalender 84, Serien 67, Steckbrief 65, Handy 50, Sicht 48, Ampel 47, Content 45, Aufgabenbrett 44, Schulung 41, Bereiche 37, Scout-Zuteilung 36, Uebersicht 35, Personenliste 33, Freie Namen 32, Team 30, Protokoll-Loeschen 20, Personenformular 20, Formulare 19, Betreuung 18, Code 17, Grosscheck 15. Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-03 01:01:00 +02:00
parent d8720debc1
commit 0404f8c0c1
56 changed files with 732 additions and 205 deletions
@@ -1178,6 +1178,64 @@ export function scoutZuteilungSetzen(scoutId, managerId, akteur = null) {
    .run(scoutId, managerId, new Date().toISOString(), akteur);
 }

+/* =====================================================================
+   WEN DARF DIESE PERSON ÜBERHAUPT SEHEN? (03.09.2026)
+
+   Wunsch: "jeder manager soll auch immer nur seine und die seiner
+   scouts zugeteilten creator und creator daten sehen. und nicht die der
+   anderen."
+
+   Die Kette Manager -> Scout -> Creator gab es schon (betreuteIds). Was
+   fehlte, war ihre ANWENDUNG: Über zwanzig Stellen prüften die ROLLE
+   statt der ZUTEILUNG -- "ist Leitung? dann alles". Eine Lecksuche über
+   alle Leseschnittstellen (server/pruef-manager-sicht.mjs) fand am
+   03.09.2026 dreizehn davon: der Kalender zeigte fremde Fristen, die
+   Personenlisten fremde Namen, Report, Steckbrief, Profil, Start-Check,
+   Schulung und die Suche jeweils alles.
+
+   Deshalb stehen die beiden Antworten jetzt HIER, an einer Stelle, und
+   werden überall geholt statt jedes Mal neu formuliert.
+
+   RÜCKGABE null HEISST "ALLE" -- und zwar nur für DogFather. Das ist
+   bewusst kein leeres Feld: Eine leere Liste bedeutet "niemand", und
+   die Verwechslung der beiden ist genau der Fehler, der aus einer
+   Sperre eine Freigabe macht. Wer null bekommt, lässt die Einschränkung
+   ganz weg; wer ein Feld bekommt, schränkt darauf ein -- auch wenn es
+   leer ist.
+   ===================================================================== */
+
+/** Die Creator, deren Daten diese Person sehen darf.
+ *  null = alle (nur DogFather). */
+export function sichtbareCreatorIds(person) {
+  if (!person) return [];
+  if (istDogFather(person)) return null;
+  if (person.rolle === "creator") return [person.id];
+  return betreuteIds(person);          // Manager: eigene + die seiner Scouts
+}
+
+/** Die PERSONEN, die in Listen und Auswahlfeldern auftauchen dürfen --
+ *  Namen sind auch Daten. null = alle (nur DogFather).
+ *
+ *  Enthält immer die Person selbst: Wer sich in einer Auswahl nicht
+ *  findet, kann sich nichts selbst zuweisen. Bei einem Manager kommen
+ *  seine Scouts dazu -- er führt sie, er muss sie eintragen können. */
+export function sichtbarePersonenIds(person) {
+  if (!person) return [];
+  if (istDogFather(person)) return null;
+  const creator = sichtbareCreatorIds(person) || [];
+  const scouts = person.rolle === "manager" ? scoutsVon(person.id) : [];
+  return [...new Set([person.id, ...creator, ...scouts])];
+}
+
+/** SQL-Baustein daraus: "diese Spalte ist eine Person, die ich sehen
+ *  darf". Gibt null zurück, wenn nicht eingeschränkt werden muss. */
+export function personenWo(person, spalte) {
+  const ids = sichtbarePersonenIds(person);
+  if (ids === null) return null;
+  if (!ids.length) return { wo: "0=1", werte: [] };
+  return { wo: `${spalte} IN (${ids.map(() => "?").join(",")})`, werte: ids };
+}
+
 /* SQL-Baustein "diese Spalte gehoert zu einem meiner Creator".
   Gibt null zurueck, wenn es nichts zu ergaenzen gibt -- eine leere
   IN-Liste waere ungueltiges SQL. */
@@ -1341,7 +1399,18 @@ export function sichtSetzen(req, res, next) {
 /* Darf diese Person den Bereich dieses Creators sehen und bearbeiten? */
 export function darfCreator(person, creatorId) {
  if (!person || !creatorId) return false;
-  if (istLeitung(person)) return true;
+  /* NUR DogFather pauschal (03.09.2026). Hier stand istLeitung -- und
+     damit war jede Managerin fuer JEDEN Creator zustaendig, auch fuer
+     die einer fremden Managerin.
+
+     Diese eine Zeile hing an mehreren Wegen gleichzeitig: Profil,
+     Start-Check und die Uebersicht je Creator liessen sich damit ueber
+     die blosse Kenntnis einer Nummer abfragen. Man musste nichts
+     umgehen, es reichte, eine Zahl in die Adresse zu schreiben.
+
+     Ein Manager faellt jetzt in dieselbe Zeile wie ein Scout -- die
+     Kette "eigene plus die meiner Scouts" steckt in betreuteIds. */
+  if (istDogFather(person)) return true;
  if (person.rolle === "creator") return person.id === Number(creatorId);
  return betreuteIds(person).includes(Number(creatorId));
 }