Reload-Countdown laedt die Buero-Visualisierung bei 0 tatsaechlich neu

Bisher zaehlte der Countdown im Header nur rein kosmetisch herunter, ohne
selbst etwas neu zu laden. Ein dauerhaft offener Tab (z.B. auf einer
Monitor-Wand) blieb dadurch auf unbestimmte Zeit bei der beim Laden
geholten JS-Version haengen, auch wenn ein Fix laengst gemergt und per
Auto-Update deployt war - so blieben z.B. die in PR #106 entfernten
KPI-Graphen auf bereits offenen Tabs weiter sichtbar (Issue #108).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
fds2610-bot 2026-10-01 13:39:56 +02:00
parent b60a36832a
commit 72bad859f1
5 changed files with 30 additions and 13 deletions

View file

@ -30,9 +30,11 @@ CODEBERG_TOKEN=
# Mit eingerichtetem Webhook (siehe unten) ist das nur noch das Sicherheitsnetz fuer # Mit eingerichtetem Webhook (siehe unten) ist das nur noch das Sicherheitsnetz fuer
# verpasste Zustellungen und darf gross bleiben - Issue-Aenderungen landen dann in Sekunden # verpasste Zustellungen und darf gross bleiben - Issue-Aenderungen landen dann in Sekunden
# auf dem Board, nicht erst beim naechsten Lauf. # auf dem Board, nicht erst beim naechsten Lauf.
# Speist ausserdem den rein kosmetischen Reload-Countdown im Header der Buero-Visualisierung # Speist ausserdem den Reload-Countdown im Header der Buero-Visualisierung (Service "web",
# (Service "web", siehe docker/nginx/default.conf.template) - der Countdown zaehlt nur mit, # siehe docker/nginx/default.conf.template) - erreicht der Countdown 0, laedt der Browser die
# er loest selbst keinen echten Reload/Sync aus. # Seite tatsaechlich neu (Issue #108), damit ein dauerhaft offener Wand-Tab laengstens nach
# einem Intervall den aktuell deployten Frontend-Stand bekommt. Auf den periodischen
# Codeberg-Sync hat das keinen Einfluss, dafuer ist weiterhin allein das Backend zustaendig.
MONITOR_SYNC_INTERVAL=600 MONITOR_SYNC_INTERVAL=600
# Secret des Codeberg-Webhooks (Repo -> Einstellungen -> Webhooks -> Forgejo, Ziel-URL # Secret des Codeberg-Webhooks (Repo -> Einstellungen -> Webhooks -> Forgejo, Ziel-URL

View file

@ -20,7 +20,11 @@ die dazugehörigen Klärungen in [Detailfragen.md](Detailfragen.md) und
Agenten laufen animiert zwischen Schreibtisch/Board/Monitor-Wand/Kaffee-Ecke (Phase 3-5, Agenten laufen animiert zwischen Schreibtisch/Board/Monitor-Wand/Kaffee-Ecke (Phase 3-5,
siehe Visualization.md Abschnitt 9). Ist die API nicht erreichbar, zeigt die Szene siehe Visualization.md Abschnitt 9). Ist die API nicht erreichbar, zeigt die Szene
ersatzweise Demo-Daten — kenntlich gemacht durch einen roten Banner „API nicht erreichbar!". ersatzweise Demo-Daten — kenntlich gemacht durch einen roten Banner „API nicht erreichbar!".
Die Basis-URL der API kommt aus `MONITOR_API_BASE` (siehe `.env.example`). Die Basis-URL der API kommt aus `MONITOR_API_BASE` (siehe `.env.example`). Ein dauerhaft
offener Tab (z.B. auf einer Monitor-Wand) lädt sich spätestens alle `MONITOR_SYNC_INTERVAL`
Sekunden selbst neu (Reload-Countdown im Header, Issue #108), damit er immer den aktuell
deployten Frontend-Stand zeigt statt auf unbestimmte Zeit eine alte Version weiterlaufen zu
lassen.
- Klick auf den PO öffnet ein Modal, in dem sich die vom Codeberg-Sync gelesenen Projekte - Klick auf den PO öffnet ein Modal, in dem sich die vom Codeberg-Sync gelesenen Projekte
(Owner/Repo + Farbe) hinzufügen, bearbeiten und löschen lassen (Issue #27) — Änderungen (Owner/Repo + Farbe) hinzufügen, bearbeiten und löschen lassen (Issue #27) — Änderungen
wirken sofort im laufenden `sync`-Dienst, ohne Neustart. Schreibende Aktionen fragen einmalig wirken sofort im laufenden `sync`-Dienst, ohne Neustart. Schreibende Aktionen fragen einmalig

View file

@ -18,8 +18,9 @@ server {
# definiert, bleibt ihr Platzhalter stehen und nginx verweigert den Start # definiert, bleibt ihr Platzhalter stehen und nginx verweigert den Start
# ("unknown \"monitor_api_base\" variable") - besser ein lauter Fehler als eine still # ("unknown \"monitor_api_base\" variable") - besser ein lauter Fehler als eine still
# falsche URL. docker-compose.yml setzt beide Variablen daher immer (ggf. mit Default). # falsche URL. docker-compose.yml setzt beide Variablen daher immer (ggf. mit Default).
# MONITOR_SYNC_INTERVAL speist nur den rein kosmetischen Reload-Countdown im Header # MONITOR_SYNC_INTERVAL speist den Reload-Countdown im Header (Issue #12) - der laedt die
# (Issue #12) - hat keinen Einfluss auf den tatsaechlichen Update-Takt der Szene. # Seite bei 0 tatsaechlich per location.reload() neu (Issue #108), hat aber keinen Einfluss
# auf den laufenden Update-Takt der Szene selbst (SSE/Polling, siehe office-render.js).
location = /config.js { location = /config.js {
default_type application/javascript; default_type application/javascript;
add_header Cache-Control "no-store"; add_header Cache-Control "no-store";

View file

@ -2537,9 +2537,12 @@ function setAgentProblemBanner(agents) {
banner.classList.toggle("api-banner-warning", !expired && Boolean(expiring)); banner.classList.toggle("api-banner-warning", !expired && Boolean(expiring));
} }
// Rein kosmetischer Countdown im Header (Issue #12): zaehlt unabhaengig vom tatsaechlichen // Countdown im Header (Issue #12, seit Issue #108 mit echtem Reload): zaehlt unabhaengig vom
// SSE-/Polling-Takt von MONITOR_SYNC_INTERVAL (aus config.js, siehe office.html) auf 0 // tatsaechlichen SSE-/Polling-Takt von MONITOR_SYNC_INTERVAL (aus config.js, siehe office.html)
// herunter und startet danach von vorn - loest selbst keinen Reload aus. // auf 0 herunter und laedt die Seite dann per location.reload() neu, statt nur wieder von vorn
// zu zaehlen - ein dauerhaft offener Wand-Tab holt sich damit laengstens nach einem Intervall
// den aktuell deployten Frontend-Stand (sonst zeigt er auf unbestimmte Zeit die alte
// JS-Version weiter an, selbst wenn ein Fix laengst gemergt/deployt ist).
function startReloadCountdown() { function startReloadCountdown() {
const countdownEl = document.getElementById("reload-countdown"); const countdownEl = document.getElementById("reload-countdown");
if (!countdownEl) { if (!countdownEl) {
@ -2551,7 +2554,12 @@ function startReloadCountdown() {
countdownEl.textContent = `${remaining}s`; countdownEl.textContent = `${remaining}s`;
window.setInterval(() => { window.setInterval(() => {
remaining = nextCountdownSeconds(remaining, intervalSeconds); const next = nextCountdownSeconds(remaining, intervalSeconds);
if (next === intervalSeconds) {
window.location.reload();
return;
}
remaining = next;
countdownEl.textContent = `${remaining}s`; countdownEl.textContent = `${remaining}s`;
}, 1000); }, 1000);
} }

View file

@ -1045,9 +1045,11 @@ export function advancePoVisitStage(stage) {
} }
// --------------------------------------------------------------------------------------- // ---------------------------------------------------------------------------------------
// Reload-Countdown im Header (Issue #12): rein kosmetischer Sekundenzaehler, der die // Reload-Countdown im Header (Issue #12, seit Issue #108 mit echtem Reload): Sekundenzaehler,
// Sync-Frequenz des Backends (MONITOR_SYNC_INTERVAL, siehe .env.example) im Header // der die Sync-Frequenz des Backends (MONITOR_SYNC_INTERVAL, siehe .env.example) im Header
// widerspiegelt - ohne selbst irgendetwas neu zu laden (siehe office-render.js). // widerspiegelt - erreicht er 0, laedt office-render.js die Seite tatsaechlich neu, damit ein
// dauerhaft offener Wand-Tab laengstens nach einem Intervall den aktuell deployten
// Frontend-Stand bekommt.
// --------------------------------------------------------------------------------------- // ---------------------------------------------------------------------------------------
export const DEFAULT_RELOAD_INTERVAL_SECONDS = 600; export const DEFAULT_RELOAD_INTERVAL_SECONDS = 600;