Event eligibility as a rule, not a spreadsheet
Why we model who-can-register as a reusable audience over student memberships, and how one EXISTS join gates registration and previews counts.
Every club event starts with the same question: who is allowed to register? On most campuses the answer lives in a spreadsheet — a column of roll numbers, copied and pasted, out of date the moment a new batch joins.
We built eligibility as a rule instead.
Audiences over allowlists
A student holds memberships across departments and clubs, each with a year-of-study attribute. An audience is a reusable entity: a set of org units plus a year range. "CSE and Coding Club, years 2 to 3" is one audience, defined once and attached to as many events as you like.
That means eligibility is not three checkboxes copied around — it is a single named thing you can reuse, audit, and change in one place.
One join does the work
Because memberships and audiences are real tables, the gate is a single EXISTS
query. The same query:
- checks whether a given student may register, and
- previews the eligible count for organizers before they publish.
No export, no reconciliation, no stale roster. The rule is the source of truth.
Why it matters
Eligibility (who may attend) is kept separate from visibility (who can see the event). Treating them as different concerns keeps the model clean and the queries fast — and it means an organizer can scope an event to exactly the right students without ever touching a spreadsheet again.