Cookiemonsters

Imported from the pre-Redmine CookieMonsters TODO during the 2026-08-29 migration.

Original priority: P2 — Next feature layer

• Build a first-class Community Event Calendar / Game Nights experience:
  • every signed-in member may create events; this is a community feature, not an admin-only calendar;
  • add an event Audience choice with at least Site and Community only;
  • Community only is available when the event creator belongs to one or more CookieMonsters communities; after selecting it, require the creator to choose exactly which of their current communities the event belongs to (e.g. Audience → Community only → [My community]);
  • the community picker must list only communities the creator is actually a current member of; do not let a crafted request attach an event to an unrelated community, and re-check membership server-side on create/edit;
  • a Community-only event is discoverable only by current members of that selected community: non-members must not see its title, game, date/time, image, RSVP counts, attendee names, feed activity, search result or direct-link metadata, and direct API/event URLs must reject access server-side;
  • Community-only events should still appear normally in the shared Calendar for eligible community members, with a discreet community badge/name so they understand why they can see it; members can later get a filter such as All events / My communities / Site events without splitting the calendar into separate systems;
  • RSVP actions and attendee lists on a Community-only event are limited to members who currently have access through that community; if someone leaves/loses membership, they immediately lose normal event discovery/access and their old RSVP must not become an information leak;
  • the News Feed activity for a Community-only event is generated only for members of the selected community and must never appear in the general/site feed for outsiders; the normal From one of your games highlight can still apply inside that eligible audience;
  • if the creator later changes an event between Site and Community only, recalculate Calendar/feed/notifications/direct-link access immediately and present a clear audience summary before saving so a private community event is not accidentally widened;
  • if the creator leaves the selected community or that community is deleted, fail safely: do not silently convert the event to Site-wide; hide/freeze it until the creator has valid community access again or explicitly moves/deletes it under an authorized flow;
  • add a clear Community main navigation section that can contain Calendar, Members and other shared community destinations as the site grows; the left/sidebar navigation should expose the same logical Community group cleanly;
  • the homepage Game nights entry/card/link should open the Calendar/Event experience instead of pointing at static example content;
  • each event requires a Subject/title, Body/description, date, start time, end time and a selected game from the shared CookieMonsters game catalog; allow Other only as the normal safe catalog fallback when needed;
  • event creation/editing uses the creator's saved account time zone as the default input zone, while event lists/details display the corresponding time automatically in each viewer's own saved time zone;
  • always make the displayed time zone understandable (e.g. small Europe/Stockholm / CEST context or a hover/details affordance) so members in different countries can trust what time they are seeing;
  • store event times in a timezone-safe way and preserve the source IANA zone so daylight-saving transitions do not break recurring expectations or edit semantics;
  • allow the event creator to upload an optional event image/banner using the protected-media pipeline; if no custom image is supplied and the selected game has curated cover art, use that game's cover naturally in the event card/detail view;
  • selecting a known game such as Palia should therefore automatically give the event a recognizable game cover/visual treatment while still allowing a custom event image to take precedence when provided;
  • show Calendar in a polished month/list/upcoming experience rather than a dense admin table; mobile should prioritize an easy upcoming-events list while still letting members navigate dates;
  • event cards/detail views should show subject, game, localized date/time, creator, body/description, image/game cover and attendance state without becoming visually noisy;
  • add RSVP actions with three friendly states: Attending, Maybe, Not attending; make the choice quick to change and persist it server-side per member/event;
  • the event creator must be able to see the attendee breakdown and exactly which members chose Attending, Maybe and Not attending; ordinary attendee-list visibility can follow the same initial open community model unless we later add an event-specific privacy setting;
  • the creator can edit their own event after publishing, including date, start/end time, game, Subject, Body and event image; edits must update Calendar/feed/detail views consistently rather than creating a second event object;
  • when the creator makes a material change such as date/time cancellation later, provide a clean notification path to members who had RSVP'd so they do not miss the change; exact reminder/cancellation UX can be refined during implementation;
  • only the creator (plus legitimate site moderation/admin authority where needed) may edit/delete that event; enforce ownership server-side rather than relying on hidden edit buttons;
  • new events should generate a News Feed activity item such as A new event has been posted with the event subject/game/date and a direct link to the event;
  • highlight/re-rank the feed treatment for members who have that same game in My Games, so a Palia event stands out more to members who play Palia while remaining discoverable in the normal general event feed for everybody else;
  • keep the game-aware highlight transparent/simple rather than turning the feed into an opaque recommendation algorithm; it can be a stronger card accent, From one of your games badge or similar treatment;
  • Calendar/event discovery must respect blocks and any future community/private-event audience rules so blocked or unauthorized members cannot learn hidden event metadata through feed cards, RSVP lists or direct URLs;
  • keep event strings, RSVP labels, dates and time-zone formatting translation-ready/localized from the start;
  • add a Birthday module into the same Calendar system rather than creating a separate disconnected birthday calendar;
  • when a member has enabled Show my birthday, automatically surface that member as a birthday entry on the correct month/day in Calendar and in the signed-in Home upcoming-calendar module; the member should not need to manually create a birthday event every year;
  • birthday entries are privacy-driven system items, not ordinary editable community events: the source is the member's stored birth date plus their Show my birthday setting, and turning the setting off must remove the birthday from other members' Calendar/Home/Feed immediately;
  • show a friendly birthday item such as 🎂 Ambi's birthday / It's Ambi's birthday! with avatar/profile link where allowed; do not expose birth year or calculated age unless that member separately chose to share age;
  • birthday visibility must follow blocks and normal profile-discovery rules, and must never become a way for a blocked/unauthorized viewer to discover the member or infer hidden birth-date details;
  • birthday entries are all-day/local-date items and should not be distorted by time-zone conversion into the previous/next day; store/render the birthday as month/day semantics rather than an arbitrary UTC midnight timestamp;
  • optionally include visible birthdays in the member's News Feed/Home activity, especially today / this week, but keep the treatment warm and lightweight rather than flooding the feed every year;
  • do not show RSVP controls like Attending/Maybe/Not attending on birthday system items unless we deliberately design a separate birthday-celebration event later;
  • later extensions may include event comments, recurring events, reminders, calendar export/subscription and additional private-event audience types, but do not block the first useful Calendar on those extras.

CM-TODO-ID:38affba44384c30e378b

Future notes, acceptance criteria and status changes belong in this Redmine issue.