Repository navigation
[bug] Zeitkorrekturen funktionieren nicht #43
Description
Describe the bug
Bei der Erfassung eines Zeitkorrektur-Antrages ist es weder möglich, einen fehlerhaften Zeiteintrag direkt zur Korrektur auszuwählen, noch einen bestehenden Eintrag für denselben Tag durch eine neue Korrekturzeit zu überschreiben. Sobald der Korrekturzeitraum mit einer bereits erfassten Zeit kollidiert, schlägt das Absenden mit der Fehlermeldung "Time adjustment overlaps an existing time entry for this employee" fehl. Dadurch können fehlerhafte oder unvollständige Buchungen nicht nachträglich korrigiert werden.
Reproduzierung des Fehlers:
- Als Mitarbeiter eine bestehende Zeiterfassung für einen Tag vorliegen haben (z. B. 08:00 – 16:00 Uhr).
- Das Formular für eine Zeitkorrektur aufrufen.
- Versuchen, die korrekte Arbeitszeit einzutragen, die sich zeitlich ganz oder teilweise mit dem bestehenden Eintrag überschneidet (z. B. 08:00 – 17:00 Uhr oder 09:00 – 16:00 Uhr), oder versuchen, den ursprünglichen Eintrag direkt zur Korrektur zu referenzieren/auszuwählen.
- oben genannte Fehlermeldung beim absenden
Expected behaviour
Eine Zeitkorrektur sollte entweder:
- die direkte Auswahl eines existierenden Eintrags ermöglichen, um dessen Werte anzupassen, oder
- als beabsichtigtes Überschreiben bzw. Anpassung des bisherigen Tageseintrags verarbeitet werden (ggf. mit anschließendem Genehmigungsworkflow), anstatt als unzulässige Doppelbuchung abgelehnt zu werden.
Activity
patrickschiller commentedon Nov 7, 2026
#43 umgesetzt: gezielte Korrektur derselben Zeitbuchung
PR: #48
Head:
34a9b5094568fffd990fa0827e6e9f8c28c13209Abhängigkeit: Dieser Branch basiert auf dem akzeptierten #41-Stand und
enthält gegen main kumulativ #42 + #41 + #43. Vorgesehene Reihenfolge
#46 → #47 → #48; kein Merge und kein Auto-Merge aktiviert.
bestehende Buchung korrigieren. Eigene zulässige Buchung auswählen,
Zeiten exakt vorbelegen und Vorher/Vorschlag samt Bruttodifferenz vergleichen,
auch im Genehmigungs- und Verlaufskontext. DE/EN, lokale Zeit mit DST-Offset.
gebunden, auch nach Rückgabe und reinem Grund-Edit/Wiedereinreichen.
Kein gefälschtes Fremdziel, Retargeting oder stilles Auffrischen einer
veralteten Originalversion.
andere Buchungen bleiben geprüft, kein Tagesüberschreiben.
atomar mit Antrag und Audit. Vorgeschlagene Außenrahmenwerte erzwingen
Manager→HR; alte Buchungsfreigaben reichen nicht. Versions-/Sperrregeln
schützen auch gegen Split, direkte Änderungen, [bug] Genehmigung von Buchungen außerhalb der Rahmenzeit #41 und konkurrierende Anträge.
Auditdaten bleiben erhalten. Das neue Vorher/Nachher-Audit trägt Akteur,
Zeitpunkt und Request-Link. Kein doppelter Eintrag, keine doppelt gezählten
neuen Stunden. Bereits angewendete Korrekturen werden nicht durch bloßes
Request-Storno scheinbar rückgängig gemacht.
Additive Migration, getesteter Upgrade und synchroner API-/Client-Vertrag.
Lokale Nachweise:
ausgeführtem Entry-Update in allen finalen Approval-Routen.
gezielte UI-/DST-Prüfungen 68/68.
Builds,
pnpm verify:apiundgit diff --checkerfolgreich.ursprüngliche Auditdaten/Akteure ohne erfundene Request-Links erhalten.
GitHub-Gates auf
34a9b5094568fffd990fa0827e6e9f8c28c13209vollständig grün:build-test-lint,api-e2e,database-upgradeundterminal-pin-browsererfolgreich.pnpm verify:apierfolgreich.Builds erfolgreich.
erfolgreich; verlangter Signed-off-by- und exakter Co-Author-Trailer vorhanden.
Deutsche Nachtestanleitung – Paket #43 mit isoliertem Setup, synthetischen Rollen,
reproduzierbaren 08–16-Buchungen, Erwartungen, Negativ-/Parallel-/DST-Fällen und
tatsächlichen Ergebnissen.
Manueller Docker-/Browser-Durchlauf dokumentiert, nicht als durchgeführt
behauptet. Testdatenbank mit Datenerhalt gestoppt. Keine Releases, Tags,
Versionsbumps, Merges, Deployments oder Release-Workflows. #45/#44 nicht begonnen.
docs: clarify JWT identity expectations for correction tests (#43)