troogs/date-wizard
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add bulk date management functionality and update admin interface

Browse Source
This commit is contained in:
troogs
2026-10-01 17:16:02 +02:00
parent 3605a42099
commit 84ed5a7a28
5 changed files with 371 additions and 141 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/prompts/11-admin-page.prompt.md
+87
View File
@@ -0,0 +1,87 @@
---
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.