Skip to content

Operational Services, WiFi, Maintenance, Support & Gate

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

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 server 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 for an existing approved record.
  • 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.

For a request, staff can set the status to approved, rejected, reset, deleted, or pending. A reset action is valid only for an approved request. Approval needs a permanent code when the request has no code. Staff can also set the username, SSID, and admin comments.

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 can change the code, SSID, username, device type, and status. 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 use a number of hours or a start and end date. The filter uses the time when staff reviewed the permanent record.

Member rules

  • Temporary access is only offered to non-resident guests, including Mumukshus and Guests, who are currently checked in. Permanent Residents and Seva Kutir residents do not see this option.
  • A member who is not currently checked in cannot claim a temporary code.
  • Permanent access is open to all member types, but non-residents can have only one pending or approved request at a time.
  • Residents can have one approved permanent credential per device.

What WiFi does not enforce

The 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 is visible to super admins. Each department page also checks the related department role, so the relevant team can work in its own 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 WhatsApp alerts only to configured cleaning recipients who have a mobile number. It returns the send results to the staff panel.

Event extra-bedding report

The housekeeping page links to an event-specific extra-bedding report. Staff select an event or Utsav, 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 an active room stay that has been checked in.
  • The current eligibility check recognizes only a room-based check-in.
  • A member staying only in a flat or attending only a festival cannot file a maintenance request through the current member flow.
  • A member selects the department, describes the problem, and gives the work area.
  • A member can view their request history and filter it by status.

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 admin repository 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. The app confirms that it recorded the ticket. 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.

The camera pages accept a card number or a QR value that starts with cardnumber=. 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. Staff must check the result message and the gate report for rejected or unknown cards.

How scans connect to stays

An entry scan can change a pending room or flat stay for that card to checked in when the stay starts today. An exit scan changes the card to off-premise and checks out a flat stay when its checkout date is today or earlier.

Room and flat behavior is not symmetric:

  • Entry can check in one pending room stay and one pending flat stay.
  • 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 QR value used by gate staff. 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.

How this connects to other domains

  • Accounts & Identity (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 and maintenance closure can send WhatsApp messages. Gate scans and support submissions do not send a member notification.
  • Utsav and housekeeping: the extra-bedding report combines event 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 festival 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, so staff must check the result.