Die Live-Checkliste am Termin -- ein Knopf, keine Automatik
KAPITEL 5.7 UND 11: "Wird pro Live-Termin als Checkliste erzeugt und den
eingeteilten Modis zugewiesen."
DAS DOKUMENT SAGT "AUTOMATISCH", FILIPE HAT SICH FUER EINEN KNOPF
ENTSCHIEDEN (10.09.2026). Vierzehn Aufgaben, die bei jedem Termin von
selbst erscheinen, ueberrumpeln -- und was ungefragt Dinge anlegt, ist
schwer wieder loszuwerden. Wer einen Termin nur zum Merken eintraegt,
haette danach aufzuraeumen.
Ein Druck erzeugt die vierzehn Punkte aus Kapitel 11 (fuenf vorher,
fuenf waehrend, vier danach), mit dem TERMINTAG als Frist -- eine
Vorbereitung, die nach dem Live faellig wird, ist keine -- verteilt auf
die eingeteilten Modis, jede mit ihrer Kategorie.
DREI STELLEN, AN DENEN SO ETWAS ERFAHRUNGSGEMAESS KIPPT. Alle drei
vorher benannt, dann gemessen:
* ZWEIMAL DRUECKEN. Der zweite Druck legt nichts an. Und der Knopf
zeigt die Zahl ("Checkliste (14)") -- sonst drueckt man ihn zur
Sicherheit noch einmal und weiss hinterher nicht, ob doppelt
angelegt wurde.
* DAS ZWEITE LIVE. Hier waere der Fehler teuer: Die Kennung, an der
"schon uebernommen" erkannt wird, traegt jetzt die TERMINNUMMER
(`mk-vor-technik#42`). Ohne sie stuende beim zweiten Live alles als
erledigt da, und niemand bekaeme seine Liste. Geprueft mit zwei
echten Terminen.
* EIN TERMIN OHNE EINGETEILTE MODIS. Vierzehn herrenlose Aufgaben
waeren schlimmer als keine -- stattdessen kommt eine Rueckfrage.
KEIN ROLLENNAME IM BROWSER, wie ueberall: Der Server schickt ein Ja/Nein
("gehoert der Knopf hierhin") und eine Zahl ("wie viele stehen schon").
Aus einer Zahl laesst sich nichts schliessen. Ein Manager bekommt den
Knopf gar nicht erst -- und wenn er es ueber die Schnittstelle versucht,
wortgleich dieselbe Absage wie fuer eine erfundene Art.
DIE ZAEHLUNG LAEUFT IN EINER ABFRAGE fuer alle Termine im Blick, nicht
je Zeile eine. Bei dreissig Terminen waeren das dreissig Abfragen -- den
Fehler hat das Haus bei den Teilnehmern schon einmal gemacht und drei
Zeilen darueber ausdruecklich vermerkt.
DIE TERMINE IN DER PRUEFUNG LIEGEN RELATIV in der Zukunft (+3 und +10
Tage). Ein festes Datum holt der Kalender irgendwann ein, und dann ist
die Pruefung rot, ohne dass etwas kaputt ist -- genau so ist es am
06.09.2026 bei der Oeffnungsschranke des Shops passiert.
GEPRUEFT: pruef-modi-livecheck (16, neu), pruef-kalender, pruef-serien
(69), pruef-vorlagen, pruef-modi-katalog (29).
Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
@@ -462,6 +462,10 @@
|
||||
return `mit ${namen[0]}, ${namen[1]} +${namen.length - 2}`;
|
||||
}
|
||||
|
||||
/* Darf diese Person zu einem Termin eine Checkliste anlegen? Kommt
|
||||
vom Server (siehe laden()). */
|
||||
let checklisteMoeglich = false;
|
||||
|
||||
function vereinheitlichen(roh) {
|
||||
const raus = [];
|
||||
for (const t of roh.termine || []) {
|
||||
@@ -482,6 +486,10 @@
|
||||
creator_name: t.creator_name, teilnehmer_name: t.teilnehmer_name,
|
||||
erstellt_von: t.erstellt_von, dauer_min: t.dauer_min,
|
||||
serie_id: t.serie_id || null,
|
||||
/* Wie viele Punkte der Live-Checkliste zu diesem Termin schon
|
||||
angelegt sind. Kommt vom Server; fehlt die Angabe, gibt es
|
||||
den Knopf gar nicht. */
|
||||
checkliste: t.checkliste_aufgaben ?? null,
|
||||
});
|
||||
}
|
||||
for (const f of roh.fristen || []) {
|
||||
@@ -1025,6 +1033,40 @@
|
||||
if (!a.ok) { melde('Ändern ging nicht.'); return; }
|
||||
await laden();
|
||||
}));
|
||||
/* =================================================================
|
||||
DIE LIVE-CHECKLISTE (10.09.2026, Kapitel 5.7/11)
|
||||
|
||||
Das Dokument will sie "automatisch pro Live-Termin". Filipes
|
||||
Entscheidung war ein Knopf: Vierzehn Aufgaben, die bei jedem
|
||||
Termin von selbst erscheinen, ueberrumpeln -- und was ungefragt
|
||||
Dinge anlegt, ist schwer wieder loszuwerden.
|
||||
|
||||
DER KNOPF SAGT, WAS SCHON DA IST. "Checkliste (14)" statt
|
||||
"Checkliste" -- sonst drueckt man ihn zur Sicherheit noch
|
||||
einmal und weiss hinterher nicht, ob doppelt angelegt wurde.
|
||||
(Der Server legt nichts doppelt an; der Knopf soll trotzdem
|
||||
nicht dazu einladen, es zu versuchen.) */
|
||||
if (checklisteMoeglich && e.id && e.art !== 'frist') {
|
||||
const wieViele = e.checkliste || 0;
|
||||
rechts.append(tuKnopf(wieViele ? `Checkliste (${wieViele})` : 'Checkliste anlegen',
|
||||
async () => {
|
||||
const a = await hole('/workspace/api/vorlagen/uebernehmen', {
|
||||
method: 'POST',
|
||||
headers: { 'Content-Type': 'application/json' },
|
||||
body: JSON.stringify({ art: 'katalog_termin', termin_id: e.id }),
|
||||
});
|
||||
if (!a.ok) {
|
||||
const f = await a.json().catch(() => ({}));
|
||||
melde(f.fehler || 'Das hat nicht geklappt.');
|
||||
return;
|
||||
}
|
||||
const d = await a.json().catch(() => ({}));
|
||||
melde(d.angelegt
|
||||
? `${d.angelegt} Punkte auf dem Aufgabenbrett.`
|
||||
: 'Die Checkliste steht schon.');
|
||||
await laden();
|
||||
}));
|
||||
}
|
||||
if (darfAendern(e)) {
|
||||
/* BEARBEITEN STAND NIE DA (07.09.2026). Filipe: "ich hab die
|
||||
gemacht und kann sie nicht bearbeiten." Der Server liess das
|
||||
@@ -1234,6 +1276,11 @@
|
||||
const a = await hole(`/workspace/api/termine?von=${von}&tage=${tage}`);
|
||||
if (!a.ok) { melde('Kalender konnte nicht geladen werden.'); return; }
|
||||
const roh = await a.json();
|
||||
/* OB der Knopf hingehoert, sagt der Server -- nicht ein
|
||||
Rollenvergleich hier. Diese Datei bekommt jeder ausgeliefert,
|
||||
der die Seite oeffnet; ein Rollenname darin waere mit einem
|
||||
Blick in den Quelltext gefunden. */
|
||||
checklisteMoeglich = !!roh.checkliste_moeglich;
|
||||
daten = { eintraege: vereinheitlichen(roh), heute: heuteText() };
|
||||
/* Die Wiederholungen NACH den Terminen holen: Der Serveraufruf
|
||||
oben legt fehlende Ausprägungen an, und erst danach stimmt der
|
||||
|
||||
Reference in New Issue
Block a user