fs
6e3fc63c1d
Replace the single tenant avatar with a pair of theme-scoped brand logos.
Render only the theme-matching <img> server-side and swap src on theme
toggle via a JS hook — no reload, no double request, no CSS tricks.
Tenant logos
- TenantLogoService (ImageUploadTrait) with theme whitelist and per-theme
storage storage/tenants/{uuid}/logo/{light|dark}/, SIZES 128/256/512
- Public serving endpoint auth/tenant-logo-file so login can show the
logo pre-auth; matching authenticated admin preview endpoint
- appTenantLogoUrl(?size, ?theme) with 4-step fallback cascade; PDF +
mail always request 'light'
- Admin tenant edit: avatar block replaced by "Tenant logos" details
block inside the Master-data tab, two side-by-side slots via Pico
.grid with the core app-file-upload partial
- Policy rename ABILITY_ADMIN_TENANTS_AVATAR_VIEW -> LOGO_VIEW, action
routes logo / logo-delete / logo-file with theme body/query param
- API endpoint path kept (backward compat), internals on new service
- CLI tenant:logo-migrate-avatars moves legacy avatar/ -> logo/light/
idempotently (--dry-run, --yes, --cleanup)
- i18n "Tenant image" removed, 12 new keys synced across de/en
File upload component
- Full-width preview + filename/actions below (3D stack layout)
- Fixed 16:9 aspect ratio with 1rem inner padding for consistent
preview size across any logo aspect
- Transparency checker pattern as background so black logos stay
visible on dark mode and white logos on light mode
- form="" + deleteFormId support so the partial works with barrier
forms inside another form
Buttons
- width:100% dropped from button[type="submit"]; scoped back via
.login-main for the auth-flow primary CTA
- .outline base rule now tints background via color-mix of --app-color
so secondary/primary/danger outlines all gain a subtle surface
- .outline.secondary restyled Stripe-style in both themes: solid white
chip with soft shadow in light, solid elevated dark chip with white
text in dark; neutral border replaces role-colored border
- .app-action-success/.app-action-danger outlines get color-mix bg +
theme-aware outline-text tokens for stronger contrast
- Filled .primary/.app-action-success/.app-action-danger get raised
box-shadow (inset highlight + drop) — opt-in via class so chrome
buttons stay flat
- Dropped the legacy .secondary utility that was clobbering the
custom-property cascade with a hardcoded muted color
Theme swap
- Logo img carries data-src-light + data-src-dark; theme-toggle JS
swaps src when data-theme changes, keeping the topbar/login logo in
sync without a page reload
Quality gates: PHPUnit (2045), PHPStan L5, CS-Fixer, docs link/drift,
codex skills sync — all green.
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