Add admin activity management

This commit is contained in:
troogs
2026-10-01 17:58:41 +02:00
parent 84ed5a7a28
commit 944eed3eb3
7 changed files with 664 additions and 5 deletions
@@ -0,0 +1,91 @@
---
agent: agent
description: Manage the Date Wizard activity catalog from the authenticated admin page, including activity CRUD, temporary pause/resume, inline creation, icon selection, duration switching, and the special custom activity.
---
Implement or review activity management for the Date Wizard application. Preserve the existing Go server, JSON settings persistence, German user-facing language, authentication, and visual conventions.
## Admin navigation and activity list
The authenticated admin page must separate date management from activity management with clear navigation. Do not show every admin workflow in one long view.
The activity view must show a list of all configured activities and must support:
- Displaying the activity icon, name, and duration state.
- Renaming an activity through an inline name editor with save and cancel actions. Do not rely on `window.prompt`, because the browser environment may not support it.
- Switching an activity between `short` (Kurz) and `long` (Lang) with a compact icon-only control.
- Showing `short` with a half-filled circle and `long` with a full circle. Both indicators must have identical dimensions and the indicator must be centered inside its button.
- Changing an activity icon by clicking its icon and opening a sufficiently large popup icon picker.
- Providing a broad, curated emoji/icon selection. Highlight the currently selected icon.
- Closing the icon picker after selection and when clicking outside it.
- Temporarily disabling and re-enabling an activity. Use a pause icon for an active activity and a play icon for a paused activity.
- Deleting regular activities with a trash icon and confirmation.
- Using icon-only action buttons with tooltips and accessible `aria-label` values. Do not use visible text labels for row actions when a familiar icon exists.
- Keeping the layout responsive on desktop and narrow screens.
## Inline activity creation
Include an add row that visually matches the existing activity rows. Adding is handled from this row rather than a separate form:
- On the left, show an icon selector button.
- Next to it, provide an input for the new activity name.
- On the right, provide a short/long duration toggle using the same half/full circle treatment as existing activities.
- Provide an icon-only save button that creates the activity.
- Validate that the name is non-empty, within the supported length limit, and that the selected duration is `short` or `long`.
- Reject duplicate names and show a useful success or error message.
- Reset the add row after a successful save.
## Special custom activity
The settings may contain one special activity with `type: "custom"`, originally named `Etwas eigenes` and using an appropriate edit/pencil icon. It has special rules:
- Always render the custom activity as the last activity in the admin list and the public activity list.
- It must remain available in the booking flow.
- When selected publicly, it lets the visitor enter a custom description.
- The description is stored with the booking submission and included in the notification email and generated iCalendar file.
- It cannot be combined with any other activity and is the only selected activity when used.
- The custom activity cannot be deleted.
- It cannot switch between short and long; hide or remove its duration/type button.
- It can be paused and resumed like other activities.
- Its rename action remains available. Renaming must not break custom-activity behavior: public code must identify the special entry by `type: "custom"`, not only by the original name.
- If custom icon editing is intentionally restricted, keep its icon stable while still allowing rename and pause/resume.
## Backend requirements
Use the existing authenticated Go HTTP API and settings file persistence.
- Add or preserve an authenticated activity endpoint such as `/api/admin/activities`.
- `GET` returns all activities for the admin, including paused activities.
- `POST` creates a regular activity.
- `PUT` updates a regular activity's name, icon, type, and disabled state.
- `PUT` allows the custom activity's name and disabled state to change while keeping its `type: "custom"` and protected fields valid.
- `DELETE` removes regular activities only and rejects deletion of the custom activity with an appropriate error response.
- Persist changes atomically under the existing settings mutex.
- Validate names, icons, supported regular types, duplicates, and malformed requests server-side.
- Filter disabled activities from the public settings response while retaining them in admin responses.
- Do not expose the admin password in public settings.
## Public booking behavior
- Public activity selection must use the enabled activities from the settings API.
- The custom activity must be identified by `type: "custom"` even if it has been renamed.
- The custom activity must remain last.
- Preserve existing short-date and long-date selection rules for regular activities.
- Preserve custom-description handling in booking, email, and iCalendar output.
## Implementation and validation
Before editing, inspect the existing admin HTML, JavaScript, CSS, public activity flow, Go handlers, settings model, and prompt conventions. Reuse existing helpers and styling patterns.
After editing:
1. Run the project formatter for changed Go files.
2. Run the available Go test/build command.
3. Run JavaScript syntax checks for changed scripts when Node.js is available.
4. Check diagnostics for changed files.
5. Verify the unauthenticated login view and authenticated navigation.
6. Verify the activity list, custom-last ordering, custom pause-only controls, inline rename behavior, inline add row, duration indicators, icon picker, pause/play states, and trash confirmation in the browser.
7. Verify that disabled activities are absent from public activity selection.
8. Do not modify `appsettings.json` or unrelated fixtures when documenting or committing this feature unless explicitly requested.
When reporting the result, summarize changed files, user-visible behavior, API behavior, and validation commands that passed or failed.