Filipe: "eine community rolle und community kategorie, wo die community auch dann nur die sieht" · "wieso nur eine kachel — ich will mehrere, mit mehreren optionen" · "egal welche rolle hinzugefügt wird soll immer nur das sehen was ich erlaube". DIE DRITTE ADRESSE. treff.dogfather-universe.com bekommt eine eigene Weiche (treff-adresse.js), eine eigene Zugangswand, ein eigenes Manifest und acht eigene Bühnenbilder. Ohne sie stünde dort die Wand der Agentur: Spicy-Logo, "Creator Workspace", fünf Rollenkacheln mit den Namen Admin, Manager, Scout, Creator — die komplette Struktur des Unternehmens, vor der Anmeldung, für jeden mit der Adresse. Welche Wand zu welcher Tür gehört, steht jetzt in EINER Tafel (istFremdeWand) statt als Sonderfall im Code. Bei zwei Wänden war ein Sonderfall richtig; bei drei wären es drei geworden, bei vier sechs. SIEBEN BRETTER UND EIN ACHTES NUR FÜRS TEAM. Anschlagbrett, Was ansteht, Der Treff, Wunschliste, Highlights, Regeln & Hilfe, Mitmachen — dazu "Meldungen & Maßnahmen", das ausdrücklich NICHT in TREFF_BEREICHE steht: dort wäre es lautlos bei der Community gelandet und hätte ausgesehen wie die anderen sieben. WAS AUF DEN BRETTERN PASSIERT: "Will ich auch" (eine Stimme je Person, erzwungen durch den Schlüssel, nicht durch eine Prüfung) · Anheften, höchstens drei, gezählt IN der Transaktion · Freigabe vor Sichtbarkeit für Termine und Highlights, wobei Abwesenheit der Ruhezustand ist · Melden mit Pflicht-Grund (DSA Art. 16) · Entfernen mit Grund, der den Beitrag ÜBERLEBT (DSA Art. 17) · drei Stufen, gerechnet statt gespeichert · die Bannleiter: Modi bis 7 Tage, dauerhaft nur DogFather (seine Entscheidung) · "Mitmachen" wird zum Talent, genau einmal. Der Ausschluss wirkt in sitzungLesen() — also nicht nur beim Schreiben. Wer ausgeschlossen ist, ist weg, nicht stumm. ZWEI SEITEN MEHR. treff-regeln.html holt seine ZAHLEN vom Server (Mindestalter 18, Fristen, Anschläge) — ein Regeltext, der eine andere Zahl nennt als die Regel, ist schlimmer als keiner. rechte.html rechnet "Wer sieht was" aus derselben Tafel aus, aus der die Schranke ihre Entscheidung holt. Die Community steht dort bei 3 von 23. SECHS BEFUNDE, KEINEN HAT DAS LESEN GEFUNDEN: · Ein Modi kam über den verborgenen Zugang in den Treff — die Bedingung war durch Ausschluss formuliert und nahm die neue Wand automatisch mit · /api/personen gab einem Mitglied Namen und Rolle von DogFather · Ein DELETE mit Körper wird von Nodes HTTP-Parser mit einem leeren 400 abgewiesen, bevor Express ihn sieht (gemessen). Der Grund reist jetzt in der Adresse · Der Kommentar, der erklärt, warum die Zugangswand keine Rollennamen nennt, nannte selbst einen — in einer ausgelieferten Datei · Zwei Listen für "welche Seiten sind ohne Anmeldung offen". Sie stimmten, weil beide am selben Tag entstanden · Ein Portkonflikt, den ich selbst gebaut hatte (4391 gehört pruef-chat-aufloesen) Dazu zwei feste Zahlen abgeschafft (die 20 in pruef-rechtetafel, die Kachelzahl in pruef-treff) und zwei Werkzeuge, die jetzt SUCHEN statt aufzuzählen: Der Versionsstempel findet seine Manifeste selbst — das dritte hätte sonst keinen bekommen, und die neue App hätte bis zu vier Stunden lang das falsche Zeichen getragen. Das Bildwerkzeug baut beide Zugangswände aus einer Vorlage mit zwei Werten. Zwei neue Kacheltöne, gemessen statt gewählt: #2f2f7f (Abstand 31,4 in Lab) und #7c2771 (29,7). Das schwächste Paar der vorhandenen 34 liegt bei 24,9. Geprüft: treff 69 · treff-werkzeuge 60 · rollen 312 · start-ansicht 147 · crew-adresse 129 · sicht 84 · modi-verborgen 80 · haus-trennung 62 · bereiche-lesend 37 · css-klassen 30 · zwischenspeicher 21 · alle-wege 19 · rechtetafel 19 — alles grün. Co-Authored-By: Claude Opus 5 <[email protected]>
351 lines
17 KiB
JavaScript
351 lines
17 KiB
JavaScript
/* =====================================================================
|
|
DIE RECHTETAFEL — was jede Rolle sehen darf, an einer Stelle
|
|
=====================================================================
|
|
|
|
Filipe, 11.09.2026:
|
|
|
|
"egal welche rolle oder person hinzugefuegt wird soll immer nur
|
|
das sehen wass ich erlaube. mehr nicht. soll nichts so sein dass
|
|
wenn mann eine rolle oder jemanden hinzufuegt dass er dan alles
|
|
sieht, soll jede rolle immer nur das sehen was sie sehen sollen."
|
|
|
|
---------------------------------------------------------------------
|
|
DAS IST EINE UMKEHRUNG DER BAUWEISE, KEINE EINSTELLUNG
|
|
|
|
Vorher galt: erlauben, ausser es steht etwas dagegen. Die Tabelle
|
|
der geschuetzten Seiten hiess sogar so -- "GESCHUETZT ist die
|
|
Ausnahme, nicht die Regel" -- und sie kannte zwei Wege, auf denen
|
|
etwas durchfiel:
|
|
|
|
1. `null` als Wert hiess "jede angemeldete Rolle". NEUN von zwanzig
|
|
Seiten standen darauf: Start, Uebersicht, Aufgaben, Chat,
|
|
Kalender, Dateien, Calls, Start-Check, Wissen. Eine neue Rolle
|
|
erbte sie alle, ohne dass jemand etwas erlaubt haette.
|
|
|
|
2. Eine Seite, die GAR NICHT in der Tabelle stand, fiel durch
|
|
dieselbe Bedingung (`if (erlaubt && ...)`) und war damit
|
|
ebenfalls fuer jeden offen. Das betraf am 11.09.2026 keine
|
|
einzige Seite -- gemessen, nicht gehofft --, aber jede neue
|
|
waere so entstanden.
|
|
|
|
Ab hier gilt das Gegenteil: WAS NICHT IN DIESER TAFEL STEHT, IST
|
|
VERBOTEN. Kein `null`, kein `undefined`, kein Zweig, der etwas
|
|
durchlaesst. `darfSeite()` kennt genau zwei Antworten.
|
|
|
|
---------------------------------------------------------------------
|
|
WARUM DAS NICHT "DIE LISTE EINMAL DURCHGEHEN" IST
|
|
|
|
Das waere die naheliegende Antwort und die falsche. Die Rolle wird
|
|
im Haus an 74 Stellen in 20 Modulen abgefragt (gezaehlt, nicht
|
|
geschaetzt). Drei Gruende, und alle drei sind hier schon eingetreten:
|
|
|
|
* Eine Liste ALTERT. Am 09.09. war `content.html` fuer eine neue
|
|
Rolle offen -- nicht aus Nachlaessigkeit, sondern weil die Seite
|
|
spaeter dazukam als die Ueberlegung.
|
|
* Eine vergessene Erlaubnis SCHWEIGT. Sie faellt nur dem auf, der
|
|
hindurchgeht, und der merkt nichts: Die Seite laedt ja. In der
|
|
anderen Richtung ist es schlimmer -- eine Seite, die zu viel
|
|
zeigt, sieht aus wie eine Seite, die funktioniert.
|
|
* Bei 74 Stellen ist "ich gehe sie alle durch" kein Verfahren,
|
|
sondern ein Vorsatz.
|
|
|
|
Deshalb steht die Antwort nicht in einem Kommentar, sondern in
|
|
`pruef-rechtetafel.mjs`: Eine Rolle ohne Eintrag macht den Prueflauf
|
|
rot. Eine Seite ohne Eintrag macht den Prueflauf rot. Man KANN es
|
|
nicht mehr vergessen.
|
|
|
|
---------------------------------------------------------------------
|
|
DIESE DATEI HAENGT VON NICHTS AB
|
|
|
|
Kein Import aus workspace.js -- sonst gaebe es einen Ring, und die
|
|
Tafel muesste warten, bis das grosse Modul geladen ist. Sie ist
|
|
damit auch ohne laufenden Server pruefbar, genau wie crew-adresse.js.
|
|
===================================================================== */
|
|
|
|
/** Alle Rollen, die es gibt. Muss zu ROLLEN in workspace.js passen --
|
|
* pruef-rechtetafel vergleicht die beiden und wird rot, wenn eine
|
|
* Rolle nur in einer der beiden Listen steht. */
|
|
export const ALLE_ROLLEN = [
|
|
"spicy", "admin", "manager", "scout", "creator", "hand", "modi",
|
|
/* DIE COMMUNITY (11.09.2026). Zuschauer mit einem Zugang, die den
|
|
Treff sehen -- und sonst nichts. Sie steht hier NICHT in `ALLE`
|
|
(siehe unten): Wer neu dazukommt, bekommt genau die zwei Seiten,
|
|
die weiter unten ausdruecklich seinen Namen tragen. */
|
|
"gast",
|
|
];
|
|
|
|
/* Kurzform fuer die Tafel unten. `ALLE` heisst hier ausdruecklich
|
|
"alle Rollen, die es GIBT" -- nicht "alle, die es geben wird".
|
|
Genau darin liegt der Unterschied zum alten `null`. */
|
|
/* ACHTUNG: `ALLE` ist NICHT ALLE_ROLLEN.
|
|
|
|
Es ist die Abkuerzung fuer "alle Rollen, die diese Seiten am
|
|
11.09.2026 schon hatten" -- die sieben des Hauses. Die Community
|
|
gehoert ausdruecklich nicht dazu; sie bekommt ihre Seiten einzeln.
|
|
|
|
Wuerde hier ALLE_ROLLEN stehen, haette jede kuenftige Rolle wieder
|
|
automatisch neun Seiten geerbt -- genau der Fehler, gegen den diese
|
|
Datei gebaut ist, nur mit einem anderen Namen. */
|
|
const ALLE = ["spicy", "admin", "manager", "scout", "creator", "hand", "modi"];
|
|
|
|
/* Schutz der angemeldeten Seiten. Serverseitig, nicht nur im Browser --
|
|
sonst könnte man die Seite einfach direkt aufrufen. */
|
|
/* Pfad -> erlaubte Rollen. `null` heisst: jede angemeldete Rolle.
|
|
|
|
Die Rolle wird hier mitgeprueft und nicht nur in der Schnittstelle.
|
|
Sonst bekommt z. B. ein Creator die Verwaltungsseite zwar ausgeliefert
|
|
(HTTP 200) und sieht ihr Geruest, auch wenn sie danach leer bleibt und
|
|
das Skript ihn wegschickt. Sichtbar sein soll sie gar nicht. */
|
|
|
|
export const SEITEN = {
|
|
/* AUS `null` WURDE EINE LISTE (11.09.2026).
|
|
|
|
Filipe: "egal welche rolle oder person hinzugefuegt wird soll
|
|
immer nur das sehen wass ich erlaube."
|
|
|
|
Diese neun Seiten standen auf `null` -- das hiess "jede
|
|
angemeldete Rolle", also auch jede Rolle, die es noch gar nicht
|
|
gibt. Jetzt stehen die sieben, die es wirklich gibt.
|
|
|
|
FUER DIE VORHANDENEN ROLLEN AENDERT SICH DAMIT NICHTS. Das ist
|
|
Absicht: Eine Umkehrung, die nebenbei Rechte entzieht, waere
|
|
zwei Aenderungen in einer -- und man wuesste hinterher nicht,
|
|
welche der beiden etwas kaputtgemacht hat. Wer hier enger
|
|
stellen will, macht das als eigenen Schritt. */
|
|
/* Die Community sieht hier ihre sieben Kacheln und sonst nichts --
|
|
welche das sind, entscheidet bereicheFuer() in workspace.js. */
|
|
"/workspace/start.html": [...ALLE, "gast"],
|
|
"/workspace/uebersicht.html": [...ALLE],
|
|
/* AUSDRUECKLICH OHNE 'modi' (10.09.2026). Vorher stand hier `null`
|
|
("jede angemeldete Rolle") -- und mit der neuen Rolle hiess das
|
|
auch: sie. Die Seite laedt dann zwar, ihre Schnittstelle antwortet
|
|
ihm aber mit 404, weil `content` nicht zu seinen Bereichen gehoert.
|
|
Eine Seite, die man oeffnen kann und die dann leer bleibt, sieht
|
|
aus wie ein Fehler -- und ist einer.
|
|
|
|
Das ist die Kehrseite von "geschuetzt ist die Regel, nicht die
|
|
Ausnahme": Eine NEUE ROLLE erbt jedes `null` automatisch. Wer eine
|
|
Rolle hinzufuegt, muss diese Liste durchgehen -- der Kachel-Durchgang
|
|
in pruef-rollen findet die Faelle, die dabei auffallen. */
|
|
"/workspace/content.html": ["spicy", "admin", "manager", "scout", "creator"],
|
|
"/workspace/aufgaben.html": [...ALLE],
|
|
/* Chat (06.09.2026): jede Rolle. WEN man erreicht, entscheidet
|
|
schreibbareIds() -- nicht der Zugang zur Seite. Ein Creator, der
|
|
die Seite nicht öffnen dürfte, könnte auch nicht antworten, und
|
|
genau das Antworten ist der Zweck. */
|
|
"/workspace/chat.html": [...ALLE],
|
|
/* NUR DogFather (07.09.2026). Wunsch Filipe: "nimm die kategorie
|
|
zahlen bei jedem weg, nur die rolle dogfather soll die sehen."
|
|
|
|
Bis heute stand hier `null` -- jede Rolle durfte die Seite oeffnen,
|
|
und WESSEN Zahlen jemand sah, entschied sichtbareCreatorIds().
|
|
Die Begruendung dafuer war gut (es sind SEINE Zahlen), sie ist
|
|
jetzt aber nicht mehr meine Entscheidung.
|
|
|
|
WICHTIG: Die Kachel wegzunehmen haette NICHT gereicht. Eine Kachel
|
|
ist ein Weg, keine Schranke -- wer die Adresse kennt oder ein altes
|
|
Lesezeichen hat, waere weiterhin hineingekommen. Beides gehoert
|
|
zusammen: bereiche.js zeigt sie nur noch DogFather, diese Zeile
|
|
laesst nur ihn hinein. */
|
|
/* JETZT WIEDER FUER ALLE (11.09.2026). Filipe, mit der Kachel im
|
|
Bild: "jetzt soll jede rolle diese kachel sehen. spicy, dogfather,
|
|
manager, scout und creator. aber die creator kriegen dan quasi nur
|
|
ihre daten zu sehen und der manager scout dogfather oder spicy
|
|
koennen eintragen."
|
|
|
|
Die Zeile stand seit dem 07.09.2026 auf ["admin"] -- erst "nimm
|
|
die kategorie zahlen bei jedem weg", dann die Praezisierung, dass
|
|
auch Spicy Media sie nicht sieht. Beides ist damit aufgehoben.
|
|
|
|
AUSDRUECKLICH ALS LISTE, NICHT ALS `null`. `null` hiesse "jede
|
|
angemeldete Rolle" -- und damit automatisch auch jede Rolle, die
|
|
es noch gar nicht gibt. Genau das ist am 10.09. bei content.html
|
|
schiefgegangen. Hier stehen die fuenf, die Filipe genannt hat.
|
|
|
|
WER WAS DARF, steht NICHT hier. Diese Zeile oeffnet nur die Tuer.
|
|
Dahinter gilt weiterhin: sichtbareCreatorIds() entscheidet, WESSEN
|
|
Zahlen jemand sieht (ein Creator sieht genau sich selbst), und
|
|
darfEintragen() entscheidet, wer schreiben darf (Leitung + Scout,
|
|
also NICHT der Creator). Beides war schon vorher so gebaut und
|
|
bleibt unangetastet -- es war nur niemand da, der es benutzen
|
|
konnte. */
|
|
"/workspace/leistung.html": ["spicy", "admin", "manager", "scout", "creator"],
|
|
/* NUR DogFather (02.09.2026). Die Rollenauswahl verspricht das seit
|
|
jeher ("Manager -- dieselben Rechte, ausser der
|
|
Personenverwaltung"), die Schranke hielt sich nur nicht daran.
|
|
Wunsch: "die manager sollen diese kategorien garnicht sehen". */
|
|
/* PERSONEN & ZUGAENGE: jetzt auch fuer Manager und Spicy Media
|
|
(07.09.2026).
|
|
|
|
Filipe: "die manager sehen immer noch nicht die kachel personen &
|
|
zugangscode, wo sie dan die neuen creator hinzufuegen koennen ...
|
|
und die sollen in der kategorie wo die jetzt sehen werden auch noch
|
|
das mit den hinzufuegen sehen, alles andere auf der seite sollen die
|
|
weiterhin nicht sehen."
|
|
|
|
DIE SEITE OEFFNET SICH, DIE SCHNITTSTELLEN NICHT. Das ist der ganze
|
|
Trick und der Grund, warum das hier ungefaehrlich ist: Alles unter
|
|
/workspace/api/verwaltung haengt weiterhin an `nurAdmin` -- Rollen
|
|
aendern, Codes neu setzen, sperren, loeschen, Protokoll lesen
|
|
bleiben zu und antworten mit 404. Wer die Seite oeffnet, bekommt
|
|
also genau die Teile zu sehen, fuer die es auch einen Weg gibt.
|
|
|
|
Eine Seite ist kein Schutz, sie ist ein Weg. Der Schutz steht in den
|
|
Schnittstellen, und der ist unveraendert. */
|
|
/* 'hand' kam am 10.09.2026 dazu. Filipe: "ich will dass die rechte
|
|
Hand auch alle sieht."
|
|
|
|
ES WAR DIE DRITTE SCHICHT, DIE ZUSTIMMEN MUSSTE. Die Kachel stand
|
|
da, die Schnittstelle liess sie lesen -- und die Seite selbst warf
|
|
sie auf die Startseite zurueck. Gefunden hat das nicht das Auge,
|
|
sondern pruef-rollen: Sie geht jede Kachel jeder Rolle ab und
|
|
schaut, wo man landet ("Rechte Hand Kachel personen.html LANDET
|
|
AUF start.html").
|
|
|
|
Dass die Seite aufgeht, gibt ihr nichts, was die Schnittstellen ihr
|
|
nicht ohnehin geben: Alles unter /workspace/api/verwaltung ausser
|
|
der Liste antwortet ihr weiterhin mit 404. Eine Seite ist kein
|
|
Schutz, sie ist ein Weg. */
|
|
"/workspace/personen.html": ["spicy", "admin", "manager", "hand"],
|
|
"/workspace/profil.html": ["spicy", "admin", "manager", "scout", "creator"],
|
|
/* Der eigene Steckbrief -- jede Rolle hat einen. Ein Creator wird
|
|
dort nicht hingeschickt (er sieht seinen auf profil.html), darf die
|
|
Seite aber aufrufen: Sie zeigt ihm dasselbe, nur ohne die Akte. */
|
|
/* 'modi' kam am 10.09.2026 dazu. Der Steckbrief ist die EIGENE Seite
|
|
("Dein Bild und deine Kanäle"); profil.html daneben ist der
|
|
Entwicklungsplan eines Creators und fuer ihn sinnlos. Der erste
|
|
Anlauf hatte genau das verwechselt -- die Kachel hiess "Mein
|
|
Profil" und fuehrte auf eine Seite, deren Schnittstelle mit 404
|
|
antwortet, weil sie ausdruecklich nur Creator kennt. Gefunden vom
|
|
neuen Kachel-Durchgang in pruef-rollen. */
|
|
"/workspace/steckbrief.html": ["spicy", "admin", "manager", "scout", "creator", "hand", "modi"],
|
|
"/workspace/kalender.html": [...ALLE],
|
|
"/workspace/dateien.html": [...ALLE],
|
|
/* 'modi' kam am 10.09.2026 dazu -- und es war ein echter Fund: Ohne
|
|
diese Zeile leiteten VIER seiner Kacheln (Live-Ablauf, Community,
|
|
Technik, Ideen-Board) wortlos auf die Startseite zurueck. Der
|
|
Rollen-Rundgang meldete sie trotzdem als "ok": Eine Umleitung ist
|
|
kein Fehler, die Seite laedt ja -- nur eben eine andere. Seither
|
|
prueft pruef-rollen fuer JEDE Rolle, dass jede Kachel, die sie
|
|
bekommt, auch wirklich dort ankommt.
|
|
|
|
WELCHE Bereiche ein Modi oeffnen darf, entscheidet die Liste
|
|
seiner Kacheln (MODI_BEREICHE_ERLAUBT) -- sonst kaeme er ueber die
|
|
Adresszeile auch in die Agentur-Ablage. */
|
|
/* Die sieben Bretter des Treffs laufen ueber dieselbe Seite wie alle
|
|
anderen Bereiche. WELCHE ein Gast oeffnen darf, entscheidet die
|
|
Bereichsliste in workspace-bereiche.js -- diese Zeile oeffnet nur
|
|
die Tuer. Eine Seite ist ein Weg, keine Schranke. */
|
|
"/workspace/bereich.html": ["spicy", "admin", "manager", "scout", "creator", "hand", "modi", "gast"],
|
|
"/workspace/report.html": ["spicy", "admin", "manager", "scout", "creator"],
|
|
"/workspace/scouting.html": ["spicy", "admin", "manager", "scout"],
|
|
/* DIE ARBEITSLAGE DES TEAMS (09.09.2026).
|
|
|
|
Filipe: "so eine kategorie wie ueber die creator will ich dass nur
|
|
fuer die spicy und dogfather rolle auch ueber manager und scouts
|
|
gibt."
|
|
|
|
Nur diese beiden Rollen. Ein Manager sieht seine eigene Zeile hier
|
|
ausdruecklich NICHT -- das ist kein Versehen: Eine Uebersicht ueber
|
|
die Arbeit der Kollegen gehoert der Leitung, nicht der Reihe. Der
|
|
Schutz steht ohnehin in der Schnittstelle (workspace-team.js);
|
|
diese Zeile sorgt nur dafuer, dass niemand vor einer leeren Seite
|
|
steht. */
|
|
"/workspace/team.html": ["spicy", "admin"],
|
|
"/workspace/calls.html": [...ALLE],
|
|
"/workspace/startcheck.html": [...ALLE],
|
|
"/workspace/wissen.html": [...ALLE],
|
|
/* Ebenfalls nur DogFather: Was von allein passiert, bestimmt, was
|
|
allen anderen zugeschoben wird. */
|
|
/* AUTOMATIONEN BLEIBEN BEI DogFather (07.09.2026). Ausdruecklich:
|
|
"bei automationen sollen die nicht sehen." Dahinter liegen
|
|
Sicherungen, die KI und der Zustand des Servers -- das ist Betrieb,
|
|
nicht Betreuung. */
|
|
"/workspace/automation.html": ["admin"],
|
|
/* Die gemeinsame Lage des Teams -- nur die DogFather-Rolle, also
|
|
Filipe und VanVan (10.09.2026). Fuer alle anderen leitet die
|
|
Schranke auf die Startseite; die Schnittstelle dahinter antwortet
|
|
zusaetzlich mit 404. Zwei Schloesser, absichtlich: Faellt eines
|
|
weg, haelt das andere. */
|
|
/* Der Eingang: DogFather und seine rechte Hand. Blueprint 3.1 --
|
|
"Kann im Alltag vertretend Entscheidungen treffen." Genau das
|
|
passiert auf dieser Seite. */
|
|
"/workspace/teamlage.html": ["admin", "hand"],
|
|
|
|
/* DIE REGELN DES TREFFS (11.09.2026). Fuer die Community und fuer
|
|
die, die sie durchsetzen — ein Modi, der die Regeln nicht sehen
|
|
kann, moderiert nach Gefuehl.
|
|
|
|
AUSDRUECKLICH NICHT fuer Manager, Scouts, Creator und Spicy: Sie
|
|
haben mit dem Treff nichts zu tun, und die Seite nennt Fristen,
|
|
Stufen und die Bedingungen des Ausschlusses. */
|
|
"/workspace/treff-regeln.html": ["gast", "modi", "hand", "admin"],
|
|
|
|
/* MELDUNGEN & MASSNAHMEN. Nur wer moderiert -- ausdruecklich OHNE
|
|
"gast": Dort stehen die Namen derer, die gemeldet haben. Eine
|
|
Meldung, die der Gemeldete lesen kann, ist keine Meldung mehr,
|
|
sondern eine Einladung zur Vergeltung. */
|
|
"/workspace/treff-moderation.html": ["modi", "hand", "admin"],
|
|
|
|
/* WER SIEHT WAS. Nur DogFather — die Seite ist eine vollstaendige
|
|
Karte dieses Hauses: jede Seite, jede Rolle. Wer sie hat, weiss,
|
|
wo er es versuchen muesste. */
|
|
"/workspace/rechte.html": ["admin"],
|
|
};
|
|
|
|
/* Die Zugangswaende. Sie haben keine Rolle, weil sich dort noch
|
|
niemand angemeldet hat -- sie sind der Ort, an dem das passiert.
|
|
Sie stehen hier nur, damit die Pruefung "jede Datei hat einen
|
|
Eintrag" sie nicht als Luecke meldet. */
|
|
export const OHNE_ANMELDUNG = [
|
|
"/workspace/index.html",
|
|
"/workspace/crew-index.html",
|
|
/* Die Wand des Treffs (11.09.2026). Dritte Adresse, dritte Wand --
|
|
und die erste, vor der jemand steht, der NICHT zum Team gehoert. */
|
|
"/workspace/treff-index.html",
|
|
];
|
|
|
|
/* =====================================================================
|
|
DIE EINE FRAGE, DIE ALLES BEANTWORTET
|
|
===================================================================== */
|
|
|
|
/**
|
|
* Darf diese Person diese Seite oeffnen?
|
|
*
|
|
* Zwei Antworten, keine dritte:
|
|
* - Die Seite steht in der Tafel UND die Rolle steht darin -> ja.
|
|
* - Alles andere -> nein. Auch eine Seite, die es in der Tafel gar
|
|
* nicht gibt. Das ist die eigentliche Aenderung.
|
|
*
|
|
* @param {{rolle?: string}|null} person
|
|
* @param {string} pfad z. B. "/workspace/start.html"
|
|
*/
|
|
export function darfSeite(person, pfad) {
|
|
const rolle = person?.rolle;
|
|
if (!rolle) return false;
|
|
const erlaubt = SEITEN[String(pfad || "")];
|
|
/* Kein Eintrag heisst NEIN. Vorher hiess es ja -- und genau darin
|
|
lag das Loch, das man einer neuen Seite nicht ansieht. */
|
|
if (!Array.isArray(erlaubt)) return false;
|
|
return erlaubt.includes(rolle);
|
|
}
|
|
|
|
/**
|
|
* Die Tafel aus der anderen Richtung: Rolle -> Seiten.
|
|
*
|
|
* Fuer die Uebersichtsseite ("Wer sieht was") und fuer Pruefungen.
|
|
* ABGELEITET, nicht zweitgeschrieben -- eine zweite Liste waere die
|
|
* Stelle, an der die beiden auseinanderlaufen.
|
|
*/
|
|
export function seitenFuer(rolle) {
|
|
return Object.entries(SEITEN)
|
|
.filter(([, r]) => r.includes(rolle))
|
|
.map(([p]) => p)
|
|
.sort();
|
|
}
|
|
|
|
/** Alle Seiten der Tafel -- fuer die Pruefung gegen die Platte. */
|
|
export function alleSeiten() {
|
|
return Object.keys(SEITEN).sort();
|
|
}
|