Die Community-Rolle laesst sich endlich anlegen
Filipe: "und wieso kann ich immer noch keine community rolle
erstellen?"
Nachgemessen statt geraten: Die Auskunft schickte "gast/Community" als
waehlbare Rolle mit, die Oberflaeche baute den Knopf daraus -- und das
Anlegen antwortete 400 "Unbekannte Rolle." Genau so reproduziert.
DIE URSACHE: EINE LISTE, ZWEI FRAGEN
Die Pruefung las `ROLLEN`, und `ROLLEN` ist `ROLLEN_REIHE` -- die
SORTIERREIHENFOLGE. Dort fehlt "gast" mit Absicht; der Kommentar in
workspace.js sagt es woertlich ("steht mit Absicht NICHT in der Liste,
sie faellt ans Ende").
`ROLLEN_REIHE` beantwortet "in welcher Reihenfolge", nicht "welche gibt
es". Genau davor wird in diesem Haus an zehn Stellen gewarnt -- und
hier stand es vier Zeilen ueber der Stelle, an der es passiert ist.
Gefragt wird jetzt `darfAnlegen` -- dieselbe Auskunft, aus der die
Oberflaeche ihre Knoepfe baut. Damit koennen die beiden nicht mehr
auseinanderlaufen.
ZWEI NEBENBEFUNDE, beide groesser als der gemeldete Fehler:
1. DIE ALTE PRUEFUNG LIESS "admin" DURCH. `ROLLEN_REIHE` enthaelt sie.
Filipes Regel vom 11.09. ("dogfather soll man nicht auswaehlen
koennen, das ist die einzige die man nicht auswaehlen kann") stand
nur in ANLEGBAR -- und die wurde hier nicht gefragt. Es liess sich
also ein zweiter DogFather-Zugang anlegen.
2. DIESELBE ZEILE STAND EIN ZWEITES MAL, beim Rollenwechsel. Auch eine
bestehende Person liess sich nicht zu "Community" machen. Dort stand
die richtige Pruefung (`darfAnlegen`) schon direkt darunter -- die
falsche davor kam ihr nur zuvor. Und sie antwortete gespraechiger
(403 "Diese Rolle vergibst du nicht." gegen 400 "Unbekannte
Rolle."); wer durchprobiert, haette daran ablesen koennen, welche
Rollen es gibt. Jetzt beide Faelle wortgleich.
Gefunden hat das nicht das Lesen, sondern die neue Pruefung: Ihre
Suche nach der alten Zeile reichte in die Nachbarroute hinein.
NEU: pruef-rollen-anlegen (11 Pruefungen)
Sie schreibt keine Liste ab, sondern holt sich die Rollen aus
`darfAnlegen` -- derselben Quelle wie Route und Oberflaeche -- und legt
JEDE davon wirklich an. Eine eigene Liste waere eine dritte gewesen und
damit dieselbe Falle noch einmal.
Dazu die Gegenproben: eine erfundene Rolle, eine leere, und ein zweiter
DogFather -- alle drei abgelehnt.
pruef-rollen 315, pruef-personen-formular 36, pruef-personen-liste,
pruef-rechtetafel 19: gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
@@ -730,9 +730,32 @@ personenRouter.post("/workspace/api/verwaltung/personen", gleicheHerkunft, (req,
|
||||
10.09.2026 sind es zwei, und die zweite waere hier sonst still
|
||||
durchgerutscht -- ein Manager haette eine rechte Hand anlegen
|
||||
koennen, ohne dass irgendwo etwas rot wird. */
|
||||
const unbekannt = !ROLLEN.includes(rolle)
|
||||
|| (TEAM_DOGI_ROLLEN.has(rolle) && !istDogFather(req.person));
|
||||
if (unbekannt) return res.status(400).json({ fehler: "Unbekannte Rolle." });
|
||||
/* GEFRAGT WIRD `darfAnlegen`, NICHT `ROLLEN` (17.09.2026).
|
||||
|
||||
HIER STAND `!ROLLEN.includes(rolle)`, und `ROLLEN` ist
|
||||
`ROLLEN_REIHE` -- die SORTIERREIHENFOLGE. Dort fehlt "gast" mit
|
||||
Absicht (der Kommentar in workspace.js sagt es woertlich: "steht
|
||||
mit Absicht NICHT in der Liste, sie faellt ans Ende").
|
||||
|
||||
Folge: Die Oberflaeche bot "Community" an -- sie holt ihre
|
||||
Knoepfe aus `darfAnlegen` --, und der Server antwortete beim
|
||||
Anlegen "Unbekannte Rolle." Filipe, am 17.09.: "und wieso kann
|
||||
ich immer noch keine community rolle erstellen?"
|
||||
|
||||
Das ist die Falle, vor der in diesem Haus an zehn Stellen
|
||||
gewarnt wird: EINE Liste, zwei Fragen. `ROLLEN_REIHE` beantwortet
|
||||
"in welcher Reihenfolge", nicht "welche gibt es".
|
||||
|
||||
`darfAnlegen` beantwortet genau die Frage, die hier zaehlt --
|
||||
und es ist dieselbe Auskunft, aus der die Oberflaeche ihre
|
||||
Knoepfe baut. Damit koennen die beiden nicht mehr auseinander-
|
||||
laufen. Die Team-Dogi-Regel steckt schon darin (ANLEGBAR gibt
|
||||
"hand" und "modi" nur DogFather), ebenso die Regel, dass sich
|
||||
kein zweiter DogFather anlegen laesst -- die das alte `ROLLEN`
|
||||
uebrigens NICHT abgedeckt hat. */
|
||||
if (!darfAnlegen(req.person).includes(rolle)) {
|
||||
return res.status(400).json({ fehler: "Unbekannte Rolle." });
|
||||
}
|
||||
|
||||
/* ERSTER VORBEHALT: Eine Leitung anlegen darf nur DogFather.
|
||||
Duerfte ein Manager das, koennte er sich einen zweiten Zugang mit
|
||||
@@ -859,9 +882,26 @@ personenRouter.put("/workspace/api/verwaltung/personen/:id/rolle", gleicheHerkun
|
||||
/* Dieselbe Auskunft wie beim Anlegen: Wer eine Rolle nicht
|
||||
vergeben darf, darf sie auch nicht zuweisen. Sonst waere das
|
||||
Zuweisen der bequemere Weg an der Regel vorbei. */
|
||||
if (!ROLLEN.includes(rolle)) return res.status(400).json({ fehler: "Unbekannte Rolle." });
|
||||
/* EINE FRAGE, EINE ANTWORT (17.09.2026).
|
||||
|
||||
Hier standen ZWEI Pruefungen untereinander. Die erste las
|
||||
`ROLLEN` -- die Sortierreihenfolge, in der "gast" mit Absicht
|
||||
fehlt -- und lehnte deshalb ab, BEVOR die zweite, richtige
|
||||
ueberhaupt drankam. Eine bestehende Person liess sich damit
|
||||
nicht zu "Community" machen, aus demselben Grund wie beim
|
||||
Anlegen.
|
||||
|
||||
Gefunden hat das nicht das Lesen, sondern pruef-rollen-anlegen:
|
||||
Die Suche nach der alten Zeile reichte noch in diese Route
|
||||
hinein, und dort stand sie ein zweites Mal.
|
||||
|
||||
DIE ZWEITE ANTWORT WAR AUSSERDEM GESPRAECHIGER als die erste
|
||||
("Diese Rolle vergibst du nicht." mit 403 gegen "Unbekannte
|
||||
Rolle." mit 400). Wer durchprobiert, haette daran ablesen
|
||||
koennen, welche Rollen es gibt. Jetzt beide Faelle wortgleich
|
||||
-- wie beim Anlegen. */
|
||||
if (!darfAnlegen(req.person).includes(rolle)) {
|
||||
return res.status(403).json({ fehler: "Diese Rolle vergibst du nicht." });
|
||||
return res.status(400).json({ fehler: "Unbekannte Rolle." });
|
||||
}
|
||||
if (person.rolle === rolle) {
|
||||
return res.status(400).json({ fehler: "Diese Rolle hat sie schon." });
|
||||
|
||||
Reference in New Issue
Block a user