Skip to main content

Creating events

Events are the workhorse of the Community module. Officers can create them, members can RSVP, and at game time officers mark people checked in. This page walks through every form field, the RSVP and check-in flow, edit and cancellation behavior, and the features that aren't built today.

What you see​

Open Community → Events and you land on the chapter events grid. Each event renders as a card with the title, event-type pill, start-end window, location, the running counts of attending and maybe RSVPs (plus a waitlisted count once anyone joins one — see Waitlist below), and any "Required" or "Cancelled" badges. Filter chips at the top let you narrow to a single event type. Officers get a Create Event button in the header; members don't.

Creating a chapter event: title, type, location, and start/end times.

chapter events grid with type filter and Create Event button chapter events grid with type filter and Create Event button

Click any card to open the detail dialog. Members see event metadata, their own RSVP buttons, and the four-way RSVP summary (attending / maybe / not attending / waitlisted counts). Officers additionally see the full attendance table at the bottom with a Check In button on each attending row.

Create an event​

  1. Open Community → Events.
  2. Click Create Event (officers and admins only).
  3. Fill in the form:
    • Title (required, max 255 chars).
    • Description (optional, free-form text — not rich text in v0.62.1).
    • Event type (required). One of: Social, Philanthropy, Meeting, Rush, Professional Development, Community Service, Fundraiser, Other. The values are fixed in code — you can't add a new type without an org-admin/backend change.
    • Location (optional, max 255 chars). Free text: physical address, room number, Zoom link, "TBD", etc. The platform doesn't parse it.
    • Start time and End time (both required). Picked via a native datetime-local input; end must be strictly after start or the API rejects the request with a validation error.
    • Max attendees (optional). A positive integer that caps Attending RSVPs — see Capacity caps below.
    • Budget (optional, dollars). For internal planning. Not connected to the finances module.
    • Mandatory event (toggle). Surfaces a "Required" badge on the card and detail; useful for chapter meetings and ritual events.
  4. Click Create Event.

The event is created on your chapter automatically — the create form on the chapter view picks up chapter_id from your active membership and you don't choose it manually. The server stamps organization from that chapter, created_by from your user, and writes the row. The Events list refetches and the new card appears at the top.

Capacity caps​

max_attendees is enforced — but as a waitlist gate, not a hard rejection. The API doesn't reject the 26th "Attending" RSVP on a 25-cap event; it silently converts that RSVP to Waitlisted (with a position number) instead. Members see this as their "Attending" button relabeling to "Join Waitlist." The card still shows a "Max 25" label, and the detail dialog shows a live Waitlisted count alongside Attending / Maybe / Not Attending.

Waitlisted members are auto-promoted to Attending when a spot opens — specifically, when an Attending member switches their own RSVP to Not Attending (Withdraw RSVP does not trigger promotion, only the Not Attending button does). The promoted member gets an in-app notification and email. You don't have to manage the waitlist by hand; see Waitlist below for the member-facing details.

Recurring events​

Recurring events (a "Repeats" picker with Daily/Weekly/Monthly options, an end condition, and automatic materialization of future occurrences) shipped in v0.65.17 — but only on the org admin / regional admin Events page. The chapter officer create form documented above doesn't have a Repeats control: if you need a weekly meeting to repeat automatically instead of creating each week's event by hand, ask your org or regional admin to set it up from their Events page. See Events (admin view) for exactly how that works, including how editing or deleting one occurrence versus the whole series behaves.

Conflict warnings​

When an org or regional admin creates or edits an event that overlaps another event in your chapter's time slot, they get a dismissable "Schedule conflict(s) detected" warning — it never blocks the save, so an overlap can still happen. There's no equivalent warning on the officer create form; if you're double-booking your chapter's meeting room, that's on you to catch. See Conflict detection for the admin-side behavior.

Visibility​

Event scope is straightforward: each event has one chapter FK and one organization FK. The chapter FK can be null only when an org admin creates an event without picking a chapter — that becomes an "org-wide" event visible to every member of the org. Officers cannot create org-wide events; the chapter is implicitly your chapter.

There is no region-scope visibility and no cross-chapter visibility for officer-created events. If you want sister chapters to see your philanthropy weekend, ask your regional admin or national admin to author the event at the right scope.

RSVP​

Members and officers pick from three fixed RSVP states:

  • Attending
  • Maybe
  • Not Attending (rendered as "Can't Go" on the button)

That's the full list of RSVP statuses — there's a fourth, system-assigned status (Waitlisted) covered below, but members never pick it directly. There are no custom RSVP types ("going / volunteering / spectator") and no per-event custom fields (dietary preferences, t-shirt size, plus-ones). If you need those, collect them out-of-band — a forum thread, a Google Form, a chapter meeting — and store the result in a member profile custom field your org admin set up.

RSVP is upsert behavior — your current RSVP for an event is one record, keyed by event and member. Changing your mind from Attending to Maybe updates that single record; there are no duplicate RSVPs.

Cancelled events hide the RSVP buttons; the cancellation banner replaces them.

Waitlist​

Once an event's Attending count reaches max_attendees, the next member who taps "Attending" doesn't get blocked — the button relabels to Join Waitlist, and tapping it records them as Waitlisted with a position number. Their detail dialog shows "You're #N on the waitlist. You'll be moved to attending automatically if a spot opens up."

Promotion is automatic: when an Attending member switches to Not Attending, the lowest-position waitlisted member is promoted to Attending and gets a notification + email ("You're off the waitlist!"). Note that this only fires on the Not Attending transition — a member using Withdraw RSVP to delete their record outright does not trigger a promotion. If a member asks why the waitlist didn't move after they backed out, check whether they withdrew instead of switching to Not Attending.

The attendance table shows waitlisted members with a "Waitlisted #N" badge instead of a status pill (the org admin's table additionally groups them together, sorted by position), and they don't get a Check In button until they're promoted to Attending.

What members see​

A member's view of the same event is the detail dialog without the officer-only attendance table. They see:

  • Event title, type pill, mandatory / cancelled badges.
  • Description, start / end window, location, max attendees.
  • Their own RSVP buttons (relabeled to "Join Waitlist" if the event is full).
  • The four RSVP count cards (attending / maybe / not attending / waitlisted) — they can see the rollup but not who RSVPed what.

Members can RSVP from this dialog directly, or — depending on which view they opened — from their own Events page where they get the same dialog.

Check members in​

When the event happens, officers (or a chapter president, or any admin) mark attendees as checked in.

  1. Open the event detail dialog.
  2. Scroll to the Attendance table at the bottom.
  3. For each member who shows up, click Check In on their row. The row updates immediately — a green check icon replaces the empty marker, and the checked_in_at timestamp is recorded.

A few details that matter:

  • Only "Attending" RSVPs get a Check In button. Members with Maybe or Not Attending RSVPs are visible in the table but you can't check them in directly. If they show up unannounced, ask them to switch their RSVP to Attending first (on their phone, in the dialog), then check them in.
  • There's no QR code, no scan flow, no kiosk mode. Check-in is a single tap per member from the officer's device. If you've used GreekManage before v0.50.0 in a different community, the QR-check-in flow you remember was never built; the doc just claimed it.
  • Check-in is one-way at the API. The endpoint accepts a member ID and flips checked_in = true with the current timestamp. There is no "un-check-in" endpoint. If you check in the wrong person, ask your org admin to clear the field directly via Django admin, or delete the RSVP entirely and have the member re-RSVP.
  • Already-checked-in rejects. The endpoint returns 400 ("Member is already checked in.") on a duplicate check-in attempt, so accidental double-taps are safe.

Mobile differences for officers running check-in​

If you're working the door with your phone, the same officer events page is responsive — the attendance table reflows so member name, RSVP badge, and check-in button stack vertically. Tap to expand the event card, scroll to attendance, tap Check In. Practically: have one officer on the phone, one at the sign-in table. If your chapter has a tablet, the desktop layout works fine on iPad too.

There is no offline mode. If you lose connection, the check-in mutation fails silently in the toast — wait, reconnect, retry.

Edit an event​

Open the event detail dialog and the underlying record is the same shape as the create form. To edit fields after creation, use the same officer-accessible form in your org's UI (or via the API: PATCH /api/events/{id}/). Editable fields include title, description, type, location, start/end, mandatory toggle, max attendees, and budget.

Validation (v0.63.17+): the create / edit form rejects end_time <= start_time both client-side and server-side. Max attendees IS enforced server-side, but as of v0.65.17 the mechanism is auto-waitlist, not rejection — an "Attending" RSVP that would push the count past the cap is converted to Waitlisted instead of erroring out (older events that exceeded the cap on data migration are grandfathered in for existing RSVPs).

A few rules:

  • Changing start / end is allowed even when members have already RSVPed — they aren't notified automatically; tell them.
  • Changing the chapter FK is not allowed in practice — the UI doesn't expose it; the backend enforces that the chapter's organization matches the event's organization via clean().

Cancel an event​

Cancelling doesn't delete. Set is_cancelled = true and add a cancellation_reason (free text). The event stays in the list with a red Cancelled badge and the reason shown in the detail dialog. RSVPs are preserved — they don't auto-flip to "Not Attending" — so you keep the audit trail of who'd planned to come.

To uncancel, set is_cancelled = false and clear the reason. There is no separate restore flow.

If you really need an event gone (test event, duplicate), use the Delete action on the detail dialog. Deletion cascades to RSVPs; recover only via DB backup.

What members are notified about​

GreekManage's notification pipeline does not blast an "event created" notification to every chapter member in v0.62.1. There is no officer-side "Send reminder" button on events. If you want eyes on a new event:

  • Post an Engage bulletin or forum thread linking to the event.
  • Mark the event mandatory so it surfaces on dashboards.
  • Mention it in your weekly chapter email.

Reminders for upcoming events flow through the standard notifications system (digest emails, in-app bell) and are not officer-triggerable.

Calendar feed (ICS)​

Two ICS subscription feeds are available, both shipped v0.65.17:

  • Your personal feed — same as any member's: Account Settings → Subscribe to Calendar (copyable URL + Reset URL), or the Subscribe to Calendar button in any event's detail dialog. Covers every chapter you belong to.
  • Your chapter's feed — open your chapter's detail page and switch to the Calendar Feed tab (visible to officers, presidents, and admins). It shows a shareable URL scoped to your chapter's events only, plus a Reset URL button — use that if the link ever leaks and you want the old one to stop working. Share this URL with members who want their calendar app to pick up chapter events automatically instead of subscribing individually.

Both feeds are unauthenticated bearer-token URLs — anyone with the link can read the calendar, so treat Reset URL as your revocation mechanism if a link gets shared somewhere it shouldn't.

Errors and edge cases​

SymptomCauseWhat to do
"End time must be after start time."You set end ≤ start.Push end later.
Create button greyed outTitle, start, or end is empty.Fill all required fields.
Cards show stale RSVP countsReact Query cache hasn't refetched yet.Refresh or reopen the page.
"Member is already checked in."Double-tap on Check In.Ignore — first tap took.
RSVP buttons not visibleEvent is cancelled.Expected — uncancel if needed.
You see "Required" on a card you didn't expectSomeone toggled is_mandatory.Open and edit, uncheck the toggle.
You see an "org-wide" event you can't editAn org admin authored it without a chapter.Officer permissions don't extend to org-wide events; ask the org admin to edit.
"Attending" button shows "Join Waitlist"The event's Attending count already equals max_attendees.Expected — tapping it still records the RSVP, just as Waitlisted instead of Attending.
Waitlisted member wasn't promoted after someone droppedThe dropped member used Withdraw RSVP instead of switching to Not Attending.Only the Not Attending transition fires auto-promotion. There's no manual "promote" button in the UI; ask your org admin to intervene via the API/Django admin if you need it fixed immediately.

Things this page used to claim that don't exist​

Phase 0 cleaned a number of fabrications. To be explicit so nobody re-introduces them:

  • Cover image — Event has no cover_image field. Don't promise one.
  • Custom RSVP types — member-chosen RSVP statuses are fixed to attending / maybe / not_attending (waitlisted is system-assigned, never a button a member picks). No "going / volunteering / spectator" picker.
  • Custom fields on events — the model has no JSON blob or per-event custom-field table.
  • Region-wide or org-wide visibility for officer-created events — Event.chapter is a single FK; only org admins can leave it null for an org-wide event.
  • Send reminders — no officer-side send_reminder endpoint. Reminders go through the standard notifications pipeline only.
  • QR check-in / scan — the check-in endpoint accepts a member ID; there's no QR code generation or scan flow.
  • Recurring events on the officer create form — the Repeats picker only exists on the org/regional admin Events page; see Recurring events above.

max_attendees enforcement used to be described here as a "soft hint, not enforced at RSVP-create time." That's no longer accurate: as of v0.65.17 it is enforced, via auto-waitlist rather than outright rejection — see Capacity caps above.

Tips​

  • Mark mandatory events as mandatory. This is the cleanest way to surface them on the dashboard and in compliance views.
  • Set a realistic max. It's enforced now — members past the cap get auto-waitlisted rather than blocked outright, so a tight number won't turn people away, it'll just queue them.
  • Use Other for things that don't fit. "Big-little reveal", "officer transition dinner", and "tailgate" are all reasonably "Social", but if you want them visually distinct, use Other and explain in the description.
  • Don't delete on cancellation. Cancel-with-reason preserves history; deletion erases it.
  • Pair big events with an Engage bulletin. The events page doesn't push; bulletins do.

Last verified against v0.65.23 (2026-07-05). End-time validation + RSVP cap enforcement shipped v0.63.17; RSVP waitlist with auto-promote, ICS calendar feeds shipped v0.65.17 (recurring events and conflict detection also shipped v0.65.17, admin/regional-admin only).