78 lines
4.6 KiB
Markdown
78 lines
4.6 KiB
Markdown
---
|
|
agent: agent
|
|
description: Manage booked dates in the authenticated Date Wizard admin page, including newest-first display, activity and booking metadata, and confirmation-gated deletion.
|
|
---
|
|
|
|
Implement or review booked-date management for the Date Wizard application. Preserve the existing Go server, JSON booking persistence, authenticated admin behavior, German user-facing language, and visual conventions.
|
|
|
|
## Admin navigation
|
|
|
|
Add a separate booking-management view to the authenticated `/admin` page. Keep it between the existing `Termine` and `Aktivitäten` navigation items. The view is reached through a visible navigation button and must remain responsive on narrow screens.
|
|
|
|
The booking view is initially read-only except for deleting a booking. Do not add editing controls for the booking date, duration, name, activities, or booking timestamp.
|
|
|
|
## Booking list
|
|
|
|
Load bookings through an authenticated admin endpoint and display them newest first using the booking creation timestamp `bookedAt`.
|
|
|
|
Each booking entry must:
|
|
|
|
- Display the selected date as the primary information, formatted in German.
|
|
- Display every selected activity when one or more activities are present.
|
|
- Display each activity's stored icon and name, including the single-activity case and multiple-activity case.
|
|
- Display the booker's name only when a non-empty name is available.
|
|
- Display the date and time at which the booking was created from `bookedAt`.
|
|
- Display a useful empty state when no bookings exist.
|
|
- Render all values as text content rather than injecting untrusted booking data as HTML.
|
|
|
|
Keep legacy records with missing optional values displayable. Do not fabricate a booking timestamp when `bookedAt` is empty.
|
|
|
|
## Backend API
|
|
|
|
Use the existing authenticated Go HTTP API and booking storage helpers.
|
|
|
|
- Add or preserve an authenticated `GET /api/admin/bookings` endpoint.
|
|
- Return structured booking records containing `bookedAt`, `date`, `dateType`, `name`, and `activities`.
|
|
- Sort records newest first by `bookedAt`, while keeping records with missing timestamps valid.
|
|
- Do not expose the full booking records through the public `/api/booked-dates` endpoint; that endpoint may continue returning only date strings.
|
|
- Reject unauthenticated requests with the existing JSON authentication response.
|
|
- Return appropriate errors for malformed requests and storage failures.
|
|
|
|
## Booking deletion
|
|
|
|
Provide one `Termin löschen` button for every booking entry.
|
|
|
|
- Ask for explicit confirmation before sending a delete request.
|
|
- Include the formatted booking date in the confirmation question.
|
|
- Add an authenticated `DELETE /api/admin/bookings` endpoint accepting `{ "date": "YYYY-MM-DD" }`.
|
|
- Delete only the matching booking record from `config/dates_booked.json`.
|
|
- Return a not-found response when the requested booking does not exist.
|
|
- Keep the delete button disabled while the request is in progress.
|
|
- Reload the booking list after successful deletion.
|
|
- Remove the deleted date from the admin calendar's booked-date state and refresh the affected date displays.
|
|
- Keep confirmation and deletion errors visible to the administrator.
|
|
- Do not delete or modify any other booking record.
|
|
|
|
## Persistence and safety
|
|
|
|
Preserve the existing structured booking format and booking uniqueness rule: at most one booking record exists for a date. Use the existing booking mutex and atomic JSON write helper for deletion. Do not modify `config/appsettings.json` or expose the admin password.
|
|
|
|
## Implementation and validation
|
|
|
|
Before editing, inspect the existing admin HTML, JavaScript, CSS, Go handlers, booking model, storage helpers, public booked-date endpoint, and prompt conventions. Reuse existing request helpers and styling patterns.
|
|
|
|
After editing:
|
|
|
|
1. Run `gofmt` on changed Go files.
|
|
2. Run the available Go test or build command.
|
|
3. Run a JavaScript syntax check for changed scripts when Node.js is available.
|
|
4. Check diagnostics for changed files.
|
|
5. Verify unauthenticated access still shows the login view.
|
|
6. Verify the booking tab appears between `Termine` and `Aktivitäten`.
|
|
7. Verify newest-first ordering, date display, single and multiple activity display with icons, optional name display, and booking timestamp display.
|
|
8. Verify the delete confirmation prevents deletion when cancelled and deletes only the confirmed booking when accepted.
|
|
9. Verify the calendar booked state updates after deletion.
|
|
10. Do not alter `config/appsettings.json` or unrelated fixtures when documenting or committing this feature.
|
|
|
|
When reporting the result, summarize changed files, user-visible behavior, API behavior, persistence effects, and validation commands that passed or failed.
|