Files
breadcrumb-the-shire/docs/explanation-einstellungen-speicherung.md

62 lines
2.4 KiB
Markdown
Raw Normal View History

# Einstellungen: Speicherung (DB + Cache)
Letzte Aktualisierung: 2026-03-25
## Kurzfassung
- **Source of truth ist immer die Tabelle `settings` in der Datenbank.**
- `storage/runtime/settings.php` ist nur ein **Teil-Cache** für wenige, sehr häufig gelesene UI-Basiswerte.
- Nicht alle Settings müssen oder sollen im Datei-Cache stehen.
## Warum es beides gibt
Die Kombination ist bewusst so gebaut:
1. **DB als Wahrheit**
- Alle Settings werden persistiert in `settings`.
- Validierung und Schreiblogik laufen über domänenspezifische Gateways und `AdminSettingsService`.
2. **Datei-Cache für Hot-Path-Reads**
- `storage/runtime/settings.php` wird durch `SettingCacheService` geschrieben.
- Verwendet wird er über `appSetting(...)` nur für globale Basiswerte wie:
- `app_title`
- `app_locale`
- `app_registration`
refactor(settings): remove global appearance settings — tenant is sole source Removes the global app_theme, app_theme_user and app_primary_color settings from the admin/settings area and the underlying service/cache/API/i18n/docs layers. The tenant columns (tenants.primary_color, default_theme, allow_user_theme) become the single source of truth for appearance. Branding helpers are tenant-only and fall back to a hardcoded 'light' theme with no brand color when no tenant context is available (login, error, pre-session pages). The APP_THEME env var is removed. Scope: - UI: Appearance tab gone from /admin/settings; tenant edit form drops the global-fallback color preview. - Service: SettingsAppGateway no longer exposes setting-backed accessors for theme/user-theme/primary-color. Theme catalog utilities (listThemes, isAllowedTheme, normalizeTheme, resolveDefaultTheme) stay and are used across Tenant / Auth / User flows; resolveDefaultTheme now hardcodes 'light' with a catalog fallback (no global/env lookup). - AdminSettingsService: buildPageData, sanitization, audit snapshot, apply step and cache payload are all stripped of the three keys. Dead helper applyAppPrimaryColor + normalizePrimaryColor removed. - Cache: SettingCacheService HOT_PATH_KEYS drops the three keys. - API: /settings (GET/PUT) and /settings/public (GET) no longer expose appearance fields; OpenAPI schemas pruned accordingly. - Audit redaction list shortened. - DB: db/init/init.sql seed rows removed. No migration for existing installs — legacy rows stay inert. - i18n + docs: setting.app_theme, setting.app_theme_user, setting.app_primary_color removed from de+en locales; reference and explanation docs updated. - Tests: covering tests for the removed methods pruned; ThemeResolutionTest rewritten for tenant-only semantics. One unrelated PHP-CS-Fixer issue in UserRegistrar.php cleaned up to keep QG-006 green. Workflow: .agents/runs/SETTINGS-APPEARANCE-TENANT-ONLY/ (gitignored). Gates: QG-001..003, QG-006, QG-008 all pass (1985 tests, 28764 assertions). Reviews: code, security, acceptance all pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 22:40:15 +02:00
Appearance-Settings (Theme, Primärfarbe, Erlaubnis für User-Themes) sind
**tenant-scoped** und werden nicht global gecached — sie liegen auf dem
Tenant (`tenants.primary_color`, `default_theme`, `allow_user_theme`).
## Was **nicht** im Cache der Datei liegen muss
Sicherheits- oder Integrationswerte werden direkt aus DB gelesen, z. B.:
- SMTP (`smtp_host`, `smtp_port`, `smtp_user`, `smtp_from`, ...)
- Microsoft SSO Shared App Settings
- API-spezifische Policies
- User-Lifecycle-Policies (`user_inactivity_deactivate_days`, `user_inactivity_delete_days`)
- Scheduler-/Job-Konfiguration (`scheduled_jobs`, `scheduled_job_runs`)
Daher ist es korrekt, wenn diese Werte in `settings` (DB) vorhanden sind, aber nicht in `storage/runtime/settings.php`.
## Laufzeitfluss
1. Admin speichert Settings in `admin/settings`.
2. `AdminSettingsService` koordiniert domänenspezifische Gateways (z. B. `SettingsAppGateway`, `SettingsSmtpGateway`, `SettingsMetadataGateway`), die auf `SettingRepository` delegieren und in die DB schreiben.
2026-02-23 12:58:19 +01:00
3. `SettingCacheService` aktualisiert den Datei-Cache nur für den definierten Teilbereich.
4. UI-Helfer `appSetting(...)` liest danach aus Datei-Cache.
## Wenn DB und Datei scheinbar nicht zusammenpassen
Das ist oft erwartbar, solange es um nicht-gecachte Keys geht.
Prüfregel:
- Geht es um `appSetting(...)`-Keys? Dann Datei-Cache relevant.
- Geht es um SMTP/SSO/API-Details? Dann DB ist maßgeblich.
## Betriebs-Hinweis
Direkte DB-Änderungen an gecachten `appSetting(...)`-Keys werden erst wirksam, wenn der Datei-Cache aktualisiert wurde
(z. B. durch erneutes Speichern in den Settings).