fs
12356e2266
Add a reusable CSV-export building block to the core so any Grid.js list
page can gain a filter/sort-aware download with two clicks of glue.
Core primitive:
- core/Service/Export/CsvExportService: flavor-aware writer (plain CSV
or Excel-compatible UTF-8+BOM+semicolon), with OWASP-aligned formula-
injection escape (=, @, +, -, TAB, CR) applied to both rows *and*
headers. Value objects for columns (ExportColumn) carry an extractor
closure and an allowSignedNumeric flag for phone-number-shaped cells.
- core/Support/helpers/export.php: thin HTTP layer (exportSendCsv,
exportCapLimit, exportResolveFlavor, exportRequireGetRequest) reusing
the requestInput() contract for GR-CORE-003 consistency. Filename is
sanitized and length-clamped; callers must still enforce auth.
- templates/partials/app-list-export-dropdown.phtml: zero-config
<details class="dropdown"> with CSV + Excel triggers.
- web/js/core/app-list-export.js: initListExport({ gridConfig, exportUrl })
mirrors the current grid filters + sort onto the export URL and
navigates, preserving session cookies for download.
First consumer — Helpdesk domains:
- DomainListService extracts the shared filter/enrich/sort logic from
domains-data so the grid endpoint and the new domains/export endpoint
cannot drift.
- domains/export endpoint delegates to DomainListService, declares
ExportColumns (with translated level labels), and exits via
exportSendCsv.
- domains-data now ~20 lines, delegating to DomainListService.
Tests:
- CsvExportServiceTest (10 cases): both flavors, BOM/no-BOM, formula
escapes incl. TAB/CR, header escape, signed-numeric allowlist,
quoting, multiline, empty columns, generator-compatible iterable.
- ExportHelpersTest (5 cases): exportCapLimit bounds.
- DomainListServiceTest (8 cases): filter, search, "all" sentinel,
sort, paging, enrichment, BC failure, tenant-scoped security filter.
Gates: PHPUnit green, PHPStan clean on touched files, module:sync ok.
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