Guest RSVP / +1 / plus-N counts on RSVPs, plus waitlist when capacity reached

[Salem874]

ELI5

Right now, when someone RSVPs "going" to an event, they can only count as one person — but in real life, parents bring kids and members bring spouses. Also, when an event fills up, we just say "sorry, full" instead of offering a waitlist. This adds a guest count and a waitlist that auto-fills empty seats when people cancel.

Detailed proposal

Two schema adds and one cron, layered onto the RSVP loop shipped in #88:

1. tblEventRsvps.guestCount INT NOT NULL DEFAULT 0 — additional headcount beyond the RSVPing user. Capacity check in the RSVP handler totals COUNT(going) + SUM(guestCount WHERE going) instead of just row count.
2. tblEventWaitlist (eventID, userID, guestCount, joinedAt, promotedAt NULL) — populated when a "going" RSVP arrives after tblEvents.maxAttendees is reached. UI surfaces a "Join waitlist" button instead of the current flash error.
3. Auto-promote cron — _apps/calendar/waitlist-promote.php, run hourly, scans events where capacity has freed (cancellation, status change to maybe/not_going) and promotes the oldest waitlist row whose guestCount fits the freed seats. Sends a notification using the existing notification plumbing.

UI surfaces: guest-count stepper on the RSVP form (calendar app, event detail view); waitlist position indicator ("You're #3 on the waitlist"); admin event-detail view shows total headcount including guests + waitlist length. Honours Site::branding() strings ("congregants" vs "members" vs "attendees") so ChurchMS / SchoolMS read naturally. Respects existing RSVP series-vs-occurrence semantics from tblEventSeries / tblEventRecurrence.

Pros / Cons

Pros

• Accurate headcount for catering, seating, child-safeguarding ratios
• Waitlist captures demand instead of bouncing it — useful signal for organisers
• Auto-promotion makes the waitlist self-managing (no admin intervention)
• Builds on shipped Event RSVP / registration system #88 RSVP loop; no new app, no new route group

Cons

• Guest-count abuse risk (someone claims +50 to block the event) — mitigate with maxGuestsPerRsvp per event
• Waitlist notifications add an email/push volume bump
• Promotion timing (hourly cron) means short-notice cancellations may not auto-fill before the event

How necessary?

Medium — high value for social/family events (dinners, family services, school open evenings); low value for solo-attendance events (training, services with open seating).

Acceptance criteria

• tblEventRsvps.guestCount migration added (numbered _sql/ file) with default 0
• tblEventWaitlist table created with FK to tblEvents and tblUsers
• RSVP form shows guest-count stepper bounded by maxGuestsPerRsvp (new tblEvents column, default 0 = disabled)
• Capacity-full path offers "Join waitlist" instead of error flash
• Cron promotes waitlist entries when seats free and notifies the promoted user
• Admin event detail shows total headcount (RSVPs + guests) and waitlist length

Estimated effort

6-8 hours focused work (two migrations, RSVP handler tweak, waitlist controller, promotion cron, UI stepper, admin display).

---

Filed during The Events Calendar competitive analysis on 2026-06-16; decision pending.