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:
2026-09-17 12:24:11 +02:00
co-authored by Claude Opus 5
parent 79e675b846
commit 4bd19a4096
2 changed files with 260 additions and 5 deletions
+45 -5
View File
@@ -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." });