Operational Services — WiFi, Maintenance, Support & Gate¶
Part of the Aashray Business Logic. Related: Accounts, Identity & Auth. For implementation detail — exact routes, database structure, and known code-level defects — see the companion Technical Reference — Services.
This file covers four "everyday operations" services that hang off a member's identity rather than off a specific booking: campus WiFi access, maintenance requests, support tickets, and the physical gate that tracks who is on the premises. WiFi and maintenance both check whether a member is currently checked in before letting them use the service, and the gate is what actually creates that checked-in state in the first place. Each service below is described operational-side first — how staff actually review, triage, or run it — with the member's request framed as the trigger that feeds into that process, not the whole story. The one exception is Support, which today has no staff-facing operational side at all — that gap is the headline of its section, not a footnote.
1. WiFi¶
What it is¶
Two different kinds of WiFi access exist, and they work in opposite ways operationally: - Permanent access — a longer-term, per-device account with its own username and password, set up specifically for that member's device. This is staff-approved, not self-service: a member's request only starts a review, and nothing is issued until a staff member approves it. - Temporary access — an instantly-claimable, short-lived guest password drawn from a shared pool, with no review step at all. Limited to one active claim per stay.
How permanent access moves through staff review¶
A member's request for a permanent credential is just the trigger — staff must review and approve it before anything is issued. If an approved credential later needs to change (for example the member gets a new device, or forgets it), the member can ask staff to reset it, which sends the request back into that same staff review queue rather than starting a new one.
Who can request what¶
- Temporary access is only offered to non-resident guests (Mumukshus and Guests) who are currently checked in. Residents (Permanent Residents and Seva Kutir) don't see this option at all, and a member who isn't currently checked in can't claim one either.
- Permanent access is open to everyone, but the rules differ by member type: non-resident guests can only have one request pending or approved at a time, while residents are allowed to hold one approved permanent credential per device, since they may use more than one device.
What isn't actually enforced today¶
The app tells members that a permanent credential is "valid for 1 year" and a temporary one is "valid for 2 weeks with a data limit." In practice, neither limit is tracked or enforced by the system — a credential simply keeps working until a staff member manually resets, rejects, or deletes it. Any real expiry or data cap would have to be enforced by the network equipment itself, not by Aashray.
2. Maintenance¶
What it is¶
Maintenance is fundamentally a department-run triage process, not just a submission box: a member's request is only the trigger, and the real work is staff in the relevant department (electrical, housekeeping, or general maintenance) picking it up and working it through to resolution.
How staff triage and resolve a request¶
A request starts open, moves to in-progress while staff work on it, and is marked closed once resolved; the member is notified when that happens. Flats also have a separate, staff-only deep-cleaning schedule that isn't something a member requests at all — it's tracked and marked complete by housekeeping staff on their own, entirely apart from member-filed requests.
Requesting maintenance¶
A member can file a work request against a specific department, describing the problem and where it is. They can see a running history of their own requests and filter it by status.
Who can file: Permanent Residents and Seva Kutir residents can file a request at any time. Everyone else must currently have an active room stay that has been checked in. This eligibility check is the same one used elsewhere for check-in state — but today it only recognizes a room-based check-in. A member who is only staying in a flat, or who is only on-site for a festival, is not treated as checked in for this purpose, so they are told they can't file a request even though they are genuinely on the premises. This is a real gap, since the housekeeping side of maintenance also covers flats.
3. Support¶
What it is¶
Support is essentially write-only today: a member can raise a general issue, but there is no staff-facing way to see, track, or respond to it — no list, no status, and no reply channel exist. This is the most significant operational gap among the four services in this file.
Submitting a ticket¶
A member picks a topic (booking, payment, WiFi, or "other") and writes a free-text description. They get a confirmation that the ticket was recorded, but nothing today guarantees anyone at the centre will actually see or act on it.
4. Gate¶
What it is¶
Every member carries an identity card/QR code. Staff scan it when a member enters or leaves the premises. Each scan does two things: it logs the movement, and it updates whether that member currently counts as on-site — which is also what other services (like WiFi and maintenance) check when they ask "is this member checked in?"
How entry and exit connect to a stay¶
Scanning a member in at the gate is also meant to automatically mark the start of their room or flat stay (moving it from "expected" to "checked in") if that stay is due to start. Scanning a member out is meant to do the reverse for checkout.
In practice, entry and exit aren't handled the same way today. Entering the premises can automatically check a member into both a room stay and a flat stay. Leaving the premises only automatically checks a member out of a flat stay — a room-based stay is never automatically closed out at the gate. That means a room stay can keep showing as active even after the member has actually left, until a staff member notices and corrects it by hand.
Other uses¶
The gate also feeds live head-count dashboards showing how many members of each type (resident, guest, Mumukshu, Seva Kutir) are currently on the premises, plus each person's most recent entry and exit time.
How this connects to other domains¶
- Accounts & Identity (02): all four services are tied to a member's identity card; a member's type (Permanent Resident, Seva Kutir, Mumukshu, Guest) decides WiFi and maintenance eligibility, and a member's current on-site status is owned by the gate and read by the WiFi and maintenance checks.
- Bookings & check-in: WiFi (temporary) and maintenance both require an active, checked-in stay; the gate is what actually produces that checked-in state by scanning members in and out.
- Notifications: WiFi and maintenance activity trigger member notifications (request received, approved, rejected, closed); the gate and support do not notify anyone today.
Known limitations today¶
- The advertised validity period and data limit on WiFi credentials aren't actually tracked or enforced.
- Maintenance eligibility only recognizes room-based check-in, so flat and festival guests can be locked out of filing a request.
- Support tickets have no staff-facing review, status, or reply mechanism at all.
- Gate entry and exit aren't symmetric for room-based stays — only entry auto-checks-in a room; exit doesn't auto-check-it-out.
Full engineering detail, and every other known defect, is tracked in the technical reference — each of the four services has its own "Discrepancies" subsection there.