Korrigieren duerfen jetzt beide: Spicy Media und DogFather

Filipe auf die Rueckfrage, wer fremde Eintraege richtigstellen darf:
„ja spicy und dogfather".

Die Vorlage kannte dort nur DogFather („Vergangene Monate sind
gesperrt ... Ausnahme: DogFather"). Das gilt ab jetzt fuer beide --
und zwar fuer BEIDE Faelle, nicht nur fuer einen:

  * einen fremden Eintrag aendern oder loeschen
  * einen abgeschlossenen Monat dafuer kurz oeffnen

ES IST EINE MENGE UND KEINE ZWEITE LISTE. `darfKorrigieren()` gibt
`siehtAlles()` zurueck -- dieselbe Menge, die schon ueber die
Team-Uebersicht und die Zielzahlen entscheidet. Eine eigene
Aufzaehlung derselben zwei Rollen waere die, die beim naechsten Umbau
auseinanderlaeuft. Und inhaltlich gehoert es zusammen: Wer alle
Zahlen sieht und die Ziele setzt, muss einen Zahlendreher gerade
ruecken koennen; zwei verschiedene Grenzen fuer „darf alles sehen"
und „darf etwas richtigstellen" koennte spaeter niemand mehr
erklaeren.

Der Name der Variablen hiess vorher `istAdmin` -- also die Rechnung
statt ihrer Bedeutung. Jetzt heisst sie, was sie beantwortet.

NACHVOLLZIEHBAR BLEIBT ES UNVERAENDERT: Jede Korrektur an einem
fremden Eintrag und jede Aenderung an einem abgeschlossenen Monat
steht mit Name, Rolle und Zeit im Protokoll -- geprueft wird jetzt
ausdruecklich, dass dort auch `spicy` auftaucht.

GEPRUEFT: 206 Pruefungen, 0 Fehler (vorher 194)

Die Grenze wird in beide Richtungen gemessen, nicht nur in eine:
Spicy aendert wirklich (200, und der neue Wert steht in der
Datenbank), Spicy loescht wirklich -- aber ein Manager und ein
fremder Scout werden weiterhin abgewiesen (403), und danach steht
immer noch der Wert von Spicy da. Ohne diese Gegenproben hiesse
„Spicy darf" moeglicherweise „jeder darf". Loeschen ist eigens
geprueft: PATCH und DELETE sind zwei Routen, und zwei Routen koennen
auseinanderlaufen.

Auch die Freigabe fuer alte Monate wird nach Spicys Korrektur wieder
geschlossen gemessen -- eine geoeffnete Tuer ist kein Erfolg.

EINE MEINER PRUEFUNGEN WAR WIEDER FALSCH, NICHT DER CODE: Ich hatte
erwartet, dass ein Manager mit einer fremden Nummer in der Adresse
„nicht bearbeitbar" bekommt. Er bekommt `true` -- weil er gar keine
fremde Liste bekommt, sondern seine eigene; die Nummer wird fuer ihn
schlicht nicht beachtet. Richtiges Verhalten, falsche Frage. Gemessen
wird jetzt, was zaehlt: dass bei ihm kein einziger fremder Eintrag
ankommt.

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

server/pruef-manager-ziele.mjs

@@ -471,6 +471,27 @@ const altNochmal = await schick("scout", `${API}/eintrag/${altId}`, "PATCH",
 ok(altNochmal.status === 409,
   `der Scout kommt auch danach nicht hinein (${altNochmal.status}) — die Freigabe wirkte nur einmal`);
 
+/* SPICY MEDIA DARF SEIT DEM 02.10.2026 DASSELBE WIE DOGFATHER.
+   Filipe auf die Rueckfrage, wer korrigieren darf: „ja spicy und
+   dogfather". Geprueft wird beides -- dass Spicy hineinkommt UND
+   dass die Freigabe danach wieder zu ist. Nur das erste zu pruefen
+   hiesse, eine geoeffnete Tuer fuer einen Erfolg zu halten. */
+const altSpicy = await schick("spicy", `${API}/eintrag/${altId}`, "PATCH",
+  { datum: `${VORMONAT}-09`, notiz: "Korrektur durch Spicy Media" });
+ok(altSpicy.status === 200,
+  `Spicy Media darf im Vormonat ebenfalls korrigieren (${altSpicy.status})`);
+const db2b = new DatabaseSync(process.env.WORKSPACE_DB, { readOnly: true });
+const freigabeNachSpicy = db2b.prepare("SELECT offen FROM mz_freigabe WHERE eins = 1").get();
+db2b.close();
+ok(freigabeNachSpicy.offen === 0,
+  `…und die Freigabe ist auch danach wieder zu (${freigabeNachSpicy.offen})`);
+
+/* UND DIE GRENZE HAELT WEITERHIN: Ein Manager ist keine Leitung. */
+const altManager = await schick("manager", `${API}/eintrag/${altId}`, "PATCH",
+  { datum: `${VORMONAT}-10` });
+ok(altManager.status === 403 || altManager.status === 409,
+  `ein Manager kommt dort weiterhin nicht hinein (${altManager.status})`);
+
 /* =====================================================================
    7 · DIE ZIELZAHLEN
    ===================================================================== */
@@ -1070,31 +1091,86 @@ ok(mitNamen === gesamtEintraege,
 /* =====================================================================
    16 · KEIN KNOPF, DER NICHTS TUT
    ===================================================================== */
-melde("\n=== Bearbeitbar heisst wirklich bearbeitbar ===");
-const spicySicht = await (await hol("spicy",
-  `${API}/eintraege?monat=${MONAT}&aufgabe=creator&person=${IDS.scout}`)).json();
-ok(spicySicht.bearbeitbar === false,
-  "Spicy Media bekommt an einer FREMDEN Liste keine Bearbeiten-Knoepfe angeboten");
-const dogiSicht = await (await hol("admin",
-  `${API}/eintraege?monat=${MONAT}&aufgabe=creator&person=${IDS.scout}`)).json();
-ok(dogiSicht.bearbeitbar === true, "DogFather schon");
+melde("\n=== Wer korrigieren darf (seit 02.10.2026: Spicy UND DogFather) ===");
+
+/* DIE ANGEZEIGTE ERLAUBNIS UND DIE TATSAECHLICHE MUESSEN DIESELBE
+   SEIN. Eine Liste, die „darfst du" sagt und danach 403 liefert, ist
+   schlimmer als eine ohne Knoepfe -- man klickt zweimal, bevor man
+   es glaubt. Deshalb wird hier zu JEDER Anzeige auch der Vollzug
+   gemessen. */
+const sichten = {};
+for (const r of ["spicy", "admin", "manager"]) {
+  sichten[r] = await (await hol(r,
+    `${API}/eintraege?monat=${MONAT}&aufgabe=creator&person=${IDS.scout}`)).json();
+}
+ok(sichten.spicy.bearbeitbar === true,
+  "Spicy Media bekommt an einer fremden Liste Bearbeiten-Knoepfe");
+ok(sichten.admin.bearbeitbar === true, "DogFather ebenfalls");
+/* BEIM MANAGER WAR MEINE ERSTE PRUEFUNG FALSCH, nicht der Code: Er
+   bekommt `bearbeitbar: true` -- weil er gar keine fremde Liste
+   bekommt, sondern seine EIGENE. Die Nummer in der Adresse wird fuer
+   ihn schlicht nicht beachtet. Das ist das richtige Verhalten und
+   die falsche Frage; gemessen gehoert, dass bei ihm nichts Fremdes
+   ankommt. */
+const fremdeIds = new Set(sichten.admin.eintraege.map((e) => e.id));
+ok(fremdeIds.size > 0,
+  `es gibt ueberhaupt fremde Eintraege, die durchsickern koennten (${fremdeIds.size})`);
+ok(!sichten.manager.eintraege.some((e) => fremdeIds.has(e.id)),
+  `ein Manager sieht keinen einzigen davon (${sichten.manager.eintraege.length} eigene)`);
+
 const eigeneSicht = await (await hol("scout",
   `${API}/eintraege?monat=${MONAT}&aufgabe=creator`)).json();
 ok(eigeneSicht.bearbeitbar === true, "und jeder an seiner eigenen");
 
-/* GEGENPROBE: Die Angabe muss mit dem uebereinstimmen, was der Server
-   dann WIRKLICH tut. Eine Anzeige, die „darfst du" sagt und danach
-   403 liefert, ist schlimmer als gar keine. */
-/* EIN EINTRAG, DEN ES WIRKLICH NOCH GIBT. Beim ersten Lauf stand
-   hier `einId` -- der war weiter oben geloescht worden, und die
-   Antwort lautete 404 statt 403. Das haette wie ein bestandener
-   Riegel ausgesehen und war nur „gibt es nicht". */
+/* EIN EINTRAG, DEN ES WIRKLICH NOCH GIBT. Beim ersten Lauf stand hier
+   ein geloeschter -- die Antwort lautete 404 statt 403, und das sah
+   aus wie ein haltender Riegel. */
 const lebtNoch = eigeneSicht.eintraege[0]?.id;
-braucht(!!lebtNoch, "es gibt keinen Eintrag, an dem sich die Absage messen liesse");
+braucht(!!lebtNoch, "es gibt keinen Eintrag, an dem sich das messen liesse");
+
 const spicyVersuch = await schick("spicy", `${API}/eintrag/${lebtNoch}`, "PATCH",
-  { datum: HEUTE, name: "@vonSpicy" });
-ok(spicyVersuch.status === 403,
-  `…und der Server weist Spicy auch wirklich ab, mit 403 (${spicyVersuch.status})`);
+  { datum: HEUTE, name: "@vonSpicyKorrigiert" });
+ok(spicyVersuch.status === 200,
+  `Spicy Media korrigiert einen fremden Eintrag wirklich (${spicyVersuch.status})`);
+
+const dbK = new DatabaseSync(process.env.WORKSPACE_DB, { readOnly: true });
+const angekommen = dbK.prepare("SELECT name FROM mz_eintrag WHERE id = ?").get(lebtNoch);
+const vonSpicy = dbK.prepare(
+  `SELECT COUNT(*) n FROM protokoll
+    WHERE aktion = 'manager_ziele_korrigiert' AND rolle = 'spicy'`).get().n;
+dbK.close();
+ok(angekommen?.name === "@vonSpicyKorrigiert",
+  "…und die Aenderung steht wirklich in der Datenbank");
+ok(vonSpicy >= 1,
+  `…und sie ist unter ihrem Namen protokolliert (${vonSpicy} Eintraege)`);
+
+/* GEGENPROBE: Die Grenze liegt bei der Leitung, nicht bei „irgendwer
+   mit einem Zugang". Ohne diese beiden Zeilen hiesse „Spicy darf"
+   moeglicherweise „jeder darf". */
+const managerVersuch = await schick("manager", `${API}/eintrag/${lebtNoch}`, "PATCH",
+  { datum: HEUTE, name: "@vonManager" });
+ok(managerVersuch.status === 403,
+  `ein Manager wird weiterhin abgewiesen (${managerVersuch.status})`);
+const scout2Versuch = await schick("schnell", `${API}/eintrag/${lebtNoch}`, "PATCH",
+  { datum: HEUTE, name: "@vonFremdemScout" });
+ok(scout2Versuch.status === 403,
+  `ein fremder Scout ebenfalls (${scout2Versuch.status})`);
+
+const dbK2 = new DatabaseSync(process.env.WORKSPACE_DB, { readOnly: true });
+const unveraendert = dbK2.prepare("SELECT name FROM mz_eintrag WHERE id = ?").get(lebtNoch);
+dbK2.close();
+ok(unveraendert?.name === "@vonSpicyKorrigiert",
+  "…und nach beiden Absagen steht immer noch der Wert von Spicy da");
+
+/* Und Loeschen folgt derselben Grenze -- geprueft, nicht angenommen:
+   PATCH und DELETE sind zwei Routen, und zwei Routen koennen
+   auseinanderlaufen. */
+const managerLoeschen = await hol("manager", `${API}/eintrag/${lebtNoch}`, { method: "DELETE" });
+ok(managerLoeschen.status === 403,
+  `ein Manager kann einen fremden Eintrag auch nicht loeschen (${managerLoeschen.status})`);
+const spicyLoeschen = await hol("spicy", `${API}/eintrag/${lebtNoch}`, { method: "DELETE" });
+ok(spicyLoeschen.status === 200,
+  `Spicy Media kann ihn loeschen (${spicyLoeschen.status})`);
 
 /* =====================================================================
    SCHLUSS