Spicy Media legt Manager UND Scouts an -- eine Liste statt vier

Filipe, mit Bildschirmfoto der Zugaenge-Seite: "die spicy rolle soll
auch manager und scouts hinzufuegen koennen."

DER MANAGER-KNOPF FEHLTE NICHT AUS RECHTEGRUENDEN. Serverseitig war die
Tuer /workspace/api/manager-anlegen fuer Spicy Media die ganze Zeit
offen. Es gab nur nichts zum Draufdruecken -- wegen ZWEIER Listen in
derselben Funktion, drei Zeilen auseinander (personen.js):

  const darf = ... spicy ? ['manager', 'creator'] : ['creator'];
  ...
  if ((r.wert === 'admin' || r.wert === 'manager') && ich.rolle !== 'admin') continue;

Die erste erlaubt den Manager, die zweite nimmt ihn wieder weg. Uebrig
blieb ein einziger Knopf: Creator. Nichts war kaputt, nichts wurde rot,
es fehlte einfach -- die Sorte Fehler, die nur jemandem auffaellt, der
davorsitzt.

FUER SCOUTS GAB ES UEBERHAUPT KEINE TUER. Nur DogFather konnte welche
anlegen. Und die Wegwahl in der Oberflaeche war eine Kette mit
Auffangbecken (`rolle === 'manager' ? ... : creator-anlegen`): Ein Scout
waere im else gelandet, und creator-anlegen legt IMMER einen Creator an.
Der Knopf haette Erfolg gemeldet und das Falsche getan.

DIE ANTWORT STEHT JETZT AN EINER STELLE. `darfAnlegen` in workspace.js
sagt, wer wen anlegen darf. Daraus lesen:

  - die beiden Team-Tueren (Manager, Scout)
  - die allgemeine Verwaltungs-Tuer von DogFather
  - die Oberflaeche, ueber `darf_anlegen` in /workspace/api/ich

Die Oberflaeche hat damit gar keine eigene Liste mehr und kann deshalb
auch nicht mehr abweichen -- weder zu streng noch zu grosszuegig.

ZWEI TUEREN, NICHT EINE MIT EINEM ROLLENFELD. Der Absatz an der
Manager-Tuer raet davon ab, und der Rat gilt: Eine Tuer, die NICHTS
anderes kann, als eine bestimmte Rolle anzulegen, ist sicherer als eine,
die vorher nachfragt. `teamTuer(rolle)` baut beide aus demselben Text --
die Rolle wird beim Einhaengen festgelegt und kommt nie aus dem Aufruf.
Geprueft: ein mitgeschicktes "rolle: admin" bleibt wirkungslos.

GEPRUEFT (pruef-creator-anlegen, 33 -> 49 Pruefungen)
  - Spicy Media legt Manager an       -> 201, Rolle stimmt
  - Spicy Media legt Scout an         -> 201, Rolle stimmt
  - "rolle: admin" mitgeschickt       -> wirkungslos, es wird ein Scout
  - ein Manager durch die Scout-Tuer  -> 404
  - ein Scout durch die Scout-Tuer    -> 404
  - Personenliste lesen               -> 200 (die eine gewollte Ausnahme)
  - darueber anlegen                  -> 404, und es entsteht niemand
  - /api/ich nennt Spicy: manager, scout, creator -- und keinen DogFather
  - ein Manager bekommt genau eine Rolle genannt, ein Scout keine
  - die Knoepfe auf der Seite stimmen mit alldem ueberein
  - DogFather sieht unveraendert alle -- gemessen, nicht geglaubt

Der erste Anlauf der Pruefung behauptete, Spicy Media komme gar nicht an
/workspace/api/verwaltung. Falsch, und sie wurde zu Recht rot: nurAdmin
laesst genau einen Fall durch, das LESEN der Personenliste. Diese
Trennung ist jetzt festgenagelt.

Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
2026-09-10 21:56:45 +02:00
co-authored by Claude Opus 5
parent 5f270c96c5
commit bcc1c70f4a
28 changed files with 577 additions and 293 deletions
+40 -6
View File
@@ -60,11 +60,26 @@
Aus derselben Liste wie die Beschreibungen, damit die beiden nicht
auseinanderlaufen. */
const darf = ich?.rolle === 'admin' ? [...window.Bereiche.ROLLENFOLGE]
: ich?.rolle === 'spicy' ? ['manager', 'creator']
/* KEINE EIGENE LISTE MEHR (10.09.2026).
Hier standen ZWEI, drei Zeilen auseinander, und sie widersprachen
einander: Die erste erlaubte Spicy Media `['manager','creator']`,
die zweite warf den Manager mit einem `continue` wieder hinaus,
sobald man nicht DogFather war. Uebrig blieb ein einziger Knopf.
Serverseitig war die Tuer fuer den Manager die ganze Zeit offen —
es gab nur nichts zum Draufdruecken. Genau so sieht dieser Fehler
aus: Nichts ist kaputt, nichts wird rot, es fehlt einfach.
Die Liste kommt jetzt vom Server (`darf_anlegen` aus /api/ich).
Damit kann sie nicht mehr abweichen — weder zu streng noch zu
grosszuegig. Faellt die Angabe aus (alte Fassung im Zwischen-
speicher), bleibt der Creator uebrig: das Wenigste, nicht das
Meiste. */
const darf = Array.isArray(ich?.darf_anlegen) && ich.darf_anlegen.length
? ich.darf_anlegen
: ['creator'];
for (const r of ROLLEN.filter((x) => darf.includes(x.wert))) {
if ((r.wert === 'admin' || r.wert === 'manager') && ich.rolle !== 'admin') continue;
ziel.append(rollenKnopf(ziel, r));
}
}
@@ -856,10 +871,29 @@
Der Server prueft ohnehin, WER durch welche Tuer darf. Diese
Zeilen sorgen nur dafuer, dass niemand gegen eine verschlossene
laeuft. */
/* EINE TUER JE ROLLE, UND ZWAR AUSGESCHRIEBEN (10.09.2026).
Hier stand `rolle === 'manager' ? manager-anlegen :
creator-anlegen` — ein Zweig mit einem Auffangbecken. Solange
es nur zwei Rollen gab, stimmte das. Mit dem Scout waere es
still falsch geworden: Er waere im `else` gelandet, und
`creator-anlegen` legt IMMER einen Creator an. Der Knopf haette
funktioniert, die Meldung haette Erfolg gemeldet, und in der
Liste stuende ein Creator, wo ein Scout stehen sollte.
Eine Zuordnung statt einer Kette: Wer keine Tuer hat, bekommt
eine Fehlermeldung — nicht die naechstbeste Tuer. */
const rolle = gewaehlteRolle();
const weg = ich.rolle === 'admin' ? '/workspace/api/verwaltung/personen'
: rolle === 'manager' ? '/workspace/api/manager-anlegen'
: '/workspace/api/creator-anlegen';
const TUEREN = {
manager: '/workspace/api/manager-anlegen',
scout: '/workspace/api/scout-anlegen',
creator: '/workspace/api/creator-anlegen',
};
const weg = ich.rolle === 'admin' ? '/workspace/api/verwaltung/personen' : TUEREN[rolle];
if (!weg) {
melde(`Für die Rolle „${rolle}“ gibt es hier keinen Weg.`);
return;
}
const a = await hole(weg, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },