Skip to content

Notifications, Short-Links & App Updates

Part of the Aashray Business Logic. Related: Accounts, Identity & Auth, Booking Lifecycle & Engine, Services, WiFi, Maintenance, Support & Gate. For implementation detail — exact routes, database structure, and known code-level defects — see the companion Technical Reference — Notifications, Short-links & Config.

This covers how a member is reached outside of just using the app — notifications, email, and WhatsApp — plus two supporting features: short shareable links used for tutorials, and the app's ability to force an update.

The three ways members are notified

  • A member can be reached by a push notification on their phone, by email, and by a WhatsApp message. These are the three channels the system uses to reach someone outside the app itself.
  • Notifications go out at points like: a booking being created, a booking being confirmed, a booking being cancelled or refunded, a spot opening up on a waitlist, a forgotten-password request, a maintenance request update, and a WiFi access request update.
  • The same event often notifies a member through more than one channel at once — for example, a confirmed booking may trigger an email and a WhatsApp message, and sometimes a push notification as well.
  • When someone books or cancels on another member's behalf (for example, booking for a Mumukshu), both the person who acted and the person the booking is for can be notified.

Tapping a notification

  • Tapping a push notification can take the member straight to the relevant screen in the app — for example, straight to their bookings, or to a feedback form for a study session or festival they attended — rather than just opening the app to its home screen.
  • Staff can create short, easy-to-share links, grouped by department (accounts, rooms, cards, food, study sessions, travel, festivals, WiFi, and so on), that redirect to a fuller tutorial or resource page.
  • In the app, the Profile → Support screen uses these short links for its "how do I…" tutorial rows, with separate buttons for iPhone and Android instructions.
  • Staff can enable, disable, or delete these links, and see how many times each one has been opened.

Forcing an app update

  • The app can check whether a newer version is available. If staff have marked that version as required, the app is meant to require the member to update before continuing to use it, and to show them what's new in that version.
  • Today this only covers the app's version number — there's no broader system for turning individual features on or off for some members and not others.

Known limitations today

  • There's no way today to update a stale phone notification address. The address the system uses to push a notification to a member's phone is only refreshed when they log in. Someone who reinstalls the app, switches phones, or otherwise ends up on a new device without logging in again may simply stop receiving notifications until they do log in — and there's currently nothing that detects or corrects a notification that silently fails to reach a phone.
  • Some automated recipient lists are fixed and can only be changed by an engineer, not a staff member. A small number of automatic alerts — for example, who is told about low WiFi-code availability, or about a change in tomorrow's meal count — always go to the same one or two people, hardcoded in the system. There's no screen where staff can update who receives these.

Neither of these is something a member notices day-to-day, but both affect how reliably the right person hears about the right thing. Full engineering detail, and every other known defect, is tracked in the technical reference.