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.

Module-gated feature

Events live under Community → Events. The Community module must be enabled for your org or the nav item is hidden.

Who can use this

Available to: Chapter Officers and Chapter Presidents for create / edit / delete and check-in within their chapter; Org Admins for the same across every chapter; Regional Admins for chapters in their region; Members for viewing the calendar and RSVPing.

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, 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.

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 three-way RSVP summary (attending / maybe / not attending 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 used as a soft cap — 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 a hint, not a hard cap. The API does not reject the 26th "Attending" RSVP on a 25-cap event. It surfaces as a "Max 25" label on the card and an explicit count in the detail dialog. If you need a hard waitlist, manage it manually — sort by RSVP timestamp, ping the overflow members, ask them to move to Maybe or Not Attending.

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. There are no custom RSVP types ("going / volunteering / spectator"), no per-event custom fields (dietary preferences, t-shirt size, plus-ones), and no waitlist. If you need any of 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.

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.
• The three RSVP count cards (attending / maybe / not attending) — 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.

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.

Errors and edge cases

Symptom	Cause	What to do
"End time must be after start time."	You set end ≤ start.	Push end later.
Create button greyed out	Title, start, or end is empty.	Fill all required fields.
Cards show stale RSVP counts	React 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 visible	Event is cancelled.	Expected — uncancel if needed.
You see "Required" on a card you didn't expect	Someone toggled is_mandatory.	Open and edit, uncheck the toggle.
You see an "org-wide" event you can't edit	An org admin authored it without a chapter.	Officer permissions don't extend to org-wide events; ask the org admin to edit.

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 — RSVP statuses are fixed to attending / maybe / not_attending. 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.
• Hard capacity enforcement — max_attendees is a soft hint, not enforced at RSVP-create time.

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 even though it's not enforced — members read the number and self-throttle.
• 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.

Related

• Events & RSVPs (members) — what your members experience
• Module: Community — broader context
• Officer overview — full list of officer-accessible features

Last verified against v0.62.1 (2026-05-11).