Services: WiFi, Maintenance, Support & Gate¶

Part of the Aashray Business Logic. Related: Accounts, Identity & Authentication.

This page covers the staff and member rules for campus WiFi, maintenance, support, and gate operations. WiFi staff manage access and code data. Maintenance and housekeeping staff manage work queues and cleaning records. Gate staff record entry and exit. Support has no staff queue in the current staff panel.

The staff panel is an operational tool, not a second rule engine. The backend still decides whether a request or scan succeeds. The staff panel adds review, status changes, reports, exports, and manual actions.

1. WiFi¶

Staff operation¶

WiFi staff and super admins have three areas:

Upload new temporary WiFi codes.
Review permanent WiFi code requests.
View temporary WiFi usage reports.

The same staff area also supports permanent-code exports, manual additions, and Excel-based bulk changes.

Temporary code pool¶

Staff upload an Excel file, preview the rows, and then update the WiFi database. Each uploaded password enters the temporary pool as an active, unused code. The backend ignores duplicate passwords and reports how many new rows it inserted and how many duplicates it ignored.

The temporary WiFi usage report supports these staff checks:

Used, unused, or all codes.
Room, flat, or all booking types.
A date range for non-active records.
Text search across the report.
Excel download of the displayed records.

The report shows the password, status, issue time, member name, mobile number, check-in date, and checkout date. The page starts with a seven-day date range. The date range does not filter active, unused codes.

In this report, active means an unused pool code and inactive means a code that a booking has used. The system does not show a staff approval step for temporary codes.

Permanent request queue¶

The permanent WiFi page lets staff filter requests by:

All records.
New requests with no code.
Reset requests from members. These records still hold the old code.
Approved records.
Rejected records.
Deleted records.

Each row includes the request ID, card number, member details, residency type, request and update times, username, SSID, code, and status. Staff can search the table and download the current list.

In the action window, staff can set a request to approved, rejected, or deleted (staff panel). The backend can also move a single approved record to reset and clear its code, but no staff panel button does this. Approval needs a permanent code when the record has no code. The backend stores a new code only when the record has none. Staff can also set the username, the network name (SRATRC or BACKOFFICE), and comments for the member.

When staff change a request, the backend records the reviewer and review time. The system sends a WhatsApp update for the request action. The message is sent in the background after the database update.

Manual and bulk permanent-code work¶

Staff can add an approved permanent code without a member request. The form looks up a card by mobile number and requires the card number, mobile number, SSID, and code. Staff can select a device type and generate a username. The new approved record also triggers a WhatsApp message.

The page supports two Excel actions:

Update changes existing records.
Insert adds new records.

Dry run is selected by default. A dry run shows the planned changes without writing them. A real update or insert asks for confirmation before it writes data.

Bulk files must contain a valid record ID and card number. The card must exist, and an update row must match the existing ID and card number. An approved row must contain a WiFi code. A blank username can be generated from the member name, card number, and device type.

An update writes the code, SSID, username, device type, and status from the sheet, and it can set any of the five statuses. A blank status means approved. If any row fails a check, nothing is written. An insert can add approved or pending records and skips an existing ID and card-number pair. Bulk status or code changes can queue WhatsApp messages.

Staff can also export approved permanent records for the router portal. The export can include all approved records, records reviewed in the last number of hours, or records reviewed between a start and end date. The file lists the account name, the code, a first name, the device (phone, tablet, laptop, or other), an alias, the email, and a network user group by member type:

Permanent Residents get the residents group.
Seva Kutir members get a one-year, one-device, unlimited-data group.
Mumukshus and guests get the non-resident group.

Member rules¶

Temporary access is only offered to Mumukshus and guests (member app and backend). Permanent Residents and Seva Kutir members do not see this option.
The member must be checked in to a room, flat, or Utsav booking that has not ended. Otherwise the backend refuses the code.
Each checked-in booking can get one temporary code. The backend gives the oldest unused code in the pool. When the pool is empty, it asks the member to try again later. The member app shows only the code for the current booking.
Permanent access is open to all member types. A Mumukshu or guest can have only one pending or approved request at a time (backend). For them, the member app requests a mobile-device code and shows the request button only when they have no request or only rejected ones.
Permanent Residents and Seva Kutir members choose the device (mobile, laptop, tablet, or other) and can request another code at any time. Nothing limits them to one code per device.
The backend makes the username from the first and last name, the last four digits of the card number, and a short device code. It adds a number when that username is taken.
The member app shows each request except deleted ones. A pending request shows an expected approval date seven days after the request. A rejected request shows the staff comments. An approved request shows the code, username, and network name.
A member can ask to reset an approved code. The record becomes reset and keeps the old code until staff act.

WiFi messages¶

Every WiFi message goes to the member by WhatsApp, with the member's name and the device type (backend). No message includes the code.

Event	Message	Recipient
A member asks for a permanent code, or the Excel update sets a record to pending	Request received	Member
Staff approve a request, add a code by hand, or approve through Excel	Approved, with two app download links. The links differ for Permanent Residents.	Member
Staff reject a request	Rejected	Member
A member resets a code, or the Excel update sets a record to reset	Reset	Member
Staff delete a record	Deleted	Member
Fewer than 50 unused temporary codes remain at a 30-minute check	The number of codes left. It is sent once until the pool goes back to 50 or more.	One fixed staff number

The Excel update and insert send a message only for rows whose status or code changed. Issuing a temporary code sends no message.

What WiFi does not enforce¶

The member app describes permanent access as valid for one year and temporary access as valid for two weeks with a data limit. Aashray does not track or enforce either limit. A code keeps working until staff or the network equipment changes it.

2. Maintenance and housekeeping¶

Staff operation¶

The staff panel separates requests into three department queues:

General maintenance.
Housekeeping.
Electrical.

The maintenance menu with all three queues is visible to super admins. Each department role's home link opens its own queue. The queue page and the backend accept any of the three department roles, so they do not stop one department from opening another department's queue.

Maintenance request queue¶

The department page shows the requester, mobile number, creation time, department, work area, work detail, comments, closed time, and status. The queue orders open requests first, in-progress requests second, and closed requests last. Newer requests come first within the same status.

Staff can search the queue and open an update page for a request. The update page changes the status and comments. The supported status flow is:

open -> in progress -> closed

The backend sends a WhatsApp message when a request changes to closed and the requester has a mobile number. The message includes the requester name, work area, and work detail. The staff panel has no assignee, due date, service-level timer, or staff reply thread for a maintenance request.

Housekeeping deep-cleaning tracker¶

Deep cleaning is a staff schedule for flats. It is separate from a member-filed maintenance request.

Housekeeping staff can:

Search by flat number or owner name.
View all, cleaned, due soon, and overdue flats.
Select several flats and mark them cleaned together.
Mark one flat cleaned.
Change a flat's cleaning interval to a positive number of days.
View the cleaning date and staff member in the history.
Export the filtered tracker to Excel.

The next due date is the last cleaning date plus the flat's interval. A flat with no recorded cleaning is overdue. A flat due within ten days is due soon. Other flats show as cleaned.

Marking a flat cleaned sets the latest cleaning date and adds a history entry with the staff username. The backend keeps the latest 50 history entries. The system sends a WhatsApp message to each owner of the cleaned flat who is on a fixed list of recipients and has a mobile number. The message uses the maintenance-closed wording, with the flat number as the work area and "Deep Cleaning" as the work. The tracker shows only the owners on that list. The backend returns the send results to the staff panel.

Utsav extra-bedding report¶

The housekeeping page links to an Utsav-specific extra-bedding report. Housekeeping staff, super admins, and Utsav staff can load it (backend). Staff select an Utsav from the list of all Utsavs, search the report, and choose all sections, inside Research Centre rooms, or resident flats.

The report gives three totals:

Extra floor beds for Research Centre rooms.
Extra beddings for resident flats.
The combined total.

The room section shows the room, building, floor, base bed capacity, extra floor beds, total bed capacity, room gender, and housekeeping notes. The flat section shows the flat, owner or host, mobile number, extra beddings, and remarks. Staff can download an Excel workbook with room, flat, and summary sheets or print a checklist.

This report is a read and export checklist. It does not assign beds or update a booking.

Requesting maintenance¶

Permanent Residents and Seva Kutir residents can file a maintenance request at any time.
Other members need a room booking that is checked in. The check does not look at the booking dates (backend).
The current eligibility check recognizes only a room-based check-in.
A member staying only in a flat or attending only an Utsav cannot file a maintenance request through the current member flow.
A member selects the department (electrical, housekeeping, or maintenance), describes the problem, and gives the work area. The member app requires all three. The backend refuses a department it does not know.
After the request is saved, the member gets a confirmation email with the mobile number, details, and work area. The email is copied to the department's email address. The member also gets a WhatsApp message with the department, work area, and details.
No staff member gets a push or WhatsApp alert. The department learns of a new request from the email copy or from its queue.
A member can view their request history, 10 at a time, newest first. The filters are all, open, and closed. An in-progress request appears only under all. The member app does not show staff comments.

Maintenance limitations¶

The staff panel can see flat deep-cleaning work, but the member eligibility check does not recognize flat check-in. The staff panel also has no support-style inbox, assignment record, due date, or service-level timer.

3. Support¶

Staff operation¶

The current staff panel has no support area. There is no staff list, status board, assignment flow, reply screen, or support report for member support tickets.

Member submission¶

A member can choose booking, payment, WiFi, or other, then submit a free-text description of at least 10 characters (member app). The member app confirms that it recorded the ticket. The backend stores the ticket. Its staff email is switched off, so no one is told about it. The system does not guarantee that staff can see or act on it.

This is the largest operational gap on this page. A support ticket is stored as a member action without a staff workflow.

4. Gate¶

Staff operation¶

Gate staff and super admins have these tools:

Camera-based QR check-in.
Camera-based QR check-out.
Card-number or tap-reader check-in.
Card-number or tap-reader check-out.
A full gate-record report.
A current on-premise report.

Entry and exit scans¶

Each successful scan needs a known card number. The backend writes a gate record with the card number, on-premise or off-premise status, scan time, and staff username. It also updates the card's current on-site status. A repeat scan in the same direction still adds a record; the backend does not block it.

The camera pages accept a card number or a card QR value (the card number with its standard prefix). The tap pages accept the card number from the reader or input field.

If the gate device loses the network, the page stores the scan with its original scan time in a local queue. Entry and exit use separate queues. The page shows the network state and pending count, then syncs queued scans when the connection returns or when staff select Sync Now. A duplicate scan for the same card is blocked for five minutes while it remains in the local queue.

If a queued scan gets a non-network error during sync, the page removes it from the queue. The result banner for every scan and sync, including an error, clears after about one and a half seconds. Staff must check the gate report for rejected or unknown cards.

How scans connect to stays¶

An entry scan checks in that card's room or flat booking that is confirmed and waiting for check-in, when its arrival date is today. A booking that still waits for payment is not checked in. An exit scan changes the card to off-premise and checks out a checked-in flat stay when its checkout date is today or earlier. These automatic changes send no message.

Room and flat behavior is not symmetric:

Entry can check in one room booking and one flat booking.
Exit checks out an eligible flat stay.
Exit does not auto-check out a room stay.

A room stay can therefore remain checked in after the member leaves until staff corrects it through the booking workflow.

Gate reports¶

The Gate Records page lists all entry and exit records newest first. Staff can search the card number, name, mobile number, status, and record time. The page does not provide a gate-record correction action.

The current on-premise report groups cards with current on-premise status by:

Permanent Resident.
Guest.
Mumukshu.
Seva Kutir.

Each group links to a list with the card number, name, mobile number, latest entry time, latest exit time, and gate history. Staff can open the history for a card to see each on-premise or off-premise record and the staff username that recorded it.

The on-premise count comes from the card's current status. A missed scan or stale room status can make the report differ from the people physically on site.

Member rules¶

Members carry the identity card or show the card QR code from the member app (see Accounts, Identity & Authentication). Gate state is also read by services that need current on-site status, such as temporary WiFi and maintenance eligibility.

The gate does not send a member notification after an entry or exit scan.

5. Contact information¶

The member app has a contact page with phone numbers grouped by service (member app):

Room and Adhyayan questions, payment support, and WiFi support: the Research Centre office.
Food services: the kitchen office.
Travel, events and programs, maintenance, Smilestones, and Satshrut: named staff members.

A tap starts a call. A long press copies the number. The page asks members to call during business hours, 9:30 AM to 5:30 PM. The maintenance request email and the room cancellation email also give two office numbers.

How this connects to other domains¶

Accounts, Identity & Authentication (02): all four services use the member identity card. Member type controls WiFi and maintenance eligibility. Gate status controls the current on-site count.
Bookings & check-in: temporary WiFi and maintenance use current check-in state. Gate entry can create checked-in state for today's pending room or flat stay. Permanent WiFi uses staff approval instead.
Notifications: WiFi actions, a new maintenance request, and maintenance closure send WhatsApp messages. A new maintenance request also sends an email. A low temporary-code pool alerts one staff number. Gate scans and support submissions do not send a member notification.
Utsav and housekeeping: the extra-bedding report combines Utsav demand with Research Centre room data and resident-flat requests.

Known limitations today¶

WiFi validity periods and data limits are not tracked by Aashray.
Temporary WiFi code status uses active and inactive records, not a separate expiry state.
Maintenance eligibility recognizes room check-in but not flat or Utsav presence.
Maintenance has no assignee, due date, service-level timer, or reply thread.
Support tickets have no staff-facing review, status, assignment, or reply mechanism.
Gate entry and exit are asymmetric for room stays.
Gate reports show current card status and history, but they do not correct a missed or stale scan.
Offline gate sync can remove a queued scan after a non-network error. The result banner clears after about one and a half seconds, so staff must check the gate report.
Approving a member's WiFi reset request keeps the old code, even when staff type a new one. The backend stores a code only when the record has none. To give a new code, staff must use the Excel update, or delete the record and add a code by hand.
Permanent Residents and Seva Kutir members have no limit on permanent codes per device.
The member app's expected approval date for a permanent code is seven days after the request. Nothing enforces it.
Maintenance department roles are not separated. Any department role can open and update every department's queue.
Members cannot see staff comments on a maintenance request, and they have no filter for in-progress requests.
The contact page is fixed in the member app, so a staff or number change needs a new app release.