Manager sehen nur noch ihre zugeteilten Scouts -- und deren Creator

Wunsch vom 01.09.2026: "er soll nur die Scouts sehen, die ihm zugeteilt
sind." Dazu entschieden: Ein Manager sieht dann AUCH die Creator dieser
Scouts, und zuteilen darf NUR DogFather.

WAS VORHER WAR. Ein Manager sah die gesamte Scout-Pipeline -- alle Leads
aller Scouts, dazu dieselben in der Suche und in "Was ist dran". Das war
die letzte Stelle, an der "nur DogFather sieht alles" noch nicht galt.

EINE EIGENE TABELLE, KEIN ZWEITER EINTRAG IN `betreuung`.
Dort heisst die Spalte creator_id, und der ganze uebrige Code liest sie
als "das ist ein Creator". Ein Scout darin waere technisch moeglich und
fachlich eine Luege gewesen: betreuteIds() gaebe Scout-Nummern zurueck,
die anderswo als Creator behandelt wuerden. Solche Abkuerzungen raechen
sich genau dann, wenn niemand mehr weiss, dass sie getroffen wurden.

DIE KETTE steht an EINER Stelle (betreuteIds in workspace.js):
Manager -> seine Scouts -> deren Creator. Ohne sie muesste jeder Creator
einem Manager einzeln zugewiesen werden, und beim ersten vergessenen
faende er ein Loch in seiner Uebersicht, ohne zu merken, dass es eines
ist. Dieselbe Regel gilt fuer Leads in Pipeline, Suche und Hinweisen --
aus einer Quelle (pipelineIds), nicht dreimal abgeschrieben.

ZUTEILEN DARF NUR DOGFATHER, und das ist keine Foermlichkeit: Diese
Zuteilung ERWEITERT die Sicht eines Managers. Duerfte er sie selbst
setzen, koennte er sich seine eigene Sichtbarkeit vergeben -- eine
Grenze, die der Begrenzte selbst verschieben kann, ist keine. Deshalb
istDogFather und ausdruecklich NICHT istLeitung.

In der Personenliste steht bei jedem Scout "Gehoert zu", sichtbar nur
fuer DogFather. Der Leerwert heisst "— direkt bei DogFather —" und nicht
"— niemand —": Ein Scout ohne Manager ist nicht unbetreut, er haengt an
DogFather. Das ist ein Zustand, kein Mangel.

NEBENBEI KORRIGIERT: In der Zustaendigkeits-Route stand als Kommentar
noch "ein Eintrag auf DogFather oder Manager aendert an den Rechten
nichts, die Leitung sieht ohnehin jeden Creator". Das gilt seit heute
nicht mehr -- fuer einen Manager entscheidet dieser Eintrag jetzt sehr
wohl ueber die Sichtbarkeit. Ein falscher Kommentar ist schlimmer als
keiner: Er wird geglaubt.

DIE PRUEFUNG STELLT DEN MISSBRAUCH AN DEN ANFANG. Diese Aenderung
erweitert Sichtbarkeit -- alles andere heute hat sie eingeschraenkt. Ein
Fehler dort zeigt jemandem zu wenig und faellt auf; ein Fehler hier
zeigt zu viel und faellt niemandem auf. Geprueft wird deshalb: Manager
und Scout duerfen nicht zuteilen (404, und es wird auch wirklich nichts
geschrieben), Scout an Scout und Scout an DogFather werden abgewiesen,
ein Creator laesst sich nicht zuteilen. Danach die Kette in beide
Richtungen, das Zuruecknehmen, und dass ein Scout zu genau einem Manager
gehoert.

Ein lehrreicher Fehlschlag in der Pruefung selbst: Sie meldete, die
Auswahl fehle in der Oberflaeche. Sie fehlte nicht -- die Personenliste
ist nach Rollen ZUGEKLAPPT, und die Pruefung hatte nicht aufgeklappt.
Sah aus wie ein Produktfehler, war einer der Pruefung. Sie klappt jetzt
auf und stellt vorher fest, dass wirklich alle sieben Zeilen dastehen.

Gesamtlauf: 30 von 30 Dateien, 1210 von 1210 Einzelpunkten.

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

server/workspace-personen.js

@@ -15,7 +15,7 @@
 
 import express from "express";
 import {
-  db, protokolliere, echteIp, sitzungLesen, personAnlegen, codeNeu, personSperren, betreuungSetzen, istLeitung, istDogFather, ROLLEN_SORTIERUNG, ROLLEN_REIHE,
+  db, protokolliere, echteIp, sitzungLesen, personAnlegen, codeNeu, personSperren, betreuungSetzen, scoutZuteilungSetzen, istLeitung, istDogFather, ROLLEN_SORTIERUNG, ROLLEN_REIHE,
 } from "./workspace.js";
 import { sicherungJetzt } from "./workspace-sicherung.js";
 
@@ -98,9 +98,18 @@ personenRouter.get("/workspace/api/verwaltung/personen", (req, res) => {
                    AND a.status <> 'erledigt') AS offene_aufgaben,
                b.betreuer_id,
                (SELECT name FROM personen x WHERE x.id = b.betreuer_id) AS betreuer_name,
-               (SELECT COUNT(*) FROM betreuung y WHERE y.betreuer_id = p.id) AS betreut_anzahl
+               (SELECT COUNT(*) FROM betreuung y WHERE y.betreuer_id = p.id) AS betreut_anzahl,
+               /* Manager -> Scouts (01.09.2026). Bei einem Scout steht
+                  hier, wem er zugeteilt ist; bei einem Manager, wie viele
+                  Scouts an ihm haengen. Beides aus derselben Abfrage --
+                  eine zweite waere eine zweite Gelegenheit, dass die
+                  Liste etwas anderes sagt als die Rechte. */
+               sz.manager_id,
+               (SELECT name FROM personen m WHERE m.id = sz.manager_id) AS manager_name,
+               (SELECT COUNT(*) FROM scout_zuteilung z WHERE z.manager_id = p.id) AS scouts_anzahl
         FROM personen p
         LEFT JOIN betreuung b ON b.creator_id = p.id
+        LEFT JOIN scout_zuteilung sz ON sz.scout_id = p.id
         ORDER BY ${ROLLEN_SORTIERUNG.replace("rolle", "p.rolle")}, p.aktiv DESC, p.name`).all(),
       /* Wer ueberhaupt als zustaendig eingetragen werden kann.
 
@@ -151,11 +160,17 @@ personenRouter.put("/workspace/api/verwaltung/betreuung/:id", gleicheHerkunft, (
     /* DogFather, Manager und Scouts. Ein Creator kann nicht fuer einen
        anderen zustaendig sein -- das waere eine Rolle, die es nicht gibt.
 
-       WICHTIG: Ein Eintrag auf DogFather oder Manager aendert an den
-       RECHTEN nichts. Die Leitung sieht ohnehin jeden Creator; der
-       Eintrag sagt nur, WER sich kuemmert. Nur beim Scout entscheidet er
-       zusaetzlich ueber die Sichtbarkeit -- deshalb steht die Regel
-       dafuer unveraendert in betreuteIds(). */
+       ACHTUNG, SEIT DEM 01.09.2026 ANDERS: Hier stand frueher "ein
+       Eintrag auf DogFather oder Manager aendert an den Rechten nichts,
+       die Leitung sieht ohnehin jeden Creator". Das gilt nicht mehr --
+       nur noch DogFather sieht alles. Fuer einen MANAGER entscheidet
+       dieser Eintrag jetzt genauso ueber die Sichtbarkeit wie fuer einen
+       Scout: Wer ihm nicht zugeteilt ist (weder direkt noch ueber einen
+       seiner Scouts), taucht bei ihm nicht auf.
+
+       Nur bei DogFather sagt der Eintrag weiterhin bloss, WER sich
+       kuemmert. Die Regel dazu steht an genau einer Stelle:
+       betreuteIds() in workspace.js. */
     if (!betreuer || !["admin", "manager", "scout"].includes(betreuer.rolle)) {
       return res.status(400).json({
         fehler: "Zuständig können nur aktive DogFather, Manager oder Scouts sein.",
@@ -170,6 +185,63 @@ personenRouter.put("/workspace/api/verwaltung/betreuung/:id", gleicheHerkunft, (
   }
 });
 
+/* ---------- Welcher Scout gehoert zu welchem Manager --------------------
+
+   "er soll nur die Scouts sehen, die ihm zugeteilt sind." (01.09.2026)
+
+   NUR DOGFATHER darf das setzen -- ausdruecklich so entschieden, und
+   der Grund ist nicht Misstrauen, sondern Bauart: Diese Zuteilung
+   ERWEITERT die Sicht eines Managers (auf die Leads seiner Scouts und
+   auf deren Creator). Duerfte er sie selbst setzen, koennte er sich
+   seine eigene Sichtbarkeit vergeben -- und eine Grenze, die der
+   Begrenzte selbst verschieben kann, ist keine.
+
+   Deshalb istDogFather und NICHT istLeitung. Der Unterschied ist hier
+   der ganze Punkt.                                                       */
+
+personenRouter.put("/workspace/api/verwaltung/scout-zuteilung/:id", gleicheHerkunft, (req, res) => {
+  try {
+    if (!istDogFather(req.person)) {
+      /* 404 und nicht 403: Wer es nicht darf, soll nicht einmal
+         erfahren, dass es diesen Weg gibt. */
+      return res.status(404).json({ fehler: "nicht_gefunden" });
+    }
+    const id = Number(req.params.id);
+    if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
+
+    const scout = db().prepare("SELECT id, rolle FROM personen WHERE id = ?").get(id);
+    if (!scout || scout.rolle !== "scout") {
+      return res.status(404).json({ fehler: "nicht_gefunden" });
+    }
+
+    const w = req.body?.manager_id;
+    if (w === null || w === "" || w === undefined) {
+      scoutZuteilungSetzen(id, null, req.person.id);
+      protokolliere("scout_zuteilung", req.person, echteIp(req), `${id}: geloest`);
+      return res.json({ ok: true, manager_id: null });
+    }
+
+    const z = Number(w);
+    if (!Number.isInteger(z) || z < 1) return res.status(400).json({ fehler: "Ungültige Auswahl." });
+    const manager = db().prepare(
+      "SELECT id, name, rolle FROM personen WHERE id = ? AND aktiv = 1").get(z);
+    /* NUR ein Manager. Ein Scout unter einem Scout waere eine Ordnung,
+       die es nicht gibt; ein Scout unter DogFather ist ueberfluessig, da
+       er ohnehin alles sieht -- und ein Eintrag, der nichts bewirkt,
+       wird beim naechsten Mal fuer eine Wirkung gehalten. */
+    if (!manager || manager.rolle !== "manager") {
+      return res.status(400).json({ fehler: "Zuteilen kann man nur an einen aktiven Manager." });
+    }
+
+    scoutZuteilungSetzen(id, z, req.person.id);
+    protokolliere("scout_zuteilung", req.person, echteIp(req), `${id} -> ${z}`);
+    res.json({ ok: true, manager_id: z, manager_name: manager.name });
+  } catch (fehler) {
+    console.error("[workspace] Scout-Zuteilung:", fehler?.message);
+    res.status(503).json({ fehler: "nicht_verfuegbar" });
+  }
+});
+
 /* ---------- Anlegen ----------------------------------------------------- */
 
 personenRouter.post("/workspace/api/verwaltung/personen", gleicheHerkunft, (req, res) => {