Backend: Delete reservation
Last modified with commit 54c7b1e on
by TjasaSimovic.
Backend task for deleting a Vozni park reservation (DELETE /drivepark/reservations/{reservationId}) – confirm hard delete of the reservation and its booking row, implement, and verify against the spec.
Docs: Kalendar zauzetosti (Reservation menu → Ukloni rezervaciju, Delete confirmation modal)
Spec: DELETE /drivepark/reservations/{reservationId} (deleteDriveParkReservation), DriveParkReservationNotFound in api-docs/openapi.yaml
DB: DriveParkReservations, VehicleReservations in api/database/pending_schema.sql (-- DRIVE PARK --)
1. Double check API spec and DB structure
- Hard delete: the spec and schema delete the DriveParkReservations row and its VehicleReservations row permanently. The reservation then also disappears from the vehicle’s usage overview. Confirm no history of deleted reservations is needed.
- Past, current and future reservations can be deleted (no rule in the docs). Confirm.
- Zapisnici are not linked, so a record started from the reservation stays.
- The modal subtitle (name · vehicle · plate) comes from the calendar entry the frontend already has; no extra data needed.
- Roles and permissions:
drivepark.access.
2. Implementation
- Roles and permissions: require
drivepark.access→ 403. - In one transaction: delete the VehicleReservations row (
DriveParkReservationId), then the DriveParkReservations row. No vehicle lock needed: deleting can’t create an overlap. - Unknown id → 404. Success → 204.
3. Verify implementation against spec
- Status codes match
deleteDriveParkReservation. - After deleting, the bar is gone from the calendar and a new reservation for the same days → 201.
- Deleting twice → 404 the second time. BrandManager → 403.
Done when
A Manager of Vozni park can remove a reservation, and the vehicle is free again for that period.