88 lines
4.9 KiB
Markdown
88 lines
4.9 KiB
Markdown
---
|
|
agent: agent
|
|
description: Create or improve the Date Wizard admin page for managing available date slots, including authentication, calendar bulk editing, staged saves, and booked-date protection.
|
|
---
|
|
|
|
Implement or review the complete admin page for the Date Wizard application. Preserve the existing project architecture, styling conventions, API patterns, and German user-facing language.
|
|
|
|
## Existing admin functionality
|
|
|
|
The admin page is available at `/admin` and must provide:
|
|
|
|
- A password login form.
|
|
- Session-based authentication using the existing admin login and logout endpoints.
|
|
- A clear message when the password is invalid.
|
|
- A clear message when the session has expired.
|
|
- A logout action.
|
|
- Loading and displaying all available dates from the admin API.
|
|
- Displaying each date with its configured type: `short` (Kurz) or `long` (Lang).
|
|
- Date validation that allows only today or future dates and only the two supported types.
|
|
- Responsive styling consistent with the existing Date Wizard design.
|
|
|
|
## Calendar bulk editor
|
|
|
|
Replace the need to add dates one at a time with a monthly calendar editor similar to the public booking calendar.
|
|
|
|
- Show a month calendar with Monday-first weekday headings.
|
|
- Provide previous-month and next-month navigation.
|
|
- Do not allow selecting today or dates in the past.
|
|
- Clicking an editable future date cycles through exactly three states:
|
|
1. Not selected: no available date.
|
|
2. First click: `short` / Kurz.
|
|
3. Second click: `long` / Lang.
|
|
4. Third click: back to not selected.
|
|
- Render a short date with a half-filled circle, for example a circle split into two colors.
|
|
- Render a long date with the normal full selected circle.
|
|
- Make the state visually and programmatically accessible with appropriate labels and disabled states.
|
|
- Show a legend explaining the short and long visual states.
|
|
- Keep all calendar changes in a client-side draft. Clicking a date must never save immediately.
|
|
- Include an explicit `Änderungen speichern` button.
|
|
- Save the complete draft in one authenticated bulk request only after the administrator clicks the save button.
|
|
- Refresh the visible date list from the draft after local changes and show a success or error message after saving.
|
|
- Allow removing an unbooked date from the pending draft without immediately saving it.
|
|
|
|
## Booked-date protection
|
|
|
|
Dates that have already been booked are read-only in the admin page.
|
|
|
|
- Load booked dates from the existing `/api/booked-dates` endpoint.
|
|
- A booked date must remain in the available-date configuration and must not be removable through the admin calendar.
|
|
- Render a booked future date as a green calendar circle.
|
|
- Disable the calendar button for a booked date so clicks do nothing.
|
|
- Mark the calendar entry as booked using an accessible label.
|
|
- Disable its `Entfernen` button in the date list.
|
|
- Style the disabled removal button grey with a not-allowed cursor.
|
|
- Do not let bulk-save requests remove or modify booked dates, even if a malicious or stale client submits a draft that omits them.
|
|
- Enforce this protection server-side as well as in the browser.
|
|
|
|
## Backend requirements
|
|
|
|
Use the existing Go HTTP server and settings persistence mechanisms.
|
|
|
|
- Keep the existing single-date endpoints compatible unless there is a compelling project-specific reason to change them.
|
|
- Add an authenticated bulk endpoint, such as `POST /api/admin/dates/bulk`.
|
|
- Accept a JSON array of objects shaped like `{ "date": "YYYY-MM-DD", "type": "short" | "long" }`.
|
|
- Reject malformed dates, unsupported types, duplicate dates, past dates, and today.
|
|
- Validate the complete request before changing the settings file.
|
|
- Save the complete future-date selection atomically under the existing settings mutex.
|
|
- Preserve historical dates according to the existing application behavior.
|
|
- Preserve all booked dates regardless of whether they are included in the submitted draft.
|
|
- Do not create duplicate available-date entries.
|
|
- Return useful JSON success and error responses and use appropriate HTTP status codes.
|
|
|
|
## Implementation and validation
|
|
|
|
Before editing, inspect the existing admin HTML, JavaScript, CSS, Go handlers, settings model, public booking calendar, and booked-date storage/API. Reuse existing helpers and visual patterns where practical.
|
|
|
|
After editing:
|
|
|
|
1. Run the project's formatter.
|
|
2. Run the Go test/build command available in the repository.
|
|
3. Run a JavaScript syntax check for the admin script when Node.js is available.
|
|
4. Check diagnostics and whitespace errors.
|
|
5. Verify that the page renders the login view when unauthenticated.
|
|
6. Verify that the calendar, save button, staged state changes, booked green state, and disabled grey removal button are present after authentication.
|
|
7. Do not modify booked-date fixtures or unrelated application behavior.
|
|
|
|
When reporting the result, summarize the files changed, the user-visible behavior, the API changes, and the validation commands that passed or failed.
|