Skip to main content

Todo List, Notices & Wishlists

What it is​

Three planning/communication utilities: todoList (per-event planning checklist, with AI-assisted generation), notices (admin-broadcast system announcements — distinct from event Broadcast, which is planner-to-guest), and wishlists (the actual wishlist entity — creation and management — that Gift & Giftstore's catalog and wishbasket's contributions both build on).

Core concepts​

  • Wishlists, giftstore, and wishbasket are layers, not competing systems. wishlists owns creating and managing the wishlist entity itself (with an optional eventId — a wishlist can be standalone or tied to an event, per createWishlist's validation). giftstore is the product catalog those wishlist items are drawn from, with its own Redis-staged "temporary → confirm" browsing UX. wishbasket is the guest-contribution layer on top of a wishlist's items. WishlistsService directly depends on WishbasketRepository, confirming the layering rather than three independent implementations of the same idea.
  • Notices are admin-pushed, not planner-pushed — sendGlobalNotice (all users) and sendUserNotice (one user) both require defaultAdminUserAuth. This is a different audience and trigger from event Broadcast, which a planner sends to their own event's guests.

How it works​

Todo List​

POST /todolist/event/:eventId (add item), PUT .../update/event/:id, DELETE .../event/:eventId/todo/:todoId, GET .../event/:eventId (flat) or .../sectioned (grouped). POST /todolist/event/:eventId/ai/generate — AI-assisted todo list generation, presumably seeded from event type/details to suggest a starter checklist rather than a blank list.

Notices​

POST /notices/dismiss — a user marks a notice as seen/dismissed (Zod-validated). POST/DELETE /notices/global and POST/DELETE /notices/user/:userId are admin-only send/clear operations. POST /notices/admin/cleanup — periodic removal of old notices, an explicit maintenance action rather than automatic expiry.

Wishlists​

  • Public, unauthenticated: GET /wishlists/public/:reference, .../items, .../items/:itemReference — anyone with a shared link can view a wishlist without an account, mirroring the public wishbasket/giftstore reads.
  • Authenticated: POST /wishlists (create), GET /wishlists (own wishlists), GET /wishlists/standalone (specifically the ones not tied to an event), GET /wishlists/:reference.
  • GET /wishlists/themes — presentation themes for a wishlist's public page.

Key business rules & edge cases​

  • Dismissing a notice is per-user, tracked separately from the notice's existence — clearing a global notice (DELETE /notices/global) removes it for everyone, while a user's own dismiss call only affects their own view; don't conflate the two when debugging "why does this user still see a notice I cleared" (check whether it was cleared globally vs. never dismissed by that user).
  • Because a wishlist can be standalone (no eventId), don't assume every wishlist has an associated event when writing queries or reports — getStandaloneWishlists exists specifically because that's a real, distinct category.

Not yet in the generated OpenAPI spec. POST /v1/todolist/event/{eventId}, POST /v1/todolist/event/{eventId}/ai/generate, POST /v1/notices/dismiss, POST /v1/wishlists, GET /v1/wishlists/public/{reference}.

  • src/modules/todoList/ — routes/controller
  • src/modules/notices/ — routes/controller/service
  • src/modules/wishlists/wishlists.routes.ts, wishlists.service.ts (depends on WishbasketRepository)