Files

fs 149d4515de 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

2.4 KiB

Raw Blame 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:

DB als Wahrheit
- Alle Settings werden persistiert in settings.
- Validierung und Schreiblogik laufen über domänenspezifische Gateways und AdminSettingsService.
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
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

Admin speichert Settings in admin/settings.
AdminSettingsService koordiniert domänenspezifische Gateways (z. B. SettingsAppGateway, SettingsSmtpGateway, SettingsMetadataGateway), die auf SettingRepository delegieren und in die DB schreiben.
SettingCacheService aktualisiert den Datei-Cache nur für den definierten Teilbereich.
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 massgeblich.

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).

2.4 KiB Raw Blame History