Spicy Media: sieben stille Luecken -- und der Kalender zeigt wirklich nur noch Eigenes

Filipe hat drei Sachen gemeldet. Zwei davon waren nicht das, wonach sie
aussahen.

1. "BEI DER SPICY ROLLE IST DA EIN PROBLEM" (Creator-Profil laedt nicht)

Nicht diese Seite war kaputt. In NEUN Skripten stand dieselbe Zeile

    const LEITUNG = new Set(['admin', 'manager']);

und in keinem davon 'spicy'. profil.js nahm deshalb den Creator-Zweig
und lud das EIGENE Profil -- ein Spicy-Zugang ist kein Creator, also
404. Acht der neun sind nicht kaputtgegangen; sie haben sich still
falsch verhalten.

Die Liste steht jetzt EINMAL in bereiche.js. Beim Aufraeumen kamen mit
derselben Suche sechs weitere Luecken heraus, alle vom selben Typ:

  * Aufgaben abbrechen -- Server UND Knopf ohne 'spicy'
  * Teilen-Knopf in der Kopfleiste -- ohne 'spicy'
  * Chat: die Gespraechsliste laeuft ueber eine feste Rollenfolge.
    Wer nicht darin steht, taucht gar nicht auf -- eine Person, die es
    fuer die anderen nicht gibt.
  * Kalender: dieselbe Rollenfolge, dort landete Spicy Media durch
    indexOf() === -1 ganz oben statt an ihrem Platz.
  * Dashboard: "Creator anlegen" nur fuer admin/manager -- der Server
    haette sie gelassen, den Knopf hat sie nie gesehen.
  * Personenliste: ROLLENNAME ohne 'spicy'. Der Auffangwert
    `|| p.rolle` schrieb "spicy" statt "Spicy Media" -- plausibel
    genug, um jahrelang zu bleiben.

`pruef-css-klassen.mjs` verlangt jetzt, dass kein Workspace-Skript sich
wieder eine eigene Rollenliste baut. Mit Gegenprobe, dass der Sucher so
eine Liste auch wirklich findet.

2. "DIE ZAHLEN DIESE KATEGORIE NICHT SEHEN"

Kachel und Seite waren beim Anlegen der Rolle auf ["spicy","admin"]
gesetzt worden -- "dieselben Rechte ausser Automationen". Beides jetzt
auf DogFather allein.

3. "IN CIGDEMS KALENDER STEHT IMMER NOCH MEIN MANAGER MEETING"

Das war MEIN Denkfehler von heute Frueh, nicht ein vergessener Fall.
Ich hatte "geht alle an" als "kein Teilnehmer eingetragen" definiert --
also entschied der Server, was alle angeht, und nicht der, der den
Termin anlegt. Wer niemanden eintraegt, meint aber meistens nicht
"alle", sondern "mich".

Der Fall ist entfallen. Sichtbar ist ein Termin jetzt nur noch fuer
den, der ihn angelegt hat, dem er zugeordnet ist, der das Gegenueber
ist -- oder der in der Teilnehmerliste steht. Damit ist das Markieren
im Termin die einzige Antwort auf "wen geht das an": eine sichtbare
Entscheidung im Formular statt einer unsichtbaren Regel im Server.

Calls & Protokolle rufen dieselbe Funktion auf und koennen deshalb gar
nicht auseinanderlaufen -- das war Filipes vierter Wunsch, und er ist
mit derselben Zeile erledigt.

Am laufenden System als Cigdem nachgemessen: Profil laedt ("Profil:
Luna"), Zahlen-Kachel weg und Seite gesperrt, im Kalender NUR der
Termin, bei dem sie markiert ist, Calls zeigt genau denselben.

Fuenf Pruefungen auf die endgueltige Regel umgeschrieben statt
geloescht (sicht, spicy, teilnehmer, scout-zuteilung, css-klassen).
Die dritte Drehung bei scout-zuteilung steht mit allen drei Staenden
in der Akte -- eine geloeschte Pruefung hinterlaesst keine Spur davon,
dass hier einmal etwas anderes galt.

Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
2026-09-07 07:36:59 +02:00
co-authored by Claude Opus 5
parent 4eab64bd20
commit ac432d85e1
41 changed files with 484 additions and 260 deletions
+59
View File
@@ -426,6 +426,65 @@ console.log("\n=== Gegenprobe ===");
"aus classList.add(bedingung ? 'a' : 'b') werden beide Klassen gelesen, aber nicht die Variable");
}
/* =======================================================================
KEIN SKRIPT BAUT SICH SEINE EIGENE ROLLENLISTE
Am 07.09.2026 hat Filipe gemeldet, dass „Creator-Profile" bei Spicy
Media abbricht. Die Ursache war nicht diese Seite: In NEUN Skripten
stand `const LEITUNG = new Set(['admin', 'manager'])`, und in keinem
davon `spicy`. profil.js nahm deshalb den Creator-Zweig und lud das
eigene Profil -- ein Spicy-Zugang ist kein Creator, also 404.
Acht der neun sind nicht kaputtgegangen. Sie haben sich still falsch
verhalten, und das ist der Grund für diese Prüfung: Die Liste steht
jetzt EINMAL in bereiche.js, und wer sich wieder eine eigene baut,
bekommt hier einen Fehler statt in vier Wochen eine Fehlermeldung
bei einer Rolle, an die niemand gedacht hat.
======================================================================= */
console.log("\n=== Rollenlisten: eine Quelle, nicht neun");
{
const jsOrdner = join(WS, "assets/js");
const dateien = readdirSync(jsOrdner).filter((n) => n.endsWith(".js"));
ok(dateien.length >= 15, `${dateien.length} Workspace-Skripte durchgesehen`);
/* Gesucht wird eine Rollenliste, die 'admin' enthält und in einer
Zuweisung steht -- also `new Set([...])` oder `= [...]`. Der
Kommentar in bereiche.js, der den alten Fehler ZITIERT, darf nicht
mitzählen: Sonst verdeckt ausgerechnet die Erklärung den Befund. */
const eigenbau = [];
for (const n of dateien) {
const roh = readFileSync(join(jsOrdner, n), "utf8");
const text = roh.replace(/\/\*[\s\S]*?\*\//g, " ").replace(/\/\/[^\n]*/g, " ");
for (const m of text.matchAll(/(?:new Set\(\s*)?\[\s*((?:'[a-z]+'\s*,\s*)*'[a-z]+')\s*\]/g)) {
const rollen = m[1].split(",").map((x) => x.trim().replace(/'/g, ""));
if (!rollen.includes("admin") || rollen.length < 2) continue;
/* bereiche.js DARF: dort steht die eine Quelle. Und die Listen an
den Kacheln selbst sind etwas anderes -- sie sagen, wer eine
KACHEL sieht, nicht wer zur Leitung gehört. Erkennbar daran,
dass sie hinter `rollen:` stehen. */
if (n === "bereiche.js") continue;
const davor = text.slice(Math.max(0, m.index - 40), m.index);
if (/rollen\s*:\s*$/.test(davor)) continue;
eigenbau.push(`${n}: [${rollen.join(", ")}]`);
}
}
ok(eigenbau.length === 0, eigenbau.length
? `eigene Rollenliste gefunden: ${eigenbau.slice(0, 4).join(" · ")}`
: "kein Skript baut sich eine eigene Rollenliste");
/* GEGENPROBE: Der Sucher muss so eine Liste auch WIRKLICH finden --
sonst wäre die Zeile darüber grün, weil das Muster nie greift. */
const probe = " const LEITUNG = new Set(['admin', 'manager']);";
const trifft = [...probe.matchAll(/(?:new Set\(\s*)?\[\s*((?:'[a-z]+'\s*,\s*)*'[a-z]+')\s*\]/g)]
.some((m) => m[1].includes("admin"));
ok(trifft, "und der Sucher erkennt so eine Liste auch wirklich");
/* Und die eine Quelle muss die Rolle enthalten, um die es ging. */
const quelle = readFileSync(join(jsOrdner, "bereiche.js"), "utf8");
ok(/LEITUNG\s*=\s*new Set\(\[[^\]]*'spicy'[^\]]*'admin'[^\]]*'manager'[^\]]*\]\)/.test(quelle),
"bereiche.js führt Spicy Media, DogFather und Manager als Leitung");
}
/* =======================================================================
DIE SIEBEN KOPIEN DER MODULLISTE MÜSSEN GLEICH SEIN
+19 -7
View File
@@ -368,20 +368,32 @@ await bDogi.kontext.close();
aufgeloest: "die manager sollen diese kategorien garnicht sehen."
Seitdem fuehrt personen.html fuer ihn zurueck zur Startseite.
Die Pruefung wird deshalb nicht geloescht, sondern umgedreht -- eine
geloeschte Pruefung hinterlaesst keine Spur davon, dass hier einmal
etwas anderes galt. */
AM 07.09.2026 EIN DRITTES MAL GEDREHT, und der Weg dorthin gehoert
in die Akte: Manager sollen "creator und auch wirklich nur creator
hinzufuegen koennen" -- dafuer muessen sie die Seite wieder oeffnen
duerfen. Die Seite geht seither auf; die VERWALTUNG dahinter bleibt
zu.
Genau das ist jetzt die Aussage, und sie ist schaerfer als beide
vorherigen: Nicht "er kommt rein" und nicht "er kommt nicht rein",
sondern "er kommt rein UND sieht dort trotzdem keine einzige
Personenzeile". Die beiden Zeilen darunter standen schon vorher da
und waren die ganze Zeit die wichtigeren -- sie messen, dass er sich
keine Sichtbarkeit zuteilen kann.
Die Pruefung wird bei jeder Drehung umgeschrieben, nie geloescht:
Eine geloeschte Pruefung hinterlaesst keine Spur davon, dass hier
einmal etwas anderes galt -- und der neue Weg waere ab da ungeprueft. */
const bMara = await seiteAls("manager", "CODE-MANA-0001");
const rM = await bMara.seite.evaluate(() => ({
wahlen: document.querySelectorAll('select[id^="manager-"]').length,
personen: document.querySelectorAll(".person").length,
wo: location.pathname,
}));
ok(rM.wo.endsWith("/start.html"),
`ein Manager landet auf der Startseite statt in der Personenverwaltung `
+ `(${rM.wo.split("/").pop()})`);
ok(rM.wo.endsWith("/personen.html"),
`ein Manager kommt auf die Personenseite (${rM.wo.split("/").pop()})`);
ok(rM.personen === 0,
`und sieht dort keine einzige Personenzeile (${rM.personen})`);
`sieht dort aber keine einzige Personenzeile (${rM.personen})`);
ok(rM.wahlen === 0,
`erst recht keine Zuteilungs-Auswahl (${rM.wahlen}) – er koennte sich sonst `
+ "seine eigene Sichtbarkeit vergeben");
+15 -8
View File
@@ -252,9 +252,10 @@ for (const [pfad, name, feld] of [
Verabredungen sieht er nicht mehr in seinem eigenen Kalender; dafuer
gibt es den Umschalter. Genau dieser Wechsel wird hier gemessen:
ohne Umschalter keins der beiden, mit Umschalter genau das eine.
Und ein Termin ohne Teilnehmer geht weiterhin alle an -- sonst
koennte die Regel auch einfach alles ausblenden und waere trotzdem
gruen. */
Dass die Regel nicht einfach ALLES ausblendet, zeigt der Umschalter:
Als Patrick kommen beide seiner Eintraege an. Ohne diesen Nachweis
waere ein Kalender, der gar nichts mehr liefert, die sauberste
Pruefung von allen. */
{
const d2 = new DatabaseSync(process.env.WORKSPACE_DB);
const rein = d2.prepare(
@@ -262,7 +263,12 @@ for (const [pfad, name, feld] of [
VALUES (?,?,?,?,?,?,?)`);
rein.run("PATRICK-TERMIN", "call", heute + "T10:00", 30, idTili, jetzt, idPat);
rein.run("BEN-TERMIN", "call", heute + "T12:00", 30, idLuna, jetzt, idBen);
rein.run("TEAM-TERMIN", "termin", heute + "T14:00", 30, null, jetzt, idPat);
/* Am 07.09.2026 nachgezogen: Ein Termin OHNE Teilnehmer ist kein
Team-Termin mehr, sondern der private Eintrag dessen, der ihn
angelegt hat -- Filipe hat es an seinem "Manager Meeting" in
Cigdems Kalender gesehen. Der hier gehoert also Patrick, und genau
das wird unten geprueft. */
rein.run("PATRICKS NOTIZ", "termin", heute + "T14:00", 30, null, jetzt, idPat);
d2.close();
const j = async (k, s) => {
@@ -273,10 +279,11 @@ for (const [pfad, name, feld] of [
const patT = await j(kDogi, idPat);
ok(!alleT.includes("PATRICK-TERMIN") && !alleT.includes("BEN-TERMIN"),
`DogFather sieht fremde Verabredungen nicht mehr (${alleT.join(", ") || "nichts"})`);
ok(alleT.includes("TEAM-TERMIN"),
"den Termin ohne Teilnehmer aber schon -- der geht alle an");
ok(patT.includes("PATRICK-TERMIN") && !patT.includes("BEN-TERMIN"),
`mit dem Umschalter auf Patrick genau dessen (${patT.join(", ")})`);
ok(!alleT.includes("PATRICKS NOTIZ"),
"auch einen Termin OHNE Teilnehmer nicht -- der gehoert dem, der ihn anlegt");
ok(patT.includes("PATRICK-TERMIN") && patT.includes("PATRICKS NOTIZ")
&& !patT.includes("BEN-TERMIN"),
`mit dem Umschalter auf Patrick genau dessen, beide (${patT.join(", ")})`);
}
/* ================================================================
+28 -10
View File
@@ -375,13 +375,13 @@ const ruf = async (art, weg, keks, koerper) => {
/* Der Kalender folgt seit dem 07.09.2026 einer ANDEREN Regel als
Bereiche und Aufgaben, und das ist Absicht (Begruendung steht bei
termineSichtbar in workspace.js): Dort entscheidet die Rolle, hier
entscheidet allein die BETEILIGUNG. Wer niemanden eintraegt, meint
alle -- also sieht Spicy Media DogFathers teilnehmerlosen Termin
sehr wohl, Max' Verabredung mit Luna dagegen nicht. Genau
umgekehrt zu den beiden Bloecken darueber. Die zwei Zeilen stehen
hier zusammen, weil erst beide zeigen, dass wirklich die
Beteiligung zaehlt und nicht die Rolle -- eine allein waere auch
erfuellt, wenn schlicht alles oder gar nichts ankaeme. */
entscheidet allein die BETEILIGUNG -- und zwar fuer jeden gleich.
Spicy Media sieht deshalb WEDER DogFathers teilnehmerlosen Termin
NOCH Max' Verabredung mit Luna.
Weil hier zweimal "nicht" steht, braucht es die Gegenprobe
darunter zwingend: Sonst waere derselbe gruene Haken auch bei
einem Kalender zu haben, der gar nichts mehr liefert. */
await ruf("POST", "/workspace/api/termine", keksDogi,
{ titel: "DogFathers Team-Termin", art: "termin", beginn: heute + "T20:00", dauer_min: 30 });
await ruf("POST", "/workspace/api/termine", keksMax,
@@ -389,10 +389,28 @@ const ruf = async (art, weg, keks, koerper) => {
creator_id: idLuna });
const term = await ruf("GET", `/workspace/api/termine?von=${heute}&bis=${heute}`, keksSpicy);
const tTitel = (term.daten?.termine || []).map((t) => t.titel);
ok(tTitel.includes("DogFathers Team-Termin"),
`der Termin ohne Teilnehmer geht alle an -- auch sie (${tTitel.join(", ") || "nichts"})`);
ok(!tTitel.includes("DogFathers Team-Termin"),
`auch seinen teilnehmerlosen Termin nicht (${tTitel.join(", ") || "nichts"})`);
ok(!tTitel.includes("Max sein Termin"),
"Max' Verabredung mit Luna dagegen nicht -- die geht nur die beiden an");
"und Max' Verabredung mit Luna auch nicht -- beide gehen sie nichts an");
/* GEGENPROBE ZUM KALENDER: Ein Termin, bei dem sie eingetragen IST,
kommt sehr wohl an. Erst diese Zeile macht die beiden "nicht"
darueber zu einer Aussage. */
/* Ihre Nummer wird hier erfragt und nicht aus Block 2 mitgenommen --
die steht dort in einem eigenen Gueltigkeitsbereich, und eine
Variable ueber drei Bloecke zu schleifen, nur um eine Zahl zu
haben, ist genau die Art Verbindung, die spaeter jemand loest. */
const ichSpicy = await ruf("GET", "/workspace/api/ich", keksSpicy);
const nrSpicy = ichSpicy.daten?.id;
ok(Number.isInteger(nrSpicy) && nrSpicy > 0, `ihre Nummer ist lesbar (${nrSpicy})`);
const mitIhr = await ruf("POST", "/workspace/api/termine", keksDogi,
{ titel: "Abstimmung mit Spicy", art: "termin", beginn: heute + "T22:00",
dauer_min: 30, teilnehmer: [nrSpicy] });
ok(mitIhr.status === 201, `ein Termin MIT ihr angelegt (${mitIhr.status})`);
const term2 = await ruf("GET", `/workspace/api/termine?von=${heute}&bis=${heute}`, keksSpicy);
ok((term2.daten?.termine || []).some((t) => t.titel === "Abstimmung mit Spicy"),
"den sieht sie -- markiert werden ist der Weg, jemanden zu beteiligen");
/* GEGENPROBE: DogFather selbst sieht weiterhin BEIDE. Ohne sie
bewiesen die Zeilen oben nur, dass irgendetwas gefiltert wird. */
+11 -6
View File
@@ -303,14 +303,19 @@ console.log("\n=== Gegenprobe ===");
ok(await siehtTermin(K.luna, geheim),
"jetzt sieht sie ihn — die Messung erkennt auch 'sichtbar'");
/* Und der neue Fall selbst, damit er nicht ungeprüft bleibt: OHNE
Teilnehmer sieht ihn jeder. Ohne diese Zeile bliebe die Regel, die
den Umbau ausgelöst hat, ausgerechnet hier ungemessen. */
/* UND DER FALL, DER SICH AM SELBEN TAG NOCH EINMAL GEDREHT HAT:
Ein Termin OHNE Teilnehmer ist nicht „für alle", sondern privat.
Hier stand zwischenzeitlich das Gegenteil -- Filipe hat an seinem
„Manager Meeting" in Cigdems Kalender gezeigt, warum das falsch
war. Die Teilnehmerliste ist jetzt die einzige Art, jemanden zu
beteiligen; deshalb gehört genau dieser Fall hierher. */
const c = await ruf("POST", "/workspace/api/termine", {
titel: "Geht alle an", art: "termin", beginn: heute + "T21:30",
titel: "Nur fuer mich", art: "termin", beginn: heute + "T21:30",
}, K.dogi);
ok(await siehtTermin(K.luna, c.daten?.id),
"einen Termin ganz ohne Teilnehmer sieht dagegen jeder");
ok(!(await siehtTermin(K.luna, c.daten?.id)),
"einen Termin ganz ohne Teilnehmer sieht nur, wer ihn angelegt hat");
ok(await siehtTermin(K.dogi, c.daten?.id),
" – der nämlich schon, sonst wäre die Zeile darüber wertlos");
}
console.log(`\n${fehler === 0 ? "ALLES IN ORDNUNG" : `${fehler} FEHLER`}`);
+9 -2
View File
@@ -547,13 +547,20 @@ aufgabenRouter.patch("/workspace/api/aufgaben/:id", gleicheHerkunft, (req, res)
unterscheiden. */
/** Wer darf abbrechen? DogFather, Manager, Scouts -- Creator nicht. */
const DARF_ABBRECHEN = new Set(["admin", "manager", "scout"]);
/* Spicy Media steht hier seit dem 07.09.2026 mit drin: Die Rolle hat
"die gleichen rechte wie dogfather ausser Automationen, Personen nur
anlegen, keine privaten Daten". Abbrechen gehoert nicht zu den
Ausnahmen -- sie fehlte hier nur, weil diese Liste beim Anlegen der
Rolle uebersehen wurde. Gefunden hat es keine Ueberlegung, sondern
eine Pruefung, die nach eigenen Rollenlisten sucht
(pruef-css-klassen.mjs). */
const DARF_ABBRECHEN = new Set(["spicy", "admin", "manager", "scout"]);
const ABBRUCH_GRUND_MAX = 500;
aufgabenRouter.post("/workspace/api/aufgaben/:id/abbrechen", gleicheHerkunft, (req, res) => {
try {
if (!DARF_ABBRECHEN.has(req.person.rolle)) {
return res.status(403).json({ fehler: "Nur DogFather, Manager und Scouts können Aufgaben abbrechen." });
return res.status(403).json({ fehler: "Nur DogFather, Spicy Media, Manager und Scouts können Aufgaben abbrechen." });
}
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
+45 -18
View File
@@ -1683,7 +1683,13 @@ const GESCHUETZT = {
Lesezeichen hat, waere weiterhin hineingekommen. Beides gehoert
zusammen: bereiche.js zeigt sie nur noch DogFather, diese Zeile
laesst nur ihn hinein. */
"/workspace/leistung.html": ["spicy", "admin"],
/* NUR DogFather -- auch nicht Spicy Media (07.09.2026, zweite
Praezisierung). Beim Anlegen der Rolle stand hier ["spicy","admin"],
weil Spicy Media "dieselben Rechte ausser Automationen" bekommen
sollte. Filipe hat es an der laufenden Seite gesehen und
widersprochen: "bei der spicy rolle, die zahlen diese kategorie
nicht sehen." */
"/workspace/leistung.html": ["admin"],
/* NUR DogFather (02.09.2026). Die Rollenauswahl verspricht das seit
jeher ("Manager -- dieselben Rechte, ausser der
Personenverwaltung"), die Schranke hielt sich nur nicht daran.
@@ -2370,11 +2376,14 @@ export function termineSichtbar(person, praefix = "t") {
const p = praefix;
/* =====================================================================
JEDER SIEHT NUR SEINE EIGENEN TERMINE -- ODER DIE, DIE ALLE ANGEHEN
(07.09.2026)
JEDER SIEHT NUR SEINE EIGENEN TERMINE (07.09.2026)
Wunsch Filipe: "calls oder termine soll jeder nur sehen die er
selber macht oder jeden betrifft."
Wunsch Filipe, zuerst: "calls oder termine soll jeder nur sehen
die er selber macht oder jeden betrifft." Wenige Stunden spaeter,
nachdem er das Ergebnis gesehen hat, praeziser: "jeder soll und
darf im kalender immer nur seine eigenen eintraege nur sehen."
Die zweite Fassung gilt -- Begruendung unten beim entfallenen
Fall "geht alle an".
DAS GILT AUCH FUER DOGFATHER, und das ist die eigentliche
Aenderung. Bis hierher bekam er `1=1` -- er sah jeden Termin von
@@ -2383,12 +2392,11 @@ export function termineSichtbar(person, praefix = "t") {
eigenen untergehen. Ein Kalender, in dem alles steht, ist kein
Kalender mehr.
"JEDEN BETRIFFT" braucht eine Definition, sonst ist es Auslegung.
Sie steht hier: ein Termin OHNE Gegenueber und OHNE Teilnehmerliste.
Wer einen Termin anlegt und niemanden eintraegt, meint alle -- das
ist die Team-Besprechung, die Schulung, der Feiertag. Sobald auch
nur EINE Person eingetragen ist, ist es eine Verabredung und geht
nur die Beteiligten etwas an.
"EIGEN" IST HIER GENAU DEFINIERT, sonst wird es Auslegung: Ich habe
den Termin angelegt (erstellt_von), er ist mir zugeordnet
(creator_id), ich bin das Gegenueber (teilnehmer_id) -- oder ich
stehe in der Teilnehmerliste. Sonst nichts. Kein Rollenrecht, keine
Betreuung, keine Ausnahme fuer teilnehmerlose Termine.
Diese Regel ersetzt die Rollenfrage vollstaendig: Es gibt hier
nichts mehr, was DogFather sieht und ein Creator nicht. Was ein
@@ -2420,14 +2428,33 @@ export function termineSichtbar(person, praefix = "t") {
+ ` OR ${dabei})`;
const werte = [person.id, person.id, person.id, person.id];
/* "Geht alle an": kein Gegenueber, kein Teilnehmer. `NOT EXISTS` und
nicht `COUNT(*) = 0` -- der Server hoert beim ersten Treffer auf zu
suchen, statt jedes Mal die ganze Nebentabelle zu zaehlen. */
const fuerAlle = `(${p}.creator_id IS NULL AND ${p}.teilnehmer_id IS NULL`
+ ` AND NOT EXISTS (SELECT 1 FROM ${nebenTabelle.tabelle} ta`
+ ` WHERE ta.${nebenTabelle.spalte} = ${p}.id))`;
/* HIER STAND EIN ZWEITER FALL, UND ER IST AM 07.09.2026 ENTFALLEN.
return { wo: `(${eigen} OR ${fuerAlle})`, werte };
Er hiess "geht alle an": ein Termin ohne Gegenueber und ohne
Teilnehmer war fuer jeden sichtbar, nach der Ueberlegung "wer
niemanden eintraegt, meint alle".
Die Ueberlegung war falsch, und Filipe hat es an einem echten Fall
gezeigt: In Cigdems Kalender stand sein "Manager Meeting" -- SEIN
Termin, den er fuer sich eingetragen hatte. Wer keinen Teilnehmer
eintraegt, meint eben meistens nicht "alle", sondern "mich". Und
die Auslegung lag nicht bei dem, der den Termin anlegt, sondern
hier im Code -- das ist die eigentliche Schwaeche gewesen.
Filipe: "jeder soll und darf im kalender immer nur seine eigenen
eintraege nur sehen."
Was alle angeht, geht sie jetzt an, weil jemand sie EINTRAEGT:
"bei calls und protocoll will ich dass jeder seine termine von
seinem kalender sieht und die wenn sie markiert werden im termin."
Die Teilnehmerliste ist damit die einzige Antwort auf die Frage,
wen ein Termin etwas angeht -- eine sichtbare Entscheidung im
Formular statt einer unsichtbaren Regel im Server.
DIESELBE REGEL GILT FUER CALLS & PROTOKOLLE: Die Call-Liste ruft
genau diese Funktion auf (workspace-calls.js -> sichtbar). Beide
Seiten koennen deshalb gar nicht auseinanderlaufen. */
return { wo: eigen, werte };
}
/* =====================================================================