11 · Admin Panel Map (Staff-Side Overview)¶

Part of the Aashray Technical Reference. This file has no single business-logic pairing — it's a cross-cutting staff-side index spanning many domains. Related technical files: API Reference, Discrepancies. Related business-logic files: Accounts, Identity & Auth, Booking Lifecycle & Engine, Stay: Rooms & Flats, Food, Travel, Adhyayan & Utsav, Payments, Credits & Reconciliation, Services.

Scope¶

This file documents the staff-facing admin panel as a product: the counterpart to the member mobile app. Members book stays, meals, travel, and events in the Aashray app; staff run the centre through the admin panel, which is a separate repository (admin) of plain HTML/JS pages served as a static site. Every write the panel makes goes through the same backend (backend) as the app, under the /api/v1/admin/* route prefix, and mutates the same tables the member app reads — so an admin approval, assignment, cancel, or status change is immediately visible to the member. This document enumerates every admin module, every .html page, the backend route group it calls, the role(s) that gate it, and the effect on member-side state, then ends with a role → capability matrix and cross-domain links.

How the panel is built (shared shape across all modules)¶

Static HTML/JS. No framework. Each module is a folder under admin/ with an index.html menu and one page per task. jQuery + a few vendor scripts (plugin.js, bootstrap-datepicker, clockpicker, custom.js, config.js) and a shared styles.css.
Login is admin/index.html (titled "Welcome To Research Centre"). It POSTs to POST /api/v1/admin/auth/login, which returns a JWT + the user's role list. Token + roles are stored in sessionStorage; a "Forgot Password?" modal hits POST /api/v1/admin/auth/reset-password.
Home is admin/adminhome.html. It reads roles from sessionStorage and dynamically renders module buttons from a roleButtonMap — a user sees only the modules their roles unlock (multi-role users see the union). admin/office_index.html is a legacy office landing.
Client-side gate: every page calls checkRoleAccess([...allowedRoles]) from style/js/roleCheck.js. No token → redirect to login; valid admin but wrong page → alert + redirect to adminhome.html; no valid admin role → force logout. This is cosmetic only — the authoritative check is server-side (see RBAC below).
Common utility page: admin/common/shortLinks.html (short-link manager, shared by most modules).

Backend RBAC (authoritative)¶

Server-side auth lives in middleware/AdminAuth.js: - auth — verifies the Bearer JWT (SECRET, 24h expiry), loads the AdminUsers row, rejects deactivated accounts (status = 'inactive'), then loads the user's active AdminRoles into req.roles. - authorizeRoles(...roles) — passes if the user holds any one of the listed roles (OR semantics), else 401.

Data model (three tables): admin_users (username, bcrypt password, status active/inactive, optional cardno link to a member card) · roles (catalog of role names, active/inactive) · admin_roles (join: user_id × role_name × status — a user can hold many roles). Role names are string constants in config/constants.js (e.g. superAdmin, roomAdmin, foodAdmin…). Route files mount auth then authorizeRoles(...) at the router level (some, like food/utsav/short-links, gate individual routes more tightly). superAdmin is included in almost every route group and is the only role that can reach the Admin-Management (sudo) module.

Backend mount prefixes (app.js): sudo→/admin/sudo, auth→/admin/auth, adhyayan→/admin/adhyayan, card→/admin/card, food→/admin/food, gate→/admin/gate, room/flat→/admin/stay, travel→/admin/travel, accounts→/admin/accounts, maintenance→/admin/maintenance, booking-cancel→/admin/bookings, utsav→/admin/utsav (public + admin routers), avt→/admin/avt, wifi→/admin/wifi, coordinator→/api/v1/coordinator, short-links→/api/v1/short-links, redirect→/go/:slug.

Module: Admin Management (sudo)¶

What it is — Super-admin-only console for managing staff accounts and the role catalog. This is the RBAC control plane for the whole panel.

Screens / pages (admin/sudo/) - index.html — Admin Users List: searchable table of all admins, "Add New Admin User", per-user Reset Password modal. - createAdmin.html — create an admin (username, password, roles, optional cardno). - fetchAllAdmins.html / fetchAllAdmins.js — data source for the list. - activateAdmin.html / deactivateAdmin.html — flip an admin's account status. - updateAdminRoles.html — reassign a user's roles. - createRole.html / fetchRoles.html / deleteRole.html — role-catalog CRUD.

Backend routes — POST /admin/auth/create (create admin), POST /admin/auth/reset-password (public-ish, used by login modal too); /admin/sudo/*: GET fetch_all_admins, PUT update_roles, PUT deactivate/:username, PUT activate/:username, POST role/:name, GET role, DELETE role/:name.

RBAC — superAdmin only (both auth.routes create and the entire adminControls.routes router). Login/reset endpoints are reachable without a role.

Effect on member-side state — None directly on members; governs who can operate every other module. Creating/deactivating an admin and resetting passwords fire WhatsApp notices to the linked card holder (admin_account_created, admin_status_updated, admin_password_reset_notice). Deactivation immediately blocks that admin's JWT at auth.

Module: Account Management (accounts)¶

What it is — Finance back-office: transaction reporting, Razorpay settlement reconciliation, and mumukshu credit reporting.

Screens / pages (admin/account/) - index.html — menu. - voucherCreation.html — Completed Transaction Report. - pendingTransaction.html — Pending Transaction Report. - creditTransaction.html — Credited Transaction Report. - debitTransaction.html — Credits-Used (debit) Report. - settlementReport.html — settlement list (upload Razorpay settlement Excel). - settlementRecon.html — Settlement Reconciliation (update settlement fields from Excel). - settlementBreakdown.html — transactions grouped by settlement / payment id. - creditsReport.html — Mumukshu Credits Report.

Backend routes (/admin/accounts/) — GET fetchcompleted | fetchpending | fetchcredits | fetchdebits, POST setrep (upload settlement Excel), POST updateset (update from Excel), GET fetchset, GET fetchTransactions/:settlementId, GET fetchTransactions/payment/:razorpay_order_id, GET credits, GET fetchcreditstransactions.

RBAC — superAdmin, accountsAdmin, accountsAdminPra (PRA finance).

Effect on member-side state — Mostly read/reconcile; writes are to settlement records (Razorpay reconciliation), not to member bookings. Surfaces the transaction + credit ledgers that members see in-app (payments/credits). See 08 · Payments & Credits.

Module: Card Management (card)¶

What it is — The member/card registry: create and maintain the card_db identity records that every booking, credit balance, and login is keyed to.

Screens / pages (admin/card/) - index.html — search cards by name or mobile; list; links to add/report. - createCard.html — issue a new card (new member). - updateCard.html — edit card details; also transfer a card. - cardDetails.html — per-card detail incl. transactions. - creditsReport.html — credit balances report.

Backend routes (/admin/card/) — POST create, GET getAll, GET search/:name, GET by-mobile/:mobno, PUT update, PUT transfer, GET transactions/:cardno, POST reset-pwd (reset a member's app password to default).

RBAC — officeAdmin, superAdmin, cardAdmin, utsavAdmin, wifiAdmin, foodAdmin (broad, because many modules need to look up/create a card for walk-ins).

Effect on member-side state — High. Creates the member identity used across the whole app; transfer reassigns a card; reset-pwd changes a member's login password. Underpins 02 · Accounts & Cards.

Module: AVT Management (avt)¶

What it is — Read-only card lookup for the AVT team (search / browse the member registry; no writes).

Screens / pages (admin/avt/) — index.html (search cards by name, list all).

Backend routes (/admin/avt/) — GET getAll, GET search/:name.

RBAC — avtAdmin, superAdmin.

Effect on member-side state — None (read-only view over card_db). See 02 · Accounts & Cards.

Module: Room Management (room → `/admin/stay`)¶

What it is — Full staff control of room and flat stays: book on behalf of members, check-in/out, block inventory, manage the RC (Research-Centre-wide) block, and run occupancy/reservation reports.

Screens / pages (admin/room/) - index.html — menu. - roomBooking.html — New Room Booking (for a mumukshu). - flatBooking.html — New Flat Booking. - updateRoomBooking.html — edit an existing room booking. - fetchRoomBookingsByCard.html / fetchFlatBookingsByCard.html — look up a member's bookings. - fetchAllFlatBookings.html — all flat bookings. - manageRooms.html / updateRoom.html — room inventory; block/unblock/edit a room. - blockRC.html — Block / Unblock RC (centre-wide date blocks). - roomBooking.html, roomReports.html — reservation reports hub. - roomDetailReport.html / guestDetailReport.html — per-room / per-guest detail. - occupancyReport.html — occupancy. - dailyGuestCountReport.html — daily guest count / availability. - lateCheckOutFeeReport.html — late-checkout fees; revoke a fee.

Backend routes (/admin/stay/) — room: POST bookForMumukshu, PUT checkin/:bookingid, PUT checkout/:bookingid, PUT update_room_booking, PUT update_booking_status, GET room_list | available_rooms/:bookingid | available_rooms_for_day | fetch_room_bookings/:cardno. flat: POST bookFlat/:mobno, PUT flat_checkin/:id, PUT flat_checkout/:id, PUT flat_cancel/:id, GET flat_list | fetch_flat_bookings/:cardno, PUT update_flat_booking_status. inventory: PUT block_room/:roomno | unblock_room/:roomno | update_room/:roomno. RC: POST block_rc, PUT unblock_rc/:id, GET rc_block_list. reports: GET reservation_report | flat_reservation_report | daywise_report | occupancyReport | guestsByDateAndRoomtype | late-checkout-fees, PUT late-checkout-fees/revoke.

RBAC — officeAdmin, superAdmin, roomAdmin.

Effect on member-side state — High. Admin check-in/out and status/room updates change the booking the member sees in "Bookings"; RC blocks and room blocks remove availability from the member booking flow; admin creates bookings on a member's behalf; late-checkout-fee revocation adjusts what the member owes. See 03 · Stay Booking and 04 · Rooms & Flats.

Module: Booking Cancellation (bookings)¶

What it is — Admin-initiated cancellation of a member booking with refund/credit handling. Small dedicated route group (currently room-type).

Screens / pages — No dedicated folder; invoked from Room Management report/detail pages (the cancel action).

Backend routes (/admin/bookings/) — PUT cancel/:type/:bookingid.

RBAC — officeAdmin, superAdmin, roomAdmin.

Effect on member-side state — High and explicit. Sets the booking to STATUS_ADMIN_CANCELLED, runs adminCancelTransaction (refund/credit reversal), sends a WhatsApp room-status-change message and push notifications to both the guest and the booker ("Raj Sharan Booking Cancelled by Admin", deep-linked to /bookings). See 09 · Bookings Management & Cancellation and 08 · Payments & Credits.

Module: Adhyayan Management (adhyayan)¶

What it is — Manage study programs (shibirs): create/edit sessions, open/close registration, approve waitlists, book on behalf of members, mark attendance, and report.

Screens / pages (admin/adhyayan/) - index.html — menu. - createAdhyayan.html / updateAdhyayan.html / fetchAllAdhyayan.html — create / edit / edit-list of shibirs. - openCloseAdhyayan.html — activate/deactivate (open/close) a shibir. - adhyayanStatusUpdate.html — change a booking's status (confirm from waitlist / cancel). - adhyayanBookingslist.html — bookings + waitlist + pending list for a shibir. - adhyayanRegistration.html — admin creates a booking for a member. - adhyayanCentre.html — summary report hub; adhyayanReport.html?location=… — location-scoped report (Kolkata / Rajnandgaon / Dhule / Research Centre). - pgsReport.html — PGS report (fetchPGS). - adhyayanFeedback.html — read submitted feedback. - adhyayanAttendanceReport.html, adhyayanAttendanceScanMob.html (QR/scan), adhyayanAttendanceScanTap.html (NFC tap) — attendance capture + report.

Backend routes (/admin/adhyayan/) — POST create, GET fetchALLadhyayan | fetchPGS | fetchAdhyayan | fetch/:id | fetchList, PUT update/:id, GET waitlist/:id | pendinglist/:id | bookings, PUT status, PUT attendance/toggle, POST attendance/bulk-toggle, PUT :id/:activate, DELETE :id (soft-delete), GET feedback/:shibir_id, POST attendance/:shibir_id/:session_no/:cardno, GET attendance/report/:shibir_id | attendance/summary/:shibir_id, POST booking/admin, POST attendance/create.

RBAC — officeAdmin, adhyayanAdmin, superAdmin, adhyayanAdminDhu, adhyayanAdminRaj, adhyayanAdminKol (location-scoped), accountsAdmin, accountsAdminPra, adhyayanAdminReadOnly (report-only), utsavAdmin. Home menu shows location-only admins just their location's report; read-only admin sees only the RC report.

Effect on member-side state — High. Status update approves a member off the waitlist or cancels their seat; admin booking creates a seat for a member; open/close controls whether members can register; soft-delete removes a shibir from the app; attendance affects a member's participation record. See 07 · Events (Adhyayan & Utsav).

Module: Utsav Management (utsav)¶

What it is — Manage festivals (utsavs) and their packages: create/edit, open/close, admin bookings, check-in (incl. a public scanner), volunteer views, room-number assignment, plate issue, and reports.

Screens / pages (admin/utsav/) - index.html — menu. - createUtsav.html / updateUtsav.html / fetchAllUtsav.html — utsav CRUD + edit-list. - createPackage.html / updatePackage.html / fetchAllPackage.html — package CRUD. - utsavCentre.html — summary hub; utsavReport.html?location=… — location report; utsavStatusUpdate.html — booking status change. - utsavRegistration.html — admin books a member into an utsav. - utsavBookingslist.html — bookings list; utsavVolunteers.html — volunteer bookings/options. - utsavCheckin.html + utsavCheckinReport.html + issuePlateScanUtsav.html — check-in and plate-issue scanning. - roomOccupancy.html + uploadRoomNo.html — pre/post-event room occupancy; upload/assign room numbers (Excel). - fetchUtsavFeedbacks.html — read feedback.

RBAC — protected router: utsavAdmin, superAdmin, accountsAdminPra, accountsAdmin, utsavAdminReadOnly (report-only), utsavAdminRaj (Rajnandgaon report). POST /booking is further restricted to utsavAdmin, superAdmin, accountsAdminPra, accountsAdmin (read-only roles excluded). Check-in/issue-plate routes are unauthenticated by design for kiosk use.

Effect on member-side state — High. Booking/status changes confirm or cancel a member's utsav registration; activate controls registration availability; room-number upload assigns the member their stay; check-in + plate issue mark attendance/meal entitlement. See 07 · Events (Adhyayan & Utsav) and 05 · Food (plate issue).

Module: Food Management (food)¶

What it is — Kitchen and meal operations: issue plates (manual + scanner + bulk), manage member and guest food bookings, bulk booking, menu management, physical-plate ("K1 Kitchen Count") tracking, and reports.

Screens / pages (admin/food/) - index.html — menu. - issuePlate.html / issuePlateScan.html — issue a plate manually / by scanner. - manageFood.html — manage member food bookings; manageBulkFood.html — manage guest/bulk food bookings. - plateCount.html — physical plates issued ("K1 Kitchen Count"); mealCount.html — meal count by mobile. - foodReport.html — food reports; issuedPlateReport.html / issuedGuestPlateReport.html — issued-plate reports. - fetchMenu.html / addMenu.html / updateMenu.html — menu CRUD.

RBAC — food-admin group: superAdmin, foodAdmin, smilesAdmin (Smilestones → bulk/guest food). Physical-plate group: superAdmin, foodAdmin, foodPlateAdmin. (smilesAdmin home button goes straight to manageBulkFood.html; foodPlateAdmin home button goes to plateCount.html.)

Effect on member-side state — High. Booking/cancelling meals changes the member's meal schedule and credit charge; issuing a plate marks the meal consumed; menu edits change what members can book. See 05 · Food.

Module: Gate Management (gate)¶

What it is — Physical gate entry/exit control and live on-premise headcount by category.

Screens / pages (admin/gate/) - index.html — menu. - gateIn.html / gateInTap.html — record entry (scanner / NFC tap). - gateOut.html / gateOutTap.html — record exit (scanner / NFC tap). - gateReport.html — gate history. - onPremise.html — currently on-premise dashboard, drilling into: totalGuest.html, totalMumukshu.html, totalPR.html, totalSeva.html (Seva Kutir).

RBAC — gateAdmin, superAdmin. (Gate admin's home shows only Gate Management, no short-link button.)

Effect on member-side state — Low member-visibility; records entry/exit against a card and feeds live counts. Cross-references 02 · Accounts & Cards and 09 · Services.

Module: Travel Management (travel)¶

What it is — Manage travel bookings and status, build bus groups, assign passengers, appoint bus coordinators, and provide a driver view and an OTP-authenticated coordinator app.

Screens / pages (admin/travel/) - index.html — menu. - fetchUpcomingBookings.html — upcoming travel bookings. - updateBookingStatus.html — change a travel booking's status; updateTransactionStatus.html — mark payment/transaction status. - travelBusManagement.html — create/edit bus groups, assign/remove passengers, set capacity, bulk-assign & bulk-upload, export; travelBusDetails.html — group detail. - fetchBookingsForDriver.html — driver's passenger list. - coordinatorLogin.html → coordinatorDashboard.html — OTP login + coordinator dashboard (boarding status).

RBAC — admin routes: travelAdmin, superAdmin, travelAdminDri (DRI travel; home button = driver bookings only). Coordinator routes: no admin role — phone-OTP session for the appointed bus coordinator.

Effect on member-side state — High. Status/transaction updates change what the member sees for their travel booking and payment; bus assignment tells the member their bus/seat; coordinator boarding-status updates the passenger's boarding state. See 06 · Travel.

Module: Maintenance & Housekeeping (maintenance, housekeeping)¶

What it is — Facilities: triage member-raised maintenance requests by department, plus a housekeeping deep-cleaning tracker.

Screens / pages - admin/maintenance/index.html — department picker (links to maintenance.html?department=maintenance|housekeeping|electrical). - admin/maintenance/maintenance.html — department-scoped request queue. - admin/maintenance/updateRequest.html — update a request's status (Open → In-Progress → Closed). - admin/housekeeping/index.html — deep-cleaning tracker (status table, "Mark Cleaned", "Edit Interval Days", export).

Backend routes (/admin/maintenance/) — GET fetch/:department, PUT update; housekeeping: GET housekeeping/deep-cleaning/status, POST housekeeping/deep-cleaning/done, POST housekeeping/deep-cleaning/interval.

RBAC — superAdmin, maintenanceAdmin, housekeepingAdmin, electricalAdmin. Each department admin's home button deep-links to that department's queue.

Effect on member-side state — Updates the status of a maintenance ticket the member filed from the app (status visible in-app). See 09 · Services.

Module: WiFi Management (wifi)¶

What it is — Provision WiFi access: upload temporary code batches, manage permanent-code requests (approve/reject), and report usage.

Screens / pages (admin/wifi/) - index.html — menu. - uploadCodes.html — upload new temporary codes (Excel). - wifiReport.html — temporary code usage report. - permanentCodeRequests.html — review member permanent-code requests (approve/reject, manual add, portal export).

RBAC — superAdmin, wifiAdmin.

Effect on member-side state — Direct. Approving a permanent-code request grants the member WiFi credentials shown in the app; uploaded temporary codes are what members receive. See 09 · Services.

Module: Short-Link Management (common)¶

What it is — Cross-module utility to mint branded short links (/go/:slug) that redirect to any URL; each link is typed by domain and gated to that domain's admins.

Screens / pages — admin/common/shortLinks.html (linked from most module homes as "Short Link Management").

Backend routes — POST /api/v1/short-links/ (create), GET /api/v1/short-links/:type (list by type), PUT /:id, DELETE /:id; public redirect GET /go/:slug (increments click_count).

RBAC — Route-level gate: any of superAdmin, accountsAdmin, roomAdmin, cardAdmin, officeAdmin, foodAdmin, adhyayanAdmin, travelAdmin, utsavAdmin, avtAdmin, wifiAdmin. Fine-grained per-link type is enforced in the controller via TYPE_ROLE_MAP (e.g. room → superAdmin+roomAdmin, food → superAdmin+foodAdmin, etc.) — you can only create/edit/delete links of a type your role owns.

Effect on member-side state — Indirect; short links are used in member communications (WhatsApp/notifications) to route users to app/web destinations.

Module: Location (support data)¶

What it is — Reference-data endpoints (countries/states/cities/centres) used by admin forms (e.g. card creation, address pickers). Mounted at both /api/v1/location and /api/v1/admin/location.

Backend routes — POST / (add), GET countries | states/:country | cities/:country/:state | centres. No authorizeRoles on this router (open reference data).

Effect on member-side state — None; shared lookup data.

Role → Capability Matrix¶

Roles are the string constants in config/constants.js. "✓" = that role can reach the module's write actions; "R" = read/report-only in practice.

Role (constant / name)	Modules it unlocks
`superAdmin`	Everything — sudo, accounts, card, food, gate, adhyayan, room/stay, travel, maintenance/housekeeping/electrical, avt, wifi, utsav, bookings-cancel, short-links
`officeAdmin`	adhyayan, card, room/stay + bookings-cancel, short-links
`accountsAdmin`	accounts, adhyayan, utsav (+utsav booking), short-links
`accountsAdminPra`	accounts, adhyayan, utsav (+utsav booking)
`roomAdmin`	room/stay, bookings-cancel, short-links
`cardAdmin`	card, short-links
`foodAdmin`	food (all) + physical plates, card lookup, short-links
`foodPlateAdmin`	food physical-plate group only (K1 Kitchen Count)
`smilesAdmin`	food-admin group (entry point = bulk/guest food)
`gateAdmin`	gate
`adhyayanAdmin`	adhyayan, short-links
`adhyayanAdminKol` / `…Raj` / `…Dhu`	adhyayan, but home = that location's report only
`adhyayanAdminReadOnly`	adhyayan reports (R)
`utsavAdmin`	utsav (+booking), card lookup, short-links
`utsavAdminRaj`	utsav, home = Rajnandgaon report
`utsavAdminReadOnly`	utsav reports (R), booking excluded
`travelAdmin`	travel (all), short-links
`travelAdminDri`	travel, home = driver bookings only
`maintenanceAdmin`	maintenance (maintenance dept)
`housekeepingAdmin`	maintenance/housekeeping + deep-cleaning tracker
`electricalAdmin`	maintenance (electrical dept)
`wifiAdmin`	wifi, card lookup, short-links
`avtAdmin`	avt (card lookup, R), short-links
(coordinator)	Not an admin role — OTP session for a bus coordinator via `/api/v1/coordinator`

Notes: authorization is OR across the listed roles per route (authorizeRoles); superAdmin appears in nearly every group; deactivated (status = inactive) accounts are blocked at auth regardless of roles; a user may hold multiple roles and the home page merges their menus.

How this connects to other domains¶

Members create demand; admins fulfil and gate it. App users book stays, meals, travel, events, and raise WiFi/maintenance requests; the corresponding admin module approves, assigns, checks-in/out, cancels, or changes status — writing to the same tables the app reads.
02 · Accounts & Cards — Card Management is the identity registry behind every booking and login; sudo governs staff identities; AVT/gate read the same card_db.
03 · Stay Booking / 04 · Rooms & Flats — Room Management + Booking-Cancel drive stay lifecycle (book-for-member, check-in/out, RC/room blocks, admin-cancel with refund + dual notifications).
05 · Food — Food Management (and Utsav's plate-issue) issue plates, manage bookings, and set menus that members book against.
06 · Travel — Travel Management + the coordinator OTP app move bookings through status, assign buses, and update boarding.
07 · Events (Adhyayan & Utsav) — Adhyayan and Utsav modules open/close registration, confirm waitlists, book for members, mark attendance/check-in, assign rooms.
08 · Payments & Credits — Account Management reconciles Razorpay settlements and reports the transaction/credit ledgers; admin cancels trigger refund/credit reversal (adminCancelTransaction).
09 · Services (WiFi / Maintenance / Gate) — WiFi provisioning, maintenance-ticket triage, and gate entry/exit.
12 · API Reference — full route/parameter detail for every /api/v1/admin/* endpoint referenced here.

Notable cross-cutting behaviours: many admin writes fire WhatsApp (admin account lifecycle, room status changes) and push notifications (booking cancel → guest + booker); some endpoints are intentionally public (utsav check-in / plate-issue kiosks; short-link redirect; location reference data); and client-side roleCheck.js gating is advisory only — the backend authorizeRoles middleware is the real boundary.