For recurring events, members can now choose whether their "Going" RSVP
applies to a single upcoming instance or to every following instance in
the series. Previously, a "Going" RSVP silently persisted forever across
all future recurrences with no way to opt out short of leaving the
event.
The recurring `Going` button is now a dropdown with two options:
- "This event" (default): the RSVP applies only to the next occurrence
and is cleared when the recurrence advances.
- "This event and all following events": the RSVP persists across every
future occurrence until the member changes it.
Non-recurring events are unchanged and still expose a plain `Going`
button.
Implementation:
- New `recurring` boolean column on `discourse_post_event_invitees`,
defaulting to false.
- `Invitee#recurring=` coerces to a strict boolean and a `before_save`
callback enforces that only `going` rows can be recurring, so the
invariant is owned by the model.
- `Event#reset_invitee_notifications` (called on recurrence advance) now
also clears `going` rows that are not marked recurring, restoring the
original pre-regression "reset on each occurrence" behavior as the
default while keeping the opt-in persistent mode intact.
- `CreateInvitee` / `UpdateInvitee` services accept a `recurring` param
threaded through from the controller. The `InviteeSerializer` exposes
`recurring` so the UI can reflect the current selection.
- The participant chip and the trigger button swap between the `check`
and `arrows-rotate` icons depending on the invitee's `recurring` flag.
Ref - t/144138
