Status Vocabulary, Roles & Scheduled Jobs — Technical Reference

Part of the Aashray Technical Reference. Pairs with Business Logic — Status & Scheduled Jobs, which describes these states and checks in plain terms with no code detail.

This file is 100% derived from reading the backend source on main — the authoritative list of every status/type/role constant (backend/config/constants.js) and every scheduled job (backend/cron.js). This is the literal vocabulary the whole system speaks. Values are quoted verbatim.

Verification status: audited & anchored per docs/DOCS-METHODOLOGY.md on 2026-07-07 against aashray-backend main. Every constant below was confirmed line-by-line in config/constants.js and every cron job in cron.js. One correction this pass: the transaction-status column is status, not paymentStatus (§2 note + discrepancy #3).

---

1. Booking status constants

Constant	Value	Meaning / who sets it
STATUS_WAITING	waiting	Waitlisted (event full/closed at booking).
STATUS_CONFIRMED	confirmed	Secured booking.
STATUS_AWAITING_CONFIRMATION	awaiting confirmation	Pending an admin/coordinator confirm.
STATUS_PENDING / STATUS_PAYMENT_PENDING	pending	Created, awaiting (usually) online payment.
STATUS_PROCEED_FOR_PAYMENT	proceed for payment	Ready to pay.
STATUS_CANCELLED	cancelled	Cancelled by the member.
STATUS_ADMIN_CANCELLED	admin cancelled	Cancelled by staff or by the 24h auto-cancel cron (see §6).
STATUS_SEATSFULL_CANCELLED	seats full cancel	Auto-cancel because seats filled.
STATUS_WRONGFORM_CANCELLED	wrong form cancel	Cancel due to a wrong form.
STATUS_REJECTED	rejected	Rejected (e.g., wifi/permanent request).
STATUS_APPROVED	approved	Approved (e.g., wifi permanent).
STATUS_RESET	reset	Reset in progress (wifi).
STATUS_ACTIVE / STATUS_INACTIVE	active / inactive	Generic active flags (also admin-account status).
STATUS_AVAILABLE / STATUS_TAKEN	available / taken	Seat/slot availability.
STATUS_OPEN / STATUS_CLOSED	open / closed	Event open/closed for registration.
STATUS_INPROGRESS	in progress	e.g., maintenance.
STATUS_DELETED	deleted	Soft delete.

Room-specific: ROOM_WL = WL (waitlist), ROOM_STATUS_PENDING_CHECKIN = pending checkin, ROOM_STATUS_CHECKEDIN = checkedin, ROOM_STATUS_CHECKEDOUT = checkedout, ROOM_STATUS_AVAILABLE = available, ROOM_BLOCKED = blocked; label ROOM_DETAIL = Room Booking. [src: config/constants.js:68-74]

STATUS_SEATSFULL_CANCELLED (seats full cancel) and STATUS_WRONGFORM_CANCELLED (wrong form cancel) are defined here but are not valid values of the travel_db.status ENUM — see Travel — Discrepancies #2 for how that plays out in practice (writes fall back to admin cancelled + an admin_comments code).

2. Transaction / payment status constants

Constant	Value	Meaning
STATUS_PAYMENT_PENDING	pending	Online payment due (24h window).
STATUS_CASH_PENDING	cash pending	Pay at desk; never auto-expires.
STATUS_CASH_COMPLETED	cash completed	Paid in cash.
STATUS_PAYMENT_COMPLETED	completed	Paid.
STATUS_PAYMENT_AUTHORIZED	authorized	Razorpay authorized.
STATUS_PAYMENT_CAPTURED	captured	Razorpay captured.
STATUS_PAYMENT_FAILED	failed	Payment failed.
STATUS_CREDITED	credited	Refunded as store credit (cancel of a paid booking).
STATUS_AWAITING_REFUND	awaiting refund	Refund pending.

How these map to the user-facing app labels ("Paid", "Payment Due", "Credited", "Payment Cancelled") is documented in the app's own status/transaction-system section.

Note: STATUS_PAYMENT_PENDING is the same constant name used in §1 for a booking-level pending status and here for the transaction-level pending status. Both happen to resolve to the literal string 'pending', but they're written to different tables — a booking's own *_db.status column vs the transactions.status column. (Both columns are literally named status; the transactions table has no paymentStatus column.) Grepping for STATUS_PAYMENT_PENDING alone doesn't tell you which table a given usage touches. [src: models/transactions.model.js:57,81]

3. Type constants

Booking/transaction types: expense, refund; room, flat, food, breakfast, lunch, dinner, travel, adhyayan, utsav. Payment methods: upi, cash, razorpay_callback. Travel: Regular, full. Premises: onprem / offprem. User classes: PR, MUMUKSHU, SEVA KUTIR, GUEST. Constant RESEARCH_CENTRE = 'Research Centre' (the location that flips many rules — see Travel). FEEDBACK_ELIGIBILITY_HOUR = 13 — feedback opens from 1 PM on the eligibility day. [src: config/constants.js:1-19,59-64,78-79]

4. Real prices (backend constants — authoritative)

BREAKFAST_PRICE = 60      LUNCH_PRICE = 120      DINNER_PRICE = 120
NAC_ROOM_PRICE  = 700     AC_ROOM_PRICE = 1100

Discrepancy — stale app-side price constants. The app's own src/constants/prices.js holds a different, unused set of values (NAC 400 / AC 600 / travel 315 / breakfast 120 / lunch 80 / dinner 50). The backend's config/constants.js values above are the ones actually used server-side by validate/charge logic; the app file is confirmed dead code — it is exported but imported nowhere in aashray-app/src, and should be removed to avoid someone trusting it by mistake. AMT_TYPE_LATE_CHECKOUT_ROOM = 'late_checkout_room' is an extra late-checkout charge type layered on top of the room price. [src: aashray-app/src/constants/prices.js:1-6 (unused); aashray-backend/config/constants.js:65]

5. Admin RBAC role constants (full catalog)

Admin routes are gated by authorizeRoles(...) (a request passes if the user holds any listed role). Roles (config/constants.js) [src: config/constants.js:82-107]:

Role value	Area
superAdmin	Everything
officeAdmin	General office
roomAdmin	Rooms/flats/stay
cardAdmin	Cards & accounts
adhyayanAdmin (+ adhyayanAdminKol, adhyayanAdminRaj, adhyayanAdminDhu, adhyayanAdminReadOnly)	Adhyayan (centre-scoped variants + read-only)
utsavAdmin (+ utsavAdminRaj, utsavAdminReadOnly)	Utsav
foodAdmin, foodPlateAdmin	Food & plate issuing
travelAdmin (+ travelAdminDri)	Travel
accountsAdmin (+ accountsAdminPra)	Payments/settlements
gateAdmin	Gate
maintenanceAdmin, housekeepingAdmin, electricalAdmin	Maintenance (by department)
avtAdmin	AVT module
wifiAdmin	WiFi approvals
smilesAdmin	Smilestones

The role → capability mapping per screen is in Admin Panel Map.

6. Scheduled jobs (cron.js)

Job	Schedule	What it does
Auto-cancel unpaid (main)	every 30 min (*/30 * * * *)	Finds pending online transactions older than 24h (MAX_APP_PAYMENT_DURATION = 24*60 min) and cancels their bookings → status admin cancelled (actor = system user admin). Side effects per type: Adhyayan → openAdhyayanSeat (promote a waitlisted booking + create its attendance) then resetShibirAttendance on the cancelled; Utsav → cancelUtsavFoodBookings + openUtsavSeat; Travel → updateWaitingTravelBooking (promote a waiting passenger — see Travel — Discrepancies #4 on why this rarely fires); Food → cancelMeal. Then sends WhatsApp status-change messages (adhyayan/room/utsav/flat), per-member cancellation emails, and per-type "open booking" emails. [src: cron.js:38,43,49-51,170,184,196-197,202,211,219-224; cron.js:72 (cancelMeals)]
Meal count 9 PM	0 21 * * * (Asia/Kolkata)	sendTomorrowMealsCount to hardcoded recipient cards (0002849952, 0012754172, 0002823407). [src: cron.js:286,289-290]
Meal count 10 PM	0 22 * * * (IST)	checkAndSendMealsCountUpdate. [src: cron.js:300,303]
Meal count 11 PM	0 23 * * * (IST)	checkAndSendMealsCountUpdate. [src: cron.js:313,316]
WiFi low-code alert	every 30 min	If active WiFi codes < 50, send a low-stock WhatsApp alert once (de-duped until it recovers ≥50). [src: cron.js:330,345-351]

---

Edge cases & discrepancies

1. App price constants are stale/dead. See §4 above — the app ships a constants/prices.js that no longer matches what the backend actually charges. Any UI that renders a price without confirming it against the backend response risks showing the wrong number.
2. getUnpaidPastBookings is dead code. A routine to cancel past-dated unpaid room/flat bookings exists in the codebase but its call site (getUnpaidPastBookingsAndTransactions) is commented out. Only the 24h-online-payment cron (row 1 of §6) currently auto-cancels anything. Design implication: a booking the user thinks is "pending" silently becomes admin cancelled 24h after creation if unpaid — the app should surface this window clearly (it partly does via the Pay-Later notice and pending-payments timer). [src: cron.js:89 (commented call), 249,260-278 (defined, uninvoked)]
3. STATUS_PAYMENT_PENDING naming overlap. Same constant name, same literal value ('pending'), used for two different tables/concepts — the booking's own status column (§1) and the transactions.status column (§2). Both columns are named status; there is no paymentStatus column. See the note under §2. [src: models/transactions.model.js:57,81]
4. STATUS_SEATSFULL_CANCELLED / STATUS_WRONGFORM_CANCELLED are effectively legacy. Defined globally here (config/constants.js:48-49) but not valid ENUM values on travel_db.status (the only table that references these admin-comment-style reasons today); see Travel — Discrepancies #2 for the full mechanics of how a "seats full" or "wrong form" cancellation is actually recorded (admin cancelled + an admin_comments code). (The travel_db ENUM claim is verified in domain 06.) [src: config/constants.js:48-49]

---

How this connects to other domains (technical)

• Booking Lifecycle & Engine (business-logic file 03): every domain controller reads/writes the §1 status constants and the 24h auto-cancel cron (row 1 of §6) is the automated actor behind the "24-hour rule" described there.
• Payments, Credits & Reconciliation (business-logic file 08; technical companion): owns the transaction-status constants in §2, the Razorpay states, and how admin cancelled + issueCredits becomes a STATUS_CREDITED transaction.
• Travel (business / technical): consumes the travel-specific status ENUM (a subset of §1), the travelAdmin/travelAdminDri roles from §5, and is the clearest example of §6 row 1's per-type side effects (updateWaitingTravelBooking) and of §1's legacy-status discrepancy.
• Food, Stay — Rooms & Flats, Adhyayan & Utsav (business-logic files 05, 04, 07): each consumes the §1/§2 vocabulary and the meal-price / room-price constants in §4; the 24h cron's cancelMeal / openAdhyayanSeat / cancelUtsavFoodBookings side effects are per-type implementations of the same job.
• Admin Panel Map (11): the full role → screen mapping for every RBAC constant in §5.
• Accounts, Identity & Auth (business-logic file 02): staff accounts are granted the §5 role constants; that file describes the generic staff-permission model this file gives the literal role list for.