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:
@@ -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' },
|
||||
|
||||
Reference in New Issue
Block a user