Dashboard-Widgets: Feature-Gate-Zuordnung aus Admin/DB statt hardcodiertem Katalog #66

New Issue

Lars · 2026-04-08T07:27:00+02:00

Lars commented

2026-04-08 07:27:00 +02:00

Ausgangslage

allowed pro Widget wird in dashboard_widget_entitlements aus check_feature_access berechnet.
Die Zuordnung Widget-ID → features.id steht aktuell als optionales Feld requires_feature fest in backend/widget_catalog.py (Code-Deploy nötig bei Änderungen).
Tier-Limits und Feature-Schalter bleiben in features / tier_limits – das ist korrekt; nur die Mapping-Schicht soll konfigurierbar werden.

Ziel

Mapping über Feature-Administration (oder dedizierte Admin-UI) pflegen: welches Dashboard-Lab-Widget welches Feature voraussetzt (oder keines).
Backend: z. B. Tabelle dashboard_widget_feature_gates (widget_id, feature_id NULL = kein Gate) oder admin-editierbares JSON mit Validierung gegen ALLOWED_WIDGET_IDS und features.id.
Fallback: bestehende Katalog-Defaults aus widget_catalog.py beim Migrieren übernehmen, dann optional Code-Defaults entfernen oder nur als Notfall-Fallback.
Validierung: ungültige widget_id / unbekannte feature_id beim Speichern ablehnen.

Akzeptanz

Nach Änderung in der Admin-UI ändert sich GET /api/app/widgets/catalog (allowed) ohne neuen Deploy.
Doku: .claude/docs/technical/DASHBOARD_WIDGETS_AGENT_GUIDE.md und ggf. ARCHITECTURE.md §9 anpassen.

Referenz (Implementierung v1)

backend/dashboard_widget_entitlements.py
backend/widget_catalog.py (requires_feature)

## Ausgangslage - `allowed` pro Widget wird in `dashboard_widget_entitlements` aus `check_feature_access` berechnet. - Die Zuordnung **Widget-ID → `features.id`** steht aktuell als optionales Feld **`requires_feature`** fest in **`backend/widget_catalog.py`** (Code-Deploy nötig bei Änderungen). - Tier-Limits und Feature-Schalter bleiben in **`features` / `tier_limits`** – das ist korrekt; nur die **Mapping-Schicht** soll konfigurierbar werden. ## Ziel - Mapping **über Feature-Administration** (oder dedizierte Admin-UI) pflegen: welches Dashboard-Lab-Widget welches Feature voraussetzt (oder keines). - Backend: z. B. Tabelle `dashboard_widget_feature_gates` (`widget_id`, `feature_id` NULL = kein Gate) **oder** admin-editierbares JSON mit Validierung gegen `ALLOWED_WIDGET_IDS` und `features.id`. - **Fallback:** bestehende Katalog-Defaults aus `widget_catalog.py` beim Migrieren übernehmen, dann optional Code-Defaults entfernen oder nur als Notfall-Fallback. - **Validierung:** ungültige `widget_id` / unbekannte `feature_id` beim Speichern ablehnen. ## Akzeptanz - Nach Änderung in der Admin-UI ändert sich `GET /api/app/widgets/catalog` (`allowed`) **ohne** neuen Deploy. - Doku: `.claude/docs/technical/DASHBOARD_WIDGETS_AGENT_GUIDE.md` und ggf. `ARCHITECTURE.md` §9 anpassen. ## Referenz (Implementierung v1) - `backend/dashboard_widget_entitlements.py` - `backend/widget_catalog.py` (`requires_feature`)

Sign in to join this conversation.