Lars/mitai-jinkendo
1
0
Fork 0
Code Issues 33 Pull Requests Actions Packages Projects Releases 5 Wiki Activity

Dashboard: Nutzer-konfigurierbare Übersicht (Widget-System, Persistenz, Standard-Reset) #65

New Issue
Open
opened 2026-04-07 11:20:54 +02:00 by Lars · 1 comment
Lars commented 2026-04-07 11:20:54 +02:00
Owner
Copy Link

Ziel

Nutzer können die Übersichtsseite (Dashboard) selbstständig konfigurieren: welche Bausteine (Widgets) sichtbar sind, in welcher Reihenfolge, optional Unterkonfiguration (z. B. welche KPIs in einem Kennzahlen-Widget, Obergrenzen wie max. 9). Minimal-Konfiguration ist erlaubt (z. B. nur Willkommen).

Es gibt ein allgemeingültiges Standard-Dashboard; der Nutzer kann per Zurücksetzen jederzeit darauf zurückspringen.

Nicht in Scope (aktuell):

  • Mehrere benannte Dashboard-Presets, zwischen denen der Nutzer wechselt (nur ein Layout pro Profil).

Umsetzungsreihenfolge (vorgeschlagen)

  1. Widget-System (Frontend): stabile widget_id, zentrale Registry (id → Komponente + Metadaten), optional gemeinsamer Renderer; Pilot /pilot/viz auf diese Struktur umbiegen oder produktives Dashboard schrittweise.
  2. Persistenz (Backend): Profilgebundenes Layout, z. B. profiles.dashboard_layout JSONB oder eigene Tabelle; GET/PUT API mit Validierung gegen Registry (unbekannte IDs ablehnen, Limits z. B. KPI-Anzahl).
  3. Konfigurations-UI: primär Nutzer-Einstellungen (nicht zwingend Admin-Rolle); Sortierung, Ein/Aus, Bereiche; Details pro Widget; Speichern + Zurücksetzen auf Standard.

Technische Anforderungen (Kern)

  • Layout-JSON mit Version (version) für spätere Migrationen.
  • Serverseitige Validierung + sinnvolle Defaults bei null/leer.
  • Responsives Verhalten (Mobile/Desktop) beibehalten.

Verknüpfung

  • Pilot unter /pilot/viz als Prototyp; Layer-1-Referenzwerte bereits angebunden; Konzept Widget-Schicht im Kontext Phase 0c / Visualisierung (Issue #53).

Akzeptanz (grob)

  • Nutzer kann Dashboard anpassen und speichern; nach Reload bleibt Konfiguration erhalten.
  • Zurücksetzen auf Standard-Dashboard funktioniert.
  • Ungültige Konfiguration wird abgelehnt oder sanft normalisiert.
  • Kein Multi-Dashboard-Wechsel nötig für diese Story.
## Ziel Nutzer können die **Übersichtsseite (Dashboard)** selbstständig konfigurieren: welche **Bausteine (Widgets)** sichtbar sind, in welcher **Reihenfolge**, optional **Unterkonfiguration** (z. B. welche KPIs in einem Kennzahlen-Widget, Obergrenzen wie max. 9). **Minimal-Konfiguration ist erlaubt** (z. B. nur Willkommen). Es gibt ein **allgemeingültiges Standard-Dashboard**; der Nutzer kann per **Zurücksetzen** jederzeit darauf zurückspringen. **Nicht in Scope (aktuell):** - Mehrere benannte Dashboard-Presets, zwischen denen der Nutzer wechselt (nur **ein** Layout pro Profil). ## Umsetzungsreihenfolge (vorgeschlagen) 1. **Widget-System (Frontend):** stabile `widget_id`, zentrale Registry (id → Komponente + Metadaten), optional gemeinsamer Renderer; Pilot `/pilot/viz` auf diese Struktur umbiegen oder produktives Dashboard schrittweise. 2. **Persistenz (Backend):** Profilgebundenes Layout, z. B. `profiles.dashboard_layout` JSONB oder eigene Tabelle; `GET`/`PUT` API mit **Validierung** gegen Registry (unbekannte IDs ablehnen, Limits z. B. KPI-Anzahl). 3. **Konfigurations-UI:** primär **Nutzer-Einstellungen** (nicht zwingend Admin-Rolle); Sortierung, Ein/Aus, Bereiche; Details pro Widget; Speichern + **Zurücksetzen auf Standard**. ## Technische Anforderungen (Kern) - Layout-JSON mit **Version** (`version`) für spätere Migrationen. - Serverseitige Validierung + sinnvolle Defaults bei `null`/leer. - Responsives Verhalten (Mobile/Desktop) beibehalten. ## Verknüpfung - Pilot unter `/pilot/viz` als Prototyp; Layer-1-Referenzwerte bereits angebunden; Konzept Widget-Schicht im Kontext Phase 0c / Visualisierung (Issue #53). ## Akzeptanz (grob) - [ ] Nutzer kann Dashboard anpassen und speichern; nach Reload bleibt Konfiguration erhalten. - [ ] Zurücksetzen auf Standard-Dashboard funktioniert. - [ ] Ungültige Konfiguration wird abgelehnt oder sanft normalisiert. - [ ] Kein Multi-Dashboard-Wechsel nötig für diese Story.
Lars commented 2026-04-07 13:21:27 +02:00
Author
Owner
Copy Link

Stand 2026-04-06 (Branch develop)

Bereits umgesetzt

  • Widget-System (Frontend): zentrale Registry, WidgetRenderer, Registrierung in registerPilotLabWidgets.js.
  • Katalog + API: GET /api/app/widgets/catalog (widget_catalog.py).
  • Persistenz (Backend): profilgebundenes Layout mit Version im JSON, Validierung unbekannter Widget-IDs / config-Felder (dashboard_widget_config.py, dashboard_layout_schema).
  • Dashboard-Lab /app/dashboard-lab: Layout-Editor (Widget ein/aus, Reihenfolge), Speichern + Zurücksetzen, Live-Vorschau.
  • Pilot /pilot/viz: festes Standard-Layout (defaultLabLayout), gleicher Renderer wie Lab.
  • Pilot-Widgets: u.a. welcome, quick_capture, kpi_board, body_overview, activity_overview mit basisweiser config (z. B. chart_days 7–90 für Körper/Aktivität).
  • KPI-Board: Konfiguration über config.tiles (bis 9 Kacheln: body_fat, avg_kcal, ref:<type_key>). Legacy chart_days wird serverseitig verworfen (Auto-Kachelwahl). Ø-Kalorien-Fenster im Auto-Modus fest 7 Tage.

Bekannt / nachziehen (geringe Priorität)

  • Manuelle Reihenfolge der KPI-Kacheln im Lab-Editor: noch nicht vollständig implementiert.

Noch offen bis „produktionsreif“

  • Haupt-Dashboard (Dashboard.jsx) ist noch nicht auf Widget-Renderer + persistiertes Layout umgestellt (aktuell getrennt von Lab).
  • Keine produktionsreine Nutzer-Konfigurationsseite (ohne Lab-Chrome); Lab bleibt Entwicklungs-/Power-User-Oberfläche.
  • Weitere Widgets und komplette Migration der Visuals vom klassischen Dashboard und von Verlaufsseiten auf das Widget-Modell.

Nächste Schritte (Vorschlag)

Phase A (Kern)

  1. Weitere Widgets bauen; bestehende Charts/Visuals konsolidieren (Single Source / data_layer wie Phase 0c).
  2. Produkt-Dashboard: WidgetRenderer + Layout aus API als Standard-Einstieg; Navigation anpassen.
  3. User-Settings: eigene Seite „Dashboard anpassen“ (Funktionalität wie Lab-Editor, reduzierte UX).

Phase B

  1. Admin-UI: globale Standard-Konfigurationen für Dashboard (Defaults, ggf. neue Widget-Kombinationen vordefinieren).
  2. Verlauf (zweite Ausbaustufe): konfigurierbare Verlaufs-„Seiten“ (Submenü), Seiten anlegen/verwalten; Admin-Defaults für Verlauf analog zu Dashboard; möglichst gemeinsames Layout-/Widget-Format mit dem Dashboard.

Hinweis: app_dashboard-Modulversion Backend wurde mit KPI-tiles angehoben; Frontend Build + Backend-Tests für Widget-Config sind grün.

## Stand 2026-04-06 (Branch develop) ### Bereits umgesetzt - **Widget-System (Frontend):** zentrale Registry, `WidgetRenderer`, Registrierung in `registerPilotLabWidgets.js`. - **Katalog + API:** `GET /api/app/widgets/catalog` (`widget_catalog.py`). - **Persistenz (Backend):** profilgebundenes Layout mit **Version** im JSON, Validierung unbekannter Widget-IDs / `config`-Felder (`dashboard_widget_config.py`, `dashboard_layout_schema`). - **Dashboard-Lab** `/app/dashboard-lab`: Layout-Editor (Widget ein/aus, Reihenfolge), Speichern + Zurücksetzen, Live-Vorschau. - **Pilot** `/pilot/viz`: festes Standard-Layout (`defaultLabLayout`), gleicher Renderer wie Lab. - **Pilot-Widgets:** u.a. `welcome`, `quick_capture`, `kpi_board`, `body_overview`, `activity_overview` mit basisweiser **config** (z. B. `chart_days` 7–90 für Körper/Aktivität). - **KPI-Board:** Konfiguration über **`config.tiles`** (bis 9 Kacheln: `body_fat`, `avg_kcal`, `ref:<type_key>`). Legacy **`chart_days` wird serverseitig verworfen** (Auto-Kachelwahl). Ø-Kalorien-Fenster im Auto-Modus fest **7 Tage**. ### Bekannt / nachziehen (geringe Priorität) - Manuelle **Reihenfolge der KPI-Kacheln** im Lab-Editor: noch nicht vollständig implementiert. ### Noch offen bis „produktionsreif“ - **Haupt-Dashboard** (`Dashboard.jsx`) ist noch **nicht** auf Widget-Renderer + persistiertes Layout umgestellt (aktuell getrennt von Lab). - **Keine produktionsreine Nutzer-Konfigurationsseite** (ohne Lab-Chrome); Lab bleibt Entwicklungs-/Power-User-Oberfläche. - **Weitere Widgets** und **komplette Migration der Visuals** vom klassischen Dashboard und von **Verlaufsseiten** auf das Widget-Modell. --- ## Nächste Schritte (Vorschlag) ### Phase A (Kern) 1. Weitere Widgets bauen; bestehende Charts/Visuals konsolidieren (Single Source / data_layer wie Phase 0c). 2. **Produkt-Dashboard:** `WidgetRenderer` + Layout aus API als Standard-Einstieg; Navigation anpassen. 3. **User-Settings:** eigene Seite „Dashboard anpassen“ (Funktionalität wie Lab-Editor, reduzierte UX). ### Phase B 4. **Admin-UI:** globale **Standard-Konfigurationen** für Dashboard (Defaults, ggf. neue Widget-Kombinationen vordefinieren). 5. **Verlauf (zweite Ausbaustufe):** konfigurierbare Verlaufs-„Seiten“ (Submenü), Seiten anlegen/verwalten; Admin-Defaults für Verlauf analog zu Dashboard; möglichst **gemeinsames Layout-/Widget-Format** mit dem Dashboard. --- *Hinweis: `app_dashboard`-Modulversion Backend wurde mit KPI-`tiles` angehoben; Frontend Build + Backend-Tests für Widget-Config sind grün.*
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
bug

Bug/Fehler

  
develop

Betrifft develop Branch

  
feature

Feature Request

  
high

Hohe Priorit�t

  
low

Niedrige Priorit�t

No Label
bug
develop
feature
high
low
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Lars/mitai-jinkendo#65
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?