## Herkunft Sammel-Issue für die Befunde aus der Abnahme zu **v4.5 Welle 2** (Rechte-Konsolidierung), die bewusst **nicht** im selben MR behoben wurden — teils Bestandsprobleme, teils strukturelle Verbesserungen, die einen eigenen Review verdienen. Die Blocker und die billigen Punkte sind in Welle 2 erledigt. --- ## 1. `setStatus()` strukturell härten statt per Konvention Der zentrale Rechte-Riegel in `EinsatzService::setStatus()` ist ein **Opt-out per Parameter**: `$autoReason === null` heißt „vom Benutzer ausgelöst, Recht prüfen". Ein künftiger Aufrufer, der eine Begründung aus einem Formular durchreicht, schaltet den Riegel **stillschweigend ab**. Heute ist das sauber (alle sechs Aufrufer geprüft: drei ohne Parameter, drei mit hartkodiertem Literal), aber die Absicherung hängt an Disziplin — genau dem, was die ganze Drift-Klasse verursacht hat. **Vorschlag:** ```php public function setStatus(int $id, string $newStatus, User $editor): bool // ohne $autoReason private function setStatusAuto(int $id, string $newStatus, User $editor, string $grund): bool ``` Dann ist die Ausnahme von außen gar nicht mehr erreichbar, statt nur „nicht gemeint". ## 2. `einsatz-alarm-trigger.php` umgeht das neue `abschnitt.create`-Gate `public/api/einsatz-alarm-trigger.php` gatet auf `einsatz.edit`; `AlarmProcessor::createFollowupAbschnitte()` ruft `abschnittService->create()` direkt am Service. Eine Rolle mit `einsatz.edit`, der ein Admin `abschnitt.create` **bewusst entzogen** hat, kann darüber weiterhin Abschnitte entstehen lassen. Risiko gering (Templates sind admin-gepflegt, `rule_ids` werden serverseitig gegen `findPendingRules` gefiltert) — aber #205 ist damit nicht vollständig dicht. Bewusst entscheiden: akzeptieren und dokumentieren, oder `abschnitt.create` für den Abschnitts-Teil verlangen. ## 3. `max_abschnitte_pro_einsatz` wird serverseitig nicht erzwungen `public/api/abschnitte-create.php` berechnet `$maxLimit` und **benutzt es nie** — begrenzt wird nur clientseitig im Modal. Relevanz durch #205 gestiegen: Jeder offene Abschnitt blockiert über die Abschnitts-Sperre das Erledigen **und** Abschließen des Einsatzes. Eine Rolle mit `abschnitt.create` kann damit unbegrenzt Abschnitte anlegen und den Abschluss blockieren — billiges „Denial of Closure" gegen Rollen, die eigentlich mehr dürfen. - [ ] Bestand + Request gegen `$maxLimit` prüfen, mit 409 ablehnen ## 4. `assigned_dispo_user_id` wird in `create()`/`update()` nicht validiert `EinsatzService::bindParams()` übernimmt den POST-Wert roh. Der Bulk-Endpoint validiert dagegen sauber via `$u->isAnyDispo()`. Für #204 heißt das: Der **einzige** ohne `einsatz.status` erreichbare Statuswechsel (`neu → dispo`) wird von einem völlig ungeprüften Request-Feld ausgelöst, und es lässt sich eine beliebige User-ID als Disponent eintragen — auch ein Gast. Im Review **keine Rechteausweitung** gefunden (der SP-Scope hängt an `einsatz_schwerpunkt`, nicht an der Dispo-ID; der Dispo-Eigentumsfilter greift über `created_by`), aber die Inkonsistenz gehört geschlossen. ## 5. Kleinkram - [ ] **Gate-Reihenfolge angleichen**: In `create()` steht das Rechte-Gate **vor** `validateRequired()`, in `update()` **danach**. Fail-closed-first (create) ist die bessere Variante. - [ ] **Toter JS-Hook**: `public/assets/js/einsaetze-view.js` hängt an `#btn-abschnitte`; das Element existiert nicht (der Toolbar-Knopf nutzt inline `onclick`). - [ ] **`validateStatus('')`** wirft „Ungueltiger Status: " — über die Oberfläche nicht erreichbar, die Meldung wäre aber kryptisch. - [ ] **Falscher Kommentar** in `EinsatzService` (~Z. 942): behauptet, MailParser/AlarmProcessor liefen „alle über `EinsatzService::create()`" — war schon vor Welle 2 falsch. - [ ] **`public/einsaetze/view.php`**-Docblock nennt `abschnitt.create` nicht, obwohl die Seite jetzt daran hängt. ## 6. Testabdeckung - [ ] Kein Test deckt **#205** ab (weder Endpoint-Gate noch UI-Bedingung). - [ ] Der `ApiPermissionGateTest` prüft weiterhin **Quelltext**, nicht Verhalten, und deckt nur `public/api/*` ab. Die Verhaltens-Tests (`StatusRechtDbTest`) laufen nur im e2e-Job, der in MRs manuell + `allow_failure` ist. Zu klären: Soll die Gruppe `db` in den immer laufenden `tests`-Job (bräuchte einen DB-Service dort), oder soll e2e bei Rechte-Änderungen verpflichtend angestoßen werden? _Abnahme v4.5 Welle 2, 20.07.2026 (code-reviewer + security-reviewer)._