Skip to content

Adhyayan & Utsav (Study Sessions & Festivals)

Part of the Aashray Business Logic. Related: Booking Lifecycle, Food, Travel, Payments, Credits & Reconciliation, Notifications, Shortlinks & Config. For implementation detail — exact routes, database structure, and known code-level defects — see the companion Technical Reference — Adhyayan & Utsav.

Aashray runs two kinds of events for members: Raj Adhyayan, multi-day study sessions led by a speaker, and Raj Utsav, festivals sold as one or more dated ticket packages. Both are staff-created and staff-run: a session or festival exists — with its dates, price, and capacity already set — before any member ever sees it. A member's registration is a request that lands inside that already-configured, already-open event; it isn't what brings the event into being. For events held at the Research Centre, staff also track attendance or on-site logistics once people are registered, and collect feedback once the event ends. This file also briefly covers AVT management, a staff-only screen that happens to live next to these features in the admin panel but has nothing to do with events themselves.

The shared mechanics — seats, payments, cancellation, refunds and credits — work the same way described in Booking Lifecycle; this file covers only what's specific to study sessions and festivals.

Raj Adhyayan — study sessions

What it is

A study session ("Adhyayan") is led by a speaker (a Swadhyay Karta) over one or more days at a location — the Research Centre or elsewhere. A member can register a seat for themselves, for a guest, or for other mumukshus they're acting on behalf of. Registration may be free or paid; a free session is confirmed immediately, with no payment step. Members whose account type is "guest" can only register themselves — they can't register other guests or mumukshus on a session.

Setting up and running a session

Before a session is visible to any member, staff create it — setting the speaker, dates, location, price, and total number of seats — and it opens for registration by default.

  • Staff can open or close registration on a session at any time; while closed, every new registration goes straight to the waitlist regardless of seats remaining.
  • Staff can edit a session's total seats at any time, and — once attendance has started being recorded for it — can no longer change its length (number of days).

A member's request: browsing and registering

Once a session exists and is open, a member's registration is what actually claims a seat inside it, not what creates the session in the first place.

  • A member browses upcoming sessions (grouped by month) and opens a session to see the speaker, dates, location, price, and how many seats remain — the details staff set when they created it.
  • Registering opens a short form asking who the seat is for, then hands off to the normal booking and payment flow.
  • If seats remain and the session is open for registration, the seat is reserved right away (confirmed immediately if free, or held pending payment if not). If the session is full, or staff have closed registration, the registration instead joins a waitlist.
  • A member cannot hold more than one active registration (confirmed, waitlisted, or pending payment) for the same session.

Cancelling and the waitlist

  • A member cancels from their bookings. Cancelling a confirmed or pending-payment seat automatically promotes the oldest person on the waitlist into that seat.
  • Staff can also cancel or close out a session entirely. Doing so notifies every affected member, but — see Known limitations, below — it does not automatically cancel or refund their individual registrations.

Attendance during a session

For sessions held at the Research Centre, staff track attendance day by day. This happens two ways: scanning a member's card (by phone camera or a dedicated card-tap reader at the door), or a staff member manually marking someone present or absent, one at a time or in bulk. Only members whose registration is confirmed (including those who paid by cash) are eligible to be marked.

Staff can pull a per-person, per-session attendance report, and a per-session summary of how many attended versus were absent. A recurring assembly called "Param Gyaan Sabha," which is run as a study session under the hood, has its own dedicated report.

Feedback after a session

Once a member's session has fully ended, a short feedback survey becomes available to them — for a limited time afterward, and only once per person, and only for their own registration (not one they made on someone else's behalf). It asks about the speaker, the member's personal experience, and the food and stay, plus space for free-text suggestions.

Known limitation: the feedback window shown to a member on their bookings screen and the window the system actually enforces don't currently agree — see Known limitations, below.

Raj Utsav — festivals

What it is

A festival ("Utsav") is sold as one or more dated packages — each with its own start and end dates and its own price. A member picks a package when registering. Check-in and a few per-person logistics (arrival, own-car details, an optional volunteer role, room assignment) are tracked against the registration.

Setting up and running a festival

Before a festival is visible to any member, staff create it — setting its dates, location, registration deadline, and which meals it covers — then add one or more dated packages, each with its own price and a date window that must fall within the festival's own dates. A few packages can be set up as overlapping options for the same period of a festival; registering for one then blocks registering for a conflicting one. The festival opens for registration by default.

A festival stops being visible for browsing (and can no longer be opened by id) once its registration deadline has passed — including to members who already registered for it.

A member's request: browsing and registering

Once a festival exists and is open, a member's registration is what claims a place in it, not what brings it into being.

  • A member browses upcoming festivals (grouped by month, each showing its packages), and opens one to see package prices ("starting from ₹…"), remaining availability, and static event details like the daily schedule and guidelines — the details staff set when they created it.
  • Registering asks which package, whether the member is arriving by their own car (and, if so, the vehicle number), an optional volunteer role, and free-text notes — then hands off to the normal booking and payment flow. Registering as yourself for a festival always continues to an add-on selection step (for things like meals or travel), unlike a study session, where that step is skipped for off-campus sessions.

Seats and the waitlist

The seat and waitlist concept works the same way as a study session — if a package fills up, new registrations wait. Unlike a study session, however, cancelling a festival registration does not currently free the seat to the next waitlisted person automatically — see Known limitations, below.

Arrival, volunteering, check-in and rooms

For festivals held at the Research Centre, meals are automatically arranged for the dates covered by a member's chosen package. On the day, gate staff can check a member in and issue a physical meal plate using simple on-site tools that don't require signing in as an admin. Separately, staff assign rooms — individually or in bulk from a spreadsheet — and can pull a report of who is staying around the festival dates.

Feedback after a festival

The same concept applies as for a study session: a short survey (six required questions, no skipping) becomes available once per person after the festival ends, for a limited time. Staff can review submitted responses in a feedback report.

Known limitation: the same kind of mismatch exists here between the visible feedback window and the enforced one, and it's more pronounced for longer festivals — see Known limitations, below.

This is a staff-only screen for browsing and searching the full list of member cards and viewing a member's photo. It isn't an event feature and has no connection to registrations or bookings — it's grouped here only because it sits next to Adhyayan and Utsav in the staff admin panel. The photo view has a light protection (disabling right-click, drag, and text selection) to discourage casual copying, though it's a deterrent rather than a real safeguard.

Known limitations today

A few of the rules described above don't fully hold in practice yet:

  • Cancelling or closing a study session doesn't clean up its bookings. Staff can cancel a whole session, and every affected member is notified, but their individual registrations are not automatically cancelled or refunded — that has to be handled separately today.
  • Long study sessions can look like they have incomplete attendance. An older reporting format can only display a limited number of sessions; for a long study session, the extra days are still being tracked but don't show up in that older view.
  • The visible feedback window and the actual eligibility window don't currently agree, for both study sessions and festivals — a member can sometimes see the "Give Feedback" option after they're no longer eligible, or lose eligibility while the option is still showing. This is more pronounced for longer festivals.
  • Cancelling a festival registration doesn't free the seat to the next waitlisted person, the way cancelling a study-session registration does.
  • The "overall rating" column in the festival feedback report staff see is always blank, due to a labeling mismatch between one of the survey questions and how the report reads it.
  • Paging through the list of upcoming festivals can occasionally show overlapping or skipped entries.
  • Festival check-in and meal-plate issuing at the gate don't require a staff login. This is convenient for volunteers running the gate, but it also means anyone who can reach those tools could check a member in or issue a plate without any admin authentication.

None of these is something a member is likely to notice day-to-day except the feedback-window mismatch. Full engineering detail, and every other known defect, is tracked in the technical reference.

How this connects to other domains

  • Booking Lifecycle (03): seat reservation, payment, cancellation, refunds, and credits for both study sessions and festivals all run through the shared booking engine described there.
  • Food (05): a Research-Centre festival automatically arranges meals for its dates; a study session instead just carries a simple "food included" flag.
  • Travel (06): registering for a festival asks whether a member is arriving by their own car; separately, whether someone is "leaving right after a study session ends" is a self-reported travel-planning question tied to Adhyayan (today it isn't checked against the member's actual registration — see Travel's own planned changes).
  • Payments, Credits & Reconciliation (08): fees for sessions and packages, refunds, and staff-issued credits on cancellation all follow the rules described there.
  • Notifications, Shortlinks & Config (10): registration, cancellation, and status changes trigger push, email, and WhatsApp notifications to the member and, if registered on their behalf, to whoever registered them.