Manager-Ziele zu Ende gebaut -- und dabei zwei Loecher gefunden
Filipe: „perfektioniere alles jetzt sofort, es muss ready sein."
Die Vorlage Punkt fuer Punkt gegen das Gebaute gehalten, nicht gegen
meine eigene Liste von heute Mittag. Vier Punkte standen noch offen,
und auf dem Weg dorthin sind zwei Fehler aufgefallen, nach denen
niemand gesucht hat.
DIE ZWEI FEHLER ZUERST -- beide gefunden durch Messen, nicht Denken
1. EINE GELOESCHTE PERSON HAETTE IHRE ZAHLEN MITGENOMMEN.
`mz_eintrag.person_id` stand auf ON DELETE CASCADE. Die Vorlage
sagt aber: „Wer die Rolle verliert, sieht die Kachel nicht mehr;
die Daten bleiben fuer den DogFather erhalten." Mit CASCADE waere
genau das nicht wahr gewesen -- `DELETE FROM personen` haette den
Monatsverlauf eines Menschen lautlos mitgenommen.
Jetzt SET NULL, und Name und Rolle stehen zusaetzlich als Text am
Eintrag (dieselbe Bauweise wie bei support_meldungen). Die Rolle
ist nicht Zierde: Ohne sie wuerde ein abgeschlossener Monat
rueckwirkend an den Zielzahlen einer anderen Rolle gemessen.
Der Umbau laeuft auf dem Bestand von heute Mittag -- Spaltenliste
AUS PRAGMA abgeleitet, nicht gepflegt, und geprueft werden Zeilen
UND Spalten. Am 11.09.2026 hat genau so ein Umbau drei Spalten mit
Inhalt verloren, ohne Fehlermeldung, bei unveraenderter Zeilenzahl.
2. MEIN EIGENER SPERR-TRIGGER HAETTE DAS LOESCHEN BLOCKIERT.
ON DELETE SET NULL ist kein Loeschen, sondern ein UPDATE auf
person_id. Der Trigger sah eine Aenderung an einem abgeschlossenen
Monat und brach ab -- `DELETE FROM personen` waere damit
gescheitert, an einer Stelle, die mit Monatszielen nichts zu tun
hat. Erlaubt ist jetzt genau eine Aenderung an einem alten Monat:
dem Eintrag seinen Besitzer zu nehmen. Als BEDINGUNG und nicht als
`UPDATE OF <spaltenliste>` -- eine Liste muesste jemand pflegen.
Weil `CREATE TRIGGER IF NOT EXISTS` eine geaenderte Fassung nicht
erneuert, wird die alte am INHALT erkannt und ersetzt. Eine
Fassungsnummer muesste jemand hochzaehlen, und das wird vergessen.
DIE VIER OFFENEN PUNKTE DER VORLAGE
04 Jede Aufgabenzeile hat ihr eigenes Zeichen -- aus dem Haus
(`window.Bereiche`), nicht neu gezeichnet: Trichter, Bildschirm,
Buch, Rahmen. Das Statuszeichen bleibt daneben; ein eingefaerbtes
Aufgabenzeichen allein traegt die Stufe nicht.
05 „Farbiger Rand + Badge": Eine Kachel, an der eine Warnung haengt,
traegt jetzt einen feinen Saum -- JEDE Kachel, nicht nur diese.
Eine Regel, die nur an einer Stelle gilt, wird beim naechsten Mal
vergessen.
08 Die Team-Tabelle ist sortierbar: jede Spalte ein Knopf (kein
anklickbares <th> -- das erreicht die Tastatur nicht), mit
aria-sort, und sortiert wird nach ANTEIL statt nach nackter Zahl.
Dazu eine Ampel-Spalte mit Wort. Auf dem Handy verschwindet die
Kopfzeile im Kartenmodus, deshalb steht das Sortieren zusaetzlich
in der Leiste -- sonst waere es auf einem Telefon nicht
vorhanden.
09 Wer die Rolle verliert, steht weiter in der Uebersicht, als
„nicht mehr dabei" und mit der Rolle von damals. Wer geloescht
wurde, erscheint als zusammengefasste Zeile unter dem
mitgeschriebenen Namen.
WAS DER SAUM MICH GELEHRT HAT
Er stand zuerst in start.css und war wirkungslos -- der Browser
lieferte weiter den Faseschatten. Der Grund steht seit dem 25.09.2026
in module.css: `:is()` uebernimmt die Spezifitaet seines staerksten
Arguments, und `.gruppe[data-gruppe]` macht die ganze Modulliste
(0,2,0) -- genau so stark wie `.kachel[data-warn="ja"]`, bei
Gleichstand gewinnt die zuletzt geladene Datei. Dieselbe Falle wie
damals bei den Fokusringen, dieselbe Antwort: Was gegen die Modulform
gewinnen muss, gehoert in die Datei mit der Modulform. Gemerkt habe
ich es nur, weil die Bildmessung den errechneten Schatten AUSGIBT
statt ein Bild zu machen.
Beim Herausschneiden blieb eine Klammer zu viel in start.css stehen --
gefunden von pruef-css-klassen („eine schliessende Klammer ohne
oeffnende"), bevor sie still CSS verschluckt hat.
AUSSERDEM BEHOBEN
* Spicy Media sah an einer FREMDEN Liste „Bearbeiten" und „Loeschen",
und der Server antwortete mit 403. Ein Knopf, der nichts tut, ist
schlimmer als kein Knopf.
* Klick auf eine Person klappt jetzt alle vier Zeilen auf. Die
Vorlage verspricht „zeigt deren Eintraege" -- zugeklappt zeigte
der Klick nur Zahlen.
* Der CSV-Export kennt drei Staende statt zwei: „pflichtig", „neu,
noch ohne Pflicht", „nicht mehr dabei". Vorher hiess beides „nein".
* Das Aufklappen baute die ganze Liste neu und riss den
angeklickten Knopf weg (Fokus sprang nach oben).
GEPRUEFT: 168 Pruefungen, 0 Fehler (vorher 141)
Neu darunter: der Umbau auf einem echten Alt-Bestand (Zeilen, Spalten,
Inhalt, Indizes, Trigger, und ein zweiter Lauf, der nichts mehr tut),
das Loeschen einer Person mit Eintraegen aus einem abgeschlossenen
Monat -- mit Gegenprobe, dass dieselbe Sperre den INHALT weiterhin
nicht aendern laesst.
Zwei meiner neuen Pruefungen haben zuerst sich selbst gemessen statt
den Code: Eine verglich gegen einen Eintrag, den sie vorher geloescht
hatte (404 sah aus wie ein haltender Riegel), die andere meldete eine
fehlende Spalte, die nur ihr eigener Handeinsatz verursacht hatte.
Beide berichtigt.
Am Bildschirm nachgemessen bei 412 px und 1280 px: kein waagerechtes
Schieben, kein eigenes Beruehrziel unter 40 px, genau EINE Kachel mit
Saum und zwanzig ohne.
Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
Claude Opus 5
@@ -434,8 +434,13 @@ ok(triggerHaelt,
|
||||
|
||||
const weit = new Date(Date.now() + 600_000).toISOString().replace("T", " ").slice(0, 19);
|
||||
db2.prepare("UPDATE mz_freigabe SET offen = 1, bis = ? WHERE eins = 1").run(weit);
|
||||
db2.prepare("INSERT INTO mz_eintrag (person_id, aufgabe, monat, datum, erstellt)"
|
||||
+ " VALUES (?,?,?,?,?)").run(IDS.scout, "meeting", VORMONAT, `${VORMONAT}-05`, jetztIso);
|
||||
/* Name und Rolle stehen mit drin -- genau so, wie der Server es tut.
|
||||
Ohne sie waere dieser Eintrag der einzige ohne, und die Pruefung
|
||||
weiter unten („an allen Eintraegen stehen Name und Rolle") haette
|
||||
einen Fehler gemeldet, den nur diese Zeile verursacht hat. */
|
||||
db2.prepare("INSERT INTO mz_eintrag (person_id, von_name, von_rolle, aufgabe, monat, datum, erstellt)"
|
||||
+ " VALUES (?,?,?,?,?,?,?)")
|
||||
.run(IDS.scout, "Kevin", "scout", "meeting", VORMONAT, `${VORMONAT}-05`, jetztIso);
|
||||
const altId = db2.prepare("SELECT last_insert_rowid() AS id").get().id;
|
||||
db2.prepare("UPDATE mz_freigabe SET offen = 0, bis = NULL WHERE eins = 1").run();
|
||||
db2.close();
|
||||
@@ -726,6 +731,222 @@ if (heuteNr === 1) {
|
||||
"…alle seine Zeilen stehen auf neutral, keine einzige warnt");
|
||||
}
|
||||
|
||||
/* =====================================================================
|
||||
13 · WER GEHT, NIMMT SEINE ZAHLEN NICHT MIT
|
||||
=====================================================================
|
||||
|
||||
Vorlage, Punkt 09: „Wer die Rolle verliert, sieht die Kachel nicht
|
||||
mehr; die Daten bleiben fuer den DogFather erhalten."
|
||||
|
||||
DREI WEGE, AUF DENEN JEMAND VERSCHWINDEN KANN, und alle drei muessen
|
||||
die Zahlen stehen lassen: Rollenwechsel, Stilllegung, Loeschung.
|
||||
Der dritte ist der gefaehrliche -- er loescht wirklich eine Zeile
|
||||
in `personen`, und mit ON DELETE CASCADE waere der Monatsverlauf
|
||||
lautlos mitgegangen.
|
||||
===================================================================== */
|
||||
melde("\n=== Wer die Rolle verliert ===");
|
||||
|
||||
const dbV = new DatabaseSync(process.env.WORKSPACE_DB);
|
||||
/* Sandra (scout2) hat weiter oben einen Creator eingetragen. Jetzt
|
||||
wird sie Creator -- sie verliert damit die Kachel. */
|
||||
dbV.prepare("UPDATE personen SET rolle = 'creator' WHERE id = ?").run(IDS.scout2);
|
||||
dbV.close();
|
||||
|
||||
const teamNachWechsel = await (await hol("admin", `${API}/team?monat=${MONAT}`)).json();
|
||||
const sandra = teamNachWechsel.leute.find((x) => x.id === IDS.scout2);
|
||||
ok(!!sandra, "wer die Rolle verliert, steht weiter in der Team-Uebersicht");
|
||||
ok(sandra?.ehemalig === true, '…und ist als „nicht mehr dabei" gekennzeichnet');
|
||||
ok(sandra?.rolle === "scout",
|
||||
`…und wird an der Rolle von DAMALS gemessen (${sandra?.rolle}), nicht an der von heute`);
|
||||
ok(sandra?.aufgaben.find((a) => a.schluessel === "creator")?.zahl >= 1,
|
||||
"…seine Zahlen stehen unveraendert da");
|
||||
|
||||
/* Und die Kachel ist fuer sie zu. */
|
||||
const sandraKeks = await anmelden("scout2", "creator");
|
||||
braucht(!!sandraKeks, "die Person konnte sich nach dem Rollenwechsel nicht anmelden");
|
||||
kekse.scout2 = sandraKeks;
|
||||
const sandraStand = await hol("scout2", `${API}/stand`);
|
||||
ok(sandraStand.status === 404,
|
||||
`…sie selbst kommt nicht mehr an die Kachel (${sandraStand.status})`);
|
||||
|
||||
melde("\n=== Und wer geloescht wird ===");
|
||||
const dbL = new DatabaseSync(process.env.WORKSPACE_DB);
|
||||
dbL.exec("PRAGMA foreign_keys = ON");
|
||||
const vorherZeilen = dbL.prepare(
|
||||
"SELECT COUNT(*) n FROM mz_eintrag WHERE person_id = ?").get(IDS.scout2).n;
|
||||
braucht(vorherZeilen > 0, "die zu loeschende Person hatte gar keine Eintraege");
|
||||
dbL.prepare("DELETE FROM personen WHERE id = ?").run(IDS.scout2);
|
||||
const uebrig = dbL.prepare(
|
||||
"SELECT COUNT(*) n FROM mz_eintrag WHERE person_id IS NULL AND von_name IS NOT NULL").get().n;
|
||||
const weg = dbL.prepare("SELECT COUNT(*) n FROM personen WHERE id = ?").get(IDS.scout2).n;
|
||||
dbL.close();
|
||||
ok(weg === 0, "die Person ist wirklich geloescht (sonst beweist der Rest nichts)");
|
||||
ok(uebrig === vorherZeilen,
|
||||
`ihre ${vorherZeilen} Eintraege stehen noch da, ohne Person (${uebrig})`);
|
||||
|
||||
const teamNachLoeschen = await (await hol("admin", `${API}/team?monat=${MONAT}`)).json();
|
||||
const verwaist = teamNachLoeschen.leute.find((x) => x.id === null);
|
||||
ok(!!verwaist, "DogFather sieht die verwaisten Eintraege als eigene Zeile");
|
||||
ok(verwaist?.name === "Sandra",
|
||||
`…unter dem mitgeschriebenen Namen (${verwaist?.name})`);
|
||||
|
||||
/* =====================================================================
|
||||
14 · DER UMBAU VON CASCADE AUF SET NULL
|
||||
=====================================================================
|
||||
|
||||
Die Tabelle wurde am 02.10.2026 zuerst mit ON DELETE CASCADE
|
||||
ausgeliefert. Der Umbau muss auf einem solchen Bestand laufen --
|
||||
und zwar OHNE eine Zeile und ohne eine Spalte zu verlieren. Genau
|
||||
das ist am 11.09.2026 im Creator Workspace schiefgegangen: 24
|
||||
Spalten hinein, 21 heraus, ohne Fehlermeldung, bei unveraenderter
|
||||
Zeilenzahl.
|
||||
===================================================================== */
|
||||
melde("\n=== Der Umbau auf einem alten Bestand ===");
|
||||
const { managerZieleTabellen } = await import("./manager-ziele-tabellen.js");
|
||||
const altOrdner = mkdtempSync(join(tmpdir(), "ws-mz-alt-"));
|
||||
const altPfad = join(altOrdner, "alt.db");
|
||||
const dbA2 = new DatabaseSync(altPfad);
|
||||
/* Der Stand von heute Mittag, Wort fuer Wort: NOT NULL und CASCADE,
|
||||
ohne von_name und von_rolle. */
|
||||
dbA2.exec(`
|
||||
CREATE TABLE personen (id INTEGER PRIMARY KEY, name TEXT, rolle TEXT, erstellt TEXT);
|
||||
CREATE TABLE leads (id INTEGER PRIMARY KEY, name TEXT);
|
||||
CREATE TABLE mz_eintrag (
|
||||
id INTEGER PRIMARY KEY AUTOINCREMENT,
|
||||
person_id INTEGER NOT NULL REFERENCES personen(id) ON DELETE CASCADE,
|
||||
aufgabe TEXT NOT NULL CHECK (aufgabe IN ('creator','meeting','schulung','werbung')),
|
||||
monat TEXT NOT NULL, datum TEXT NOT NULL,
|
||||
name TEXT, name_klein TEXT, link TEXT, link_klein TEXT,
|
||||
art TEXT, notiz TEXT, lead_id INTEGER, doppelt_bei INTEGER,
|
||||
erstellt TEXT NOT NULL, geaendert TEXT, geaendert_von INTEGER);
|
||||
INSERT INTO personen (id,name,rolle,erstellt) VALUES (1,'Alt','scout','2026-01-01T00:00:00Z');
|
||||
INSERT INTO mz_eintrag (person_id,aufgabe,monat,datum,name,notiz,erstellt)
|
||||
VALUES (1,'creator','2026-10','2026-10-01','@bleibtdrin','wichtige Notiz','x');
|
||||
`);
|
||||
const altSpaltenVorher = dbA2.prepare("PRAGMA table_info(mz_eintrag)").all().length;
|
||||
const altZeilenVorher = dbA2.prepare("SELECT COUNT(*) n FROM mz_eintrag").get().n;
|
||||
|
||||
managerZieleTabellen(dbA2);
|
||||
|
||||
const altSpaltenNachher = dbA2.prepare("PRAGMA table_info(mz_eintrag)").all().map((x) => x.name);
|
||||
const altZeilenNachher = dbA2.prepare("SELECT COUNT(*) n FROM mz_eintrag").get().n;
|
||||
const altVerweis = dbA2.prepare("PRAGMA foreign_key_list(mz_eintrag)").all()
|
||||
.find((v) => v.from === "person_id");
|
||||
const altInhalt = dbA2.prepare("SELECT name, notiz FROM mz_eintrag").get();
|
||||
|
||||
ok(String(altVerweis?.on_delete).toUpperCase() === "SET NULL",
|
||||
`aus CASCADE wurde SET NULL (${altVerweis?.on_delete})`);
|
||||
ok(altZeilenNachher === altZeilenVorher,
|
||||
`keine Zeile verloren (${altZeilenVorher} -> ${altZeilenNachher})`);
|
||||
ok(altSpaltenNachher.length >= altSpaltenVorher,
|
||||
`keine Spalte verloren (${altSpaltenVorher} -> ${altSpaltenNachher.length})`);
|
||||
ok(altSpaltenNachher.includes("von_name") && altSpaltenNachher.includes("von_rolle"),
|
||||
"die beiden neuen Spalten sind da");
|
||||
ok(altInhalt?.name === "@bleibtdrin" && altInhalt?.notiz === "wichtige Notiz",
|
||||
"und der INHALT steht noch drin (nicht nur die Zeile)");
|
||||
|
||||
/* Die Indizes muessen den Umbau ueberlebt haben -- sie haengen an der
|
||||
Tabelle und verschwinden mit ihr. */
|
||||
const altIndizes = dbA2.prepare(
|
||||
"SELECT COUNT(*) n FROM sqlite_master WHERE type='index' AND tbl_name='mz_eintrag'"
|
||||
+ " AND name LIKE 'idx_mz%'").get().n;
|
||||
ok(altIndizes >= 5, `die ${altIndizes} Indizes sind wieder da`);
|
||||
const altTrigger = dbA2.prepare(
|
||||
"SELECT COUNT(*) n FROM sqlite_master WHERE type='trigger' AND tbl_name='mz_eintrag'").get().n;
|
||||
ok(altTrigger === 3, `und die drei Sperr-Trigger ebenfalls (${altTrigger})`);
|
||||
|
||||
/* GEGENPROBE: Ein zweiter Lauf darf NICHTS mehr tun. Ein Umbau, der
|
||||
bei jedem Serverstart wieder losliefe, waere eine Zeitbombe. */
|
||||
const vorZweitem = dbA2.prepare("SELECT COUNT(*) n FROM mz_eintrag").get().n;
|
||||
managerZieleTabellen(dbA2);
|
||||
const nachZweitem = dbA2.prepare("SELECT COUNT(*) n FROM mz_eintrag").get().n;
|
||||
ok(vorZweitem === nachZweitem,
|
||||
`ein zweiter Lauf laesst alles, wie es ist (${vorZweitem} -> ${nachZweitem})`);
|
||||
|
||||
/* DIE LOESCHUNG EINER PERSON MIT ALTEN EINTRAEGEN.
|
||||
|
||||
Der wichtigste Fall dieses ganzen Blocks, und er ist beim Bauen
|
||||
schiefgegangen: ON DELETE SET NULL ist kein Loeschen, sondern ein
|
||||
UPDATE auf mz_eintrag.person_id. Der Sperr-Trigger hat das als
|
||||
Aenderung an einem abgeschlossenen Monat gesehen und abgebrochen --
|
||||
damit waere das Loeschen einer Person in workspace-personen.js
|
||||
gescheitert, an einer Stelle, die mit Monatszielen nichts zu tun
|
||||
hat. Hier steht der Eintrag ausdruecklich in einem Monat, der NICHT
|
||||
der laufende ist (mz_lage steht in dieser Wegwerf-Datenbank auf
|
||||
'0000-00'). */
|
||||
dbA2.exec("PRAGMA foreign_keys = ON");
|
||||
let loeschenGing = true;
|
||||
try {
|
||||
dbA2.prepare("DELETE FROM personen WHERE id = 1").run();
|
||||
} catch (f) {
|
||||
loeschenGing = false;
|
||||
console.log(" (Grund: " + f?.message + ")");
|
||||
}
|
||||
ok(loeschenGing,
|
||||
"eine Person mit Eintraegen aus einem ABGESCHLOSSENEN Monat laesst sich loeschen");
|
||||
|
||||
/* GEGENPROBE: Der Inhalt eines alten Monats bleibt trotzdem gesperrt.
|
||||
Ohne diese Zeile waere nur bewiesen, dass die Sperre nachgibt --
|
||||
nicht, dass sie noch etwas haelt. */
|
||||
let inhaltGesperrt = false;
|
||||
try {
|
||||
dbA2.prepare("UPDATE mz_eintrag SET notiz = 'heimlich' WHERE name = '@bleibtdrin'").run();
|
||||
} catch (f) {
|
||||
inhaltGesperrt = String(f?.message || "").includes("monat_gesperrt");
|
||||
}
|
||||
ok(inhaltGesperrt,
|
||||
"…aber den INHALT eines alten Monats laesst dieselbe Sperre weiterhin nicht aendern");
|
||||
|
||||
const nachLoeschen = dbA2.prepare("SELECT person_id, name, notiz FROM mz_eintrag").get();
|
||||
ok(nachLoeschen?.notiz === "wichtige Notiz",
|
||||
"…und die Notiz steht unveraendert da");
|
||||
dbA2.close();
|
||||
try { rmSync(altOrdner, { recursive: true, force: true }); } catch { /* egal */ }
|
||||
ok(nachLoeschen && nachLoeschen.person_id === null && nachLoeschen.name === "@bleibtdrin",
|
||||
"nach dem Loeschen der Person bleibt der Eintrag, nur ohne Besitzer");
|
||||
|
||||
/* =====================================================================
|
||||
15 · WAS AM EINTRAG MITGESCHRIEBEN WIRD
|
||||
===================================================================== */
|
||||
melde("\n=== Name und Rolle stehen am Eintrag ===");
|
||||
const dbN = new DatabaseSync(process.env.WORKSPACE_DB, { readOnly: true });
|
||||
const mitNamen = dbN.prepare(
|
||||
"SELECT COUNT(*) n FROM mz_eintrag WHERE von_name IS NOT NULL AND von_rolle IS NOT NULL").get().n;
|
||||
const gesamtEintraege = dbN.prepare("SELECT COUNT(*) n FROM mz_eintrag").get().n;
|
||||
dbN.close();
|
||||
ok(gesamtEintraege > 0, `es gibt ueberhaupt Eintraege zum Pruefen (${gesamtEintraege})`);
|
||||
ok(mitNamen === gesamtEintraege,
|
||||
`an allen ${gesamtEintraege} Eintraegen stehen Name und Rolle (${mitNamen})`);
|
||||
|
||||
/* =====================================================================
|
||||
16 · KEIN KNOPF, DER NICHTS TUT
|
||||
===================================================================== */
|
||||
melde("\n=== Bearbeitbar heisst wirklich bearbeitbar ===");
|
||||
const spicySicht = await (await hol("spicy",
|
||||
`${API}/eintraege?monat=${MONAT}&aufgabe=creator&person=${IDS.scout}`)).json();
|
||||
ok(spicySicht.bearbeitbar === false,
|
||||
"Spicy Media bekommt an einer FREMDEN Liste keine Bearbeiten-Knoepfe angeboten");
|
||||
const dogiSicht = await (await hol("admin",
|
||||
`${API}/eintraege?monat=${MONAT}&aufgabe=creator&person=${IDS.scout}`)).json();
|
||||
ok(dogiSicht.bearbeitbar === true, "DogFather schon");
|
||||
const eigeneSicht = await (await hol("scout",
|
||||
`${API}/eintraege?monat=${MONAT}&aufgabe=creator`)).json();
|
||||
ok(eigeneSicht.bearbeitbar === true, "und jeder an seiner eigenen");
|
||||
|
||||
/* GEGENPROBE: Die Angabe muss mit dem uebereinstimmen, was der Server
|
||||
dann WIRKLICH tut. Eine Anzeige, die „darfst du" sagt und danach
|
||||
403 liefert, ist schlimmer als gar keine. */
|
||||
/* EIN EINTRAG, DEN ES WIRKLICH NOCH GIBT. Beim ersten Lauf stand
|
||||
hier `einId` -- der war weiter oben geloescht worden, und die
|
||||
Antwort lautete 404 statt 403. Das haette wie ein bestandener
|
||||
Riegel ausgesehen und war nur „gibt es nicht". */
|
||||
const lebtNoch = eigeneSicht.eintraege[0]?.id;
|
||||
braucht(!!lebtNoch, "es gibt keinen Eintrag, an dem sich die Absage messen liesse");
|
||||
const spicyVersuch = await schick("spicy", `${API}/eintrag/${lebtNoch}`, "PATCH",
|
||||
{ datum: HEUTE, name: "@vonSpicy" });
|
||||
ok(spicyVersuch.status === 403,
|
||||
`…und der Server weist Spicy auch wirklich ab, mit 403 (${spicyVersuch.status})`);
|
||||
|
||||
/* =====================================================================
|
||||
SCHLUSS
|
||||
===================================================================== */
|
||||
|
||||
Reference in New Issue
Block a user