Files
breadcrumb-the-shire/docs/howto-erste-aenderung.md

55 lines
2.3 KiB
Markdown
Raw Permalink Normal View History

# Leitfaden für die erste Änderung
Letzte Aktualisierung: 2026-03-25
## Ziel
Ein neuer Entwickler soll den ersten Change strukturiert und reproduzierbar umsetzen können.
## Beispiel 1: Spalte in Admin-Liste ergänzen
### Schrittfolge
1. Data-Endpoint erweitern (z. B. `pages/admin/users/data().php`)
2026-02-23 12:58:19 +01:00
2. Falls nötig: neue Repository-Methode ergänzen je nach Typ:
- Listenabfrage / Filterung / Paginierung → `core/Repository/User/UserListQueryRepository.php`
- Einzelnes Objekt lesen → `core/Repository/User/UserReadRepository.php`
- Schreiboperation → `core/Repository/User/UserWriteRepository.php`
3. Grid-Spalte in `pages/admin/<modul>/index(default).phtml` ergänzen (z. B. `pages/admin/users/index(default).phtml`)
4. i18n-Key für Spaltennamen setzen
2026-03-04 15:56:58 +01:00
5. Service-Auflösung in Action-Dateien nur über `app(Foo::class)` nutzen (kein `new ...Factory()` in `pages/**`)
6. In `data().php`: GET-only (`gridRequireGetRequest()`) und Filter/Paging über `gridParseFiltersFromSchemaFile(...)` normalisieren
2026-03-04 15:56:58 +01:00
7. `php -l` + manueller UI-Test
### Done-Kriterien
- Kein SQL in View-Dateien
- Neue Werte im Endpoint dokumentiert/benannt
- Sortierung und Mapping im Grid konsistent
- Bei neuen Filtern: Query-Param, Repository-Filter und Grid-State konsistent
2026-03-04 15:56:58 +01:00
- Instanziierungsstandard eingehalten (`app(...)`, keine Legacy-Helper)
## Beispiel 2: API-Response erweitern
### Schrittfolge
1. Endpoint in `pages/api/v1/...` anpassen (z. B. `pages/api/v1/me/index().php` oder `pages/api/v1/users/show($id).php`)
2. Permission- und Tenant-Scope-Prüfungen beibehalten
2026-03-04 15:56:58 +01:00
3. Optional Service/Repository ergänzen, Instanziierung über `app(...)`/Factory-Standards
4. `docs/openapi.yaml` aktualisieren
2026-03-09 18:30:52 +01:00
5. `/docs/reference-api.md` mit Beispiel aktualisieren
feat(console): add db:migrate CLI for idempotent core schema updates Existing systems used to have no automatic mechanism for the db/updates/*.sql idempotent updates after `git pull` — devs had to remember which files were already applied and run new ones manually with `mariadb < ...`. Mirror module:migrate to fix this: - New `bin/console db:migrate` walks db/updates/*.sql in alphabetical order, skipping anything already recorded in the new core_migrations tracking table. Each file runs in its own transaction; failure rolls back so the file is retried on the next run. - New `db:migrate --status` lists applied vs. pending files without running anything. Useful for ops debugging "schema seems stale" symptoms. - module:sync now runs db:migrate as its first step, so the standard post-pull command stays a single invocation. README's 3-step setup is unchanged — module:sync now also covers core schema updates. CoreMigrationRepository owns its own mysqli connection (using the same DB credentials as MintyPHP\DB) and runs raw `$mysqli->query()` instead of going through DB::query's prepared statement path — MariaDB rejects some DDL (e.g. ALTER TABLE … ADD CONSTRAINT CHECK) in the prepared protocol, which the existing 18 db/updates files trip on. ModuleMigrationRepository is left untouched (no module migration uses such DDL today and changing the vendor pattern is out of scope). End-to-end verified: against an existing DB the first run applies all 19 idempotent files as no-ops and records them, second run reports "all updates already applied". Against a freshly init'd DB the same thing happens — no double work, no surprises. All encrypted seed secrets keep decrypting because APP_CRYPTO_KEY is unchanged. Tests: tests/Console/CoreCommandsTest covers success/failure/status output shapes against a FakeModuleRunner (mirror of the existing ModuleCommandsTest pattern). 5 stale baseline entries in phpstan-baseline removed (covered by the new @api annotation on the test fixture class). Docs: CLAUDE.md and docs/reference-cli-commands.md document the new command + --status flag; docs/howto-fehlerbehebung.md gains a "schema seems stale after git pull" section pointing at db:migrate --status. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 08:59:57 +02:00
6. Bei neuen Berechtigungen: `PermissionService` + `init.sql` synchron halten, für Bestandsumgebungen idempotentes SQL-Update in `db/updates/*.sql` bereitstellen — wird automatisch von `bin/console db:migrate` (bzw. `module:sync`) angewendet
### Done-Kriterien
- Keine numerischen IDs exponieren, wenn UUID bereits Contract ist
- Fehlercodes konsistent (`ApiResponse::error(...)`)
- Kein Body-Leak in Logs/Audit
- OpenAPI und tatsächlich gelieferte Response-Felder stimmen 1:1
## Finaler Check
Vor PR/Merge diese Liste gegenprüfen:
- `/docs/reference-entwickler-checkliste.md`