Workspace: Scouts betreuen Creator wie das Management

Bisher hatten Scouts mit der Creator-Betreuung nichts zu tun -- keine
Profile, keine Betreuungsbereiche, keine Reports. Das aendert sich, mit
zwei bewusst gesetzten Grenzen.

GRENZE 1: nur zugeteilte Creator, keine Rollenregel.

Neue Tabelle betreuung (creator_id PRIMARY KEY -> betreuer_id). Ein
Creator hat genau EINE zustaendige Person, damit nie unklar ist, wer
gefragt ist. Das Management sieht ohnehin alle und braucht keinen
Eintrag. Wer nichts zugeteilt bekommt, sieht weiterhin nichts -- kein
Recht entsteht automatisch aus der Rolle.

Zugeteilt wird in "Personen & Zugaenge", direkt in der Personenzeile:
Betreuung ist eine Eigenschaft der Person, kein eigener Vorgang. Nur das
Management darf zuteilen -- koennte ein Scout sich selbst Creator geben,
haette er die Rechtevergabe in der Hand, die ihn begrenzen soll.
Zustaendig koennen nur aktive Scouts sein, kein Admin (der sieht alles)
und kein anderer Creator.

Bei der Uebergabe aus der Pipeline passiert die Zuteilung von selbst:
Wer jemanden gefunden hat, betreut ihn weiter. Genau darum geht es bei
"Creator-Onboarding starten". Umhaengen kann das Management jederzeit.

GRENZE 2: betreuen, nicht verwalten.

Profile, die fuenf Bereiche und Reports wie ein Manager. ABER:
- keine Zugangscodes, kein Sperren von Personen (personen.html bleibt
  admin-only, unveraendert)
- keine management-internen Felder. Der Scout bekommt admin_notiz,
  plan_start und naechster_review NICHT -- die Felder fehlen in der
  Antwort komplett, nicht nur in der Anzeige. Eine Notiz UEBER die
  Betreuung gehoert nicht in die Hand dessen, der betreut. Geprueft: Ein
  Scout, der admin_notiz mitschickt, aendert sie nicht.

Die Regel steht an EINER Stelle (betreuteIds / betreutWo / darfCreator
in workspace.js) und wird von sechs Modulen benutzt. Eine Rechteregel,
die an sechs Stellen steht, ist eine Rechteregel, die irgendwann an
fuenf Stellen stimmt.

Genau das ist beim Bauen auch passiert: workspace-calls.js hatte eine
wortgleiche Kopie der Kalender-Sichtbarkeit. Erweitert wurde nur der
Kalender -- Scouts sahen die Termine ihrer Creator, dieselben Termine
als Call aber nicht. Die Kopie ist jetzt weg, calls.js importiert die
Regel aus workspace-kalender.js.

Zwei Fehler, die die Aenderung selbst erzeugt haette, vorher gefunden:
- Report-Entscheidung: ein Scout haette eine Aufgabe angelegt, deren
  "Creator" er selbst ist -- die waere in jeder Auswertung falsch
  mitgelaufen. Zeigt jetzt auf einen seiner Creator.
- Bereichseintrag: derselbe Fehler. Ein Scout hat gar keinen eigenen
  Betreuungsbereich. Ein Eintrag ohne oder mit fremder Zuordnung landet
  beim ersten zugeteilten Creator, nie bei einem fremden. Geprueft:
  Mikas Bereich bleibt bei jedem Versuch unberuehrt.

server/workspace-reports.js

@@ -19,7 +19,9 @@
    ===================================================================== */
 
 import express from "express";
-import { db, protokolliere, echteIp, sitzungLesen } from "./workspace.js";
+import {
+  db, protokolliere, echteIp, sitzungLesen, betreuteIds, darfCreator,
+} from "./workspace.js";
 
 export const reportRouter = express.Router();
 
@@ -29,8 +31,11 @@ const tagOffset = (tage) => new Date(Date.now() - tage * 86400_000).toISOString(
 function angemeldet(req, res, next) {
   const person = sitzungLesen(req);
   if (!person) return res.status(401).json({ fehler: "nicht_angemeldet" });
-  /* Scouts haben mit der Creator-Betreuung nichts zu tun. */
-  if (person.rolle === "scout") return res.status(404).json({ fehler: "nicht_gefunden" });
+  /* Ein Scout ohne zugeteilte Creator hat hier nichts zu suchen -- und
+     erfaehrt per 404 auch nicht, dass es den Bereich gibt. */
+  if (person.rolle === "scout" && !betreuteIds(person).length) {
+    return res.status(404).json({ fehler: "nicht_gefunden" });
+  }
   req.person = person;
   next();
 }
@@ -41,11 +46,21 @@ reportRouter.use("/workspace/api/report", angemeldet);
    (oder alle sehen), ein Creator immer nur sich selbst -- unabhaengig
    davon, was im Aufruf steht. */
 function zielCreator(req) {
-  if (req.person.rolle !== "admin") return req.person.id;
+  if (req.person.rolle === "creator") return req.person.id;
+
   const w = req.query.creator;
-  if (!w || w === "alle") return null;
-  const z = Number(w);
-  return Number.isInteger(z) && z > 0 ? z : null;
+  const gewuenscht = w && w !== "alle" && Number.isInteger(Number(w)) && Number(w) > 0
+    ? Number(w) : null;
+
+  if (req.person.rolle === "admin") return gewuenscht;
+
+  /* Scout: darf nur ueber die eigenen Creator einen Report ziehen. Ein
+     fremder Wunsch wird nicht abgelehnt, sondern still auf den ersten
+     eigenen zurueckgesetzt -- so kann man den Parameter nicht dazu
+     benutzen, die Zuteilung anderer abzufragen. */
+  const meine = betreuteIds(req.person);
+  if (gewuenscht && meine.includes(gewuenscht)) return gewuenscht;
+  return meine[0] ?? -1;
 }
 
 reportRouter.get("/workspace/api/report", (req, res) => {
@@ -176,9 +191,18 @@ reportRouter.get("/workspace/api/report", (req, res) => {
 /* Liste der Creator fuer die Auswahl oben. */
 reportRouter.get("/workspace/api/report/creator", (req, res) => {
   try {
-    if (req.person.rolle !== "admin") {
+    if (req.person.rolle === "creator") {
       return res.json({ creator: [{ id: req.person.id, name: req.person.name }] });
     }
+    if (req.person.rolle === "scout") {
+      const ids = betreuteIds(req.person);
+      if (!ids.length) return res.json({ creator: [] });
+      return res.json({
+        creator: db().prepare(
+          `SELECT id, name FROM personen WHERE id IN (${ids.map(() => "?").join(",")})
+           AND aktiv = 1 ORDER BY name`).all(...ids),
+      });
+    }
     res.json({
       creator: db().prepare(
         "SELECT id, name FROM personen WHERE rolle = 'creator' AND aktiv = 1 ORDER BY name").all(),
@@ -222,6 +246,13 @@ reportRouter.post("/workspace/api/report/entscheidung", (req, res) => {
         }
         creator = z;
       }
+    } else if (req.person.rolle === "scout") {
+      /* Ein Scout haelt die Entscheidung fuer einen SEINER Creator fest,
+         nicht fuer sich selbst -- sonst haette die Aufgabe einen Scout
+         als "Creator" und liefe in jeder Auswertung falsch mit. */
+      const w = Number(req.body?.creator_id);
+      creator = darfCreator(req.person, w) ? w : (betreuteIds(req.person)[0] ?? null);
+      if (!creator) return res.status(400).json({ fehler: "Dir ist kein Creator zugeteilt." });
     } else {
       creator = req.person.id;
     }