92 lines
6.0 KiB
Markdown
92 lines
6.0 KiB
Markdown
---
|
|
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.
|