fs
149d4515de
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>
Tests
Ziel
Die Tests sind nach Schutzwirkung organisiert, nicht nur nach technischer Ebene. Wichtige Architektur- und Security-Invarianten sollen schnell gezielt laufen koennen, ohne dass jede Aenderung immer die komplette Suite im Kopf behalten muss.
PHPUnit-Suiten
CoreCore: gesamte Test-Suite.Unit: kleine verhaltensorientierte Unit-Tests ohne breites Orchestrierungs-Setup.Service: Business-Logik, Policies, Gateways und Orchestrierungs-Tests untertests/Service/.Repository: Query- und Repository-Tests untertests/Repository/.Domain: fachliche Taxonomie- und Domain-Tests untertests/Domain/.Architecture: alle Architektur-Contracts untertests/Architecture/.ArchitectureCore: Core-Boundaries, Module-/Repository-Contracts, Taxonomie- und Sync-Contracts.ArchitectureSecurity: CSRF, PRG, File-Storage, Crypto, Logging sowie AuthZ-nahe Contracts.ArchitectureUI: UI-Contracts fuer Listen, Detailseiten, Runtime-Komponenten und A11y.ArchitectureModules: modulbezogene Struktur- und Isolations-Contracts.ArchitectureMeta: Agent-/Skill-/Meta-Contracts fuer das Repository-Setup.
Regeln fuer neue Architecture-Tests
- Nur stabile Invarianten testen, keine einmaligen Migrationsdetails.
- Guards oder Risiken explizit abdecken, zum Beispiel
GR-CORE-*,GR-SEC-*,GR-TEST-*. - Keine Duplikate neben bereits breiten Contracts anlegen.
- String-Assertions nur verwenden, wenn kein robusterer Contract moeglich ist.
- Monolithische Sammeltests vermeiden; lieber kleine thematische Contracts.
Delete vs. Refactor vs. Keep
keep: testet einen echten plattformweiten Contract oder Security-Guard.refactor: Schutz ist wichtig, aber der Test ist zu datei-, markup- oder implementation-detailnah.delete: dupliziert bestehende Schutzwirkung oder prueft nur historische Altlasten.
Regeln fuer neue Service-Tests
- Services auf Guards, Orchestrierung, Normalisierung, Fehlerpfade und Seiteneffekte testen.
- Keine eigenen Tests fuer reine
find/list/get/set-Delegation ohne zusaetzliche Regel. - Thin Wrapper auf gemeinsame Primitive zentral testen, nicht pro Gateway erneut.
- Mockability-, Reflection- und Interface-Existenz-Tests ohne Risiko-Schutz vermeiden.
- Kleine Normalisierungs-Matrizen mit DataProvidern oder zusammengezogenen Contract-Dateien verdichten.
Typische Low-Value-Muster
- Gateway-Test prueft nur
encrypt/decrypterneut, obwohl das Basisverhalten schon zentral abgesichert ist. - Test bestaetigt nur, dass ein Service eins zu eins an Repository oder Gateway weiterreicht.
- Test prueft nur Methodensignatur, Reflection oder dass eine Klasse mockbar ist.
- Mehrere Minidateien decken denselben Settings-/Fallback-Mechanismus mit identischem Mock-Muster ab.
Naechste Audit-Kandidaten
- methodenweiser Low-value-Pass in
tests/Service/User/UserAccountServiceTest.php - methodenweiser Low-value-Pass in
tests/Service/Org/DepartmentServiceTest.php - methodenweiser Low-value-Pass in
tests/Service/Access/RoleServiceTest.php - verbleibende kleine Settings-Gateway-Tests auf weitere Verdichtung pruefen