Accounts, Identity & Authentication¶

Part of the Aashray Business Logic. Related: Booking Lifecycle & Engine, Travel, Payments, Credits & Reconciliation.

An identity in Aashray starts with staff, not with the member. Every card, the record that represents a person to the system, is issued and maintained by staff before the person it belongs to ever opens the member app; a member's own sign-in, profile edits, and onboarding only exist because staff already created that identity for them to step into. This document describes, in that order: how staff hold their own accounts and issue and manage member cards, how a member then operates day to day on top of a card staff already issued, how guests fit in, and where staff financial reporting and the location reference data sit as supporting material.

Who holds an identity¶

Three separate kinds of person interact with the system, and each proves who they are differently:

Members, sign in with their phone number and a password.
Staff, sign in to the web-based staff panel with a username and password, and are assigned one or more roles tied to their job.
Travel/bus coordinators, a special case: an ordinary member who has been designated to help run a specific bus group, who signs in with their phone number and a one-time code sent over WhatsApp rather than a password. This role is described fully in Travel.

A temporary access link (described under staff accounts below) is not an identity. It lends a read-only staff role to whoever holds the link.

Whichever kind of person it is, everything traces back to one underlying identity record. For a member, that record is a card, pre-issued by staff, carrying their name, gender, birth date, phone number, email, address, government ID details, home centre, profile photo, and a residency class (ordinary member, Permanent Resident, Seva Kutir volunteer, or guest). A card's number is the one identifier used everywhere a person shows up: bookings, payments, guest records, support tickets, and so on. There is no self-service sign-up, a member's phone number only works as a login because staff already put it on a card. The one exception is a guest card that the backend creates when a member books for a new guest (see Guests).

Staff accounts, and the cards staff issue¶

This is where a member's identity actually begins: staff hold their own accounts with roles that govern who is allowed to create or change a member's identity record, and card issuance is the process that turns a person into someone who can sign in at all.

Sign-in. Staff enter a username and password on the staff panel sign-in page. The backend refuses an unknown username, a wrong password, and a deactivated account (backend).
Session length. A staff sign-in lasts 24 hours. On every request the backend checks again that the account is still active, and it reloads the account's roles. A deactivation or a role change therefore takes effect on the next request (backend). The staff panel keeps the sign-in only in that browser tab. Logout clears it (staff panel).
No recognized role. If the account has no role that the staff panel recognizes, the panel shows "no valid role assigned" and does not open the staff home (staff panel).
Page access. Each staff panel page lists the roles that can open it. A staff member without one of those roles is sent back to the staff home. A temporary access link holder is sent to the sign-in page instead (staff panel).
Forgot password. The sign-in page has a "Forgot Password?" form that asks for a username and a new password. It needs no current password and no sign-in. The backend accepts it for any active account, and it requires at least 8 characters. It refuses a deactivated account. If the account is linked to a card, a WhatsApp notice goes to that card's phone (backend and staff panel). See Known limitations below.

The staff home shows one button for each area that the staff member's roles open. A staff member with several roles sees every button for each of their roles, with no duplicates (staff panel).

Role	Buttons on the staff home
super admin	Account, Admin, Card, Food, Gate, Adhyayan, Room, Travel, Maintenance, AVT, WiFi and Utsav management, Temporary Access Links, Short Link Management, Form Builder, WhatsApp Automation, Satshrut
office admin	Adhyayan, Card and Room management, WhatsApp Automation, Short Link Management, Form Builder
accounts admin, room admin, card admin, food admin, travel admin, AVT admin, WiFi admin	Their own management area, Short Link Management, Form Builder
Adhyayan admin, Utsav admin	Their own management area, WhatsApp Automation, Short Link Management, Form Builder
Adhyayan admin for Kolkata, Rajnandgaon, or Dhule	That centre's Adhyayan report
Utsav admin for the Rajnandgaon centre	The Rajnandgaon Utsav report
Adhyayan read-only role	The Research Centre Adhyayan report, WhatsApp Automation
Utsav read-only role	The Utsav report, WhatsApp Automation
gate admin	Gate Management
maintenance, housekeeping, or electrical admin	That department's request list
driver travel role	Driver bookings
Smilestones role (see Smilestones)	Bulk food booking
kitchen plate-count role	K1 kitchen count
Satshrut admin	Satshrut

Staff accounts and roles¶

Staff sign in to a separate web-based staff panel with a username and password. Every staff account is granted one or more roles matched to their job, for example, someone who handles card issuance, someone who manages rooms, someone who runs the accounts/finance desk, someone who manages travel, and so on for food, Adhyayan, Utsav, WiFi, maintenance, housekeeping, electrical, the gate, Satshrut, and AVT. Some of these roles are further narrowed to view-only access, or scoped to a single centre (for example, an Adhyayan coordinator who can only see bookings for their own centre).

Only a super admin can create new staff accounts, change what roles an existing staff account has, or manage the catalog of roles itself. A staff account can be deactivated (locking it out without deleting it) and later reactivated. The staff panel also provides a password reset action, but that action has no login check today.

Managing staff accounts and the role catalog¶

Only a super admin can use these screens and actions (backend and staff panel).

Staff list. The Admin Management screen lists every staff account with its number, username, linked card number, and status. Active accounts come first, then the list is sorted by username. A search box filters the table (backend and staff panel).
Create a staff account. The super admin enters a username, a password, the roles as comma-separated text, and an optional card number. The username must be unique, and each role must already exist in the role catalog (backend). There is no minimum password length when an account is created. If a card number is given, the account is linked to that card and a WhatsApp message goes to the card's phone (backend).
Activate or deactivate. One click on the staff list switches an account between active and inactive, with no confirmation step. A deactivated account cannot sign in, and any session it already has stops working. If the account is linked to a card, a WhatsApp notice with the new status goes to the card's phone (backend and staff panel).
Reset a staff password. The super admin can set a new password from the staff list. The same rules apply as for the sign-in page form: at least 8 characters, active accounts only, and a WhatsApp notice to the linked card (backend and staff panel).
Replace an account's roles. A separate screen takes the account's number and a comma-separated list of roles. It replaces all of that account's roles with the new list. The old roles are kept as inactive records, not deleted (backend and staff panel).
Role catalog. A super admin can list the active roles, create a role with a new unique name, and delete a role after a confirmation (backend and staff panel). The role list has an Edit link that opens the replace-roles screen with that one role filled in.
Where these screens are. The Admin Management menu links only to the staff list, the create-account form, and temporary access links. The role catalog, replace-roles, and separate activate/deactivate forms are not linked from any menu. Staff reach them only by their web address (staff panel).

Temporary access links¶

A super admin can give someone without a staff account, for example an event coordinator, time-limited access to selected staff-panel views. The link is the access: there is no account, password, or one-time code.

Who can manage links. Only a super admin can create links and use the temporary access link screen (backend and staff panel). An Utsav report link also shows in the Utsav short link list. There the backend lets Utsav staff disable, re-enable, edit, or delete it; the staff panel offers disable, re-enable, and delete (backend and staff panel).
What a link grants. A link carries one role, and the link generator issues only two: read-only Utsav or read-only Adhyayan (backend). The staff panel offers two kinds of link: the Utsav registration report for one chosen Utsav and its location, or another staff-panel page with one of the two read-only roles (staff panel).
What the holder sees. For an Utsav report link, the Utsav view, its limits, and what the panel hides are described in Adhyayan & Utsav, Temporary access links for coordinators. A link for another page carries no Utsav or location limit; the backend keeps only its optional start and end dates. The panel blocks WhatsApp automation for every link holder, and sends a link holder to the login page if they open a page their role does not allow (staff panel). The read-only view is a panel rule; the backend does not fully enforce it (see Known limitations below).
Short name and notes. Each link needs a short name made of letters, numbers, hyphens, or underscores. Optional notes can have up to 200 characters (backend).
Expiry. The panel offers 1, 3, 7, 14 (default), 30, or 60 days, or a chosen end date that lasts through the end of that day (staff panel). The backend accepts 1 to 365 days, or any future end date. After expiry the link stops working (backend).
Revocation. A super admin can revoke a link and activate it again from the link list. Revocation acts on the link's short name (see Known limitations below). Utsav staff can also disable or re-enable an Utsav report link from the Utsav short link list, and re-enabling it there restores access, even for a link a super admin revoked. This is a product decision, confirmed on 2026-09-30. While revoked, the short link stops redirecting and the backend refuses the link's access on every request (backend). The list shows the latest 100 links with their status (active, expired, or deactivated), open count, creation date, and expiry date (staff panel).
Browser behavior. The panel removes the access key from the web address after the page opens. If a full staff member is already signed in in that browser tab, opening a link does not replace their session (staff panel).

Issuing and managing member cards¶

Cards are issued and edited only by staff with the right role, there's no path for a member to create their own card. When issuing a card, staff record whether the person is an ordinary member, a Permanent Resident, a Seva Kutir volunteer, or a guest; a new card always starts out marked as "off premises."

Staff can search for a card by name, phone number, or card number, and can reset a member's password back to the same shared starter password used for new cards, the member is expected to change it again afterward. The backend can also rename a card's number and report a card's totals of expenses and refunds, but no staff panel screen offers either action (backend and staff panel).

Every newly issued card starts with that same starter password, so a freshly issued or freshly reset card is not secure until the member sets their own password.

Who can manage cards. The staff panel opens the card screens to the super admin, the office admin, and the card admin. The backend also accepts card actions from the Utsav admin, the WiFi admin, and the food admin (backend and staff panel).

Issuing a card (staff panel and backend).

The card number must be exactly 10 digits, and the phone number must be exactly 10 digits (staff panel).
Name, birth date, ID number, country, state, city, address, PIN code, and centre are required. Email is optional (staff panel).
The ID type choices are PAN, Aadhar, or None (staff panel).
The centre comes from a fixed list of 48 centres built into the create screen, plus "Others" (staff panel).
The member type choices are Mumukshu, Permanent Resident, Seva Kutir, or guest (staff panel).
A guest card also needs a reference card number and a guest type: Family, Friend, Driver, or VIP. The reference card must already exist and cannot be the guest's own card. The backend then links the guest to that card (backend).
When staff edit a guest card, the backend checks the reference card before it saves anything. The reference card is optional on an edit: a blank one saves the other details and leaves the guest's links as they are, because many older guest cards have no host on record. A guest type needs a reference card, and a reference card needs a guest type. A card that is changed into a guest still needs a reference card, as when it is issued (backend). A guest has one host. The backend saves the link between the reference card and the guest, then removes the guest's links to any other member. So a different reference card moves the guest, and the old host no longer sees them in the saved guest list in the member app. Editing a member's own card never touches the guests that member books for. When a guest card is changed to another member type, only the links where that card is the guest are removed (backend).
The card number and the phone number must each be unique across all cards. A duplicate card number is refused with a message that names it. A duplicate phone number is also refused, but the message says the card number must be unique (backend).
A new card is marked "off premises" and gets the shared starter password. A WhatsApp message with the person's name and card number goes to the card's phone (backend).

Searching cards. The Card Management screen searches 0.5 seconds after staff stop typing. It matches any card whose name, phone number, or card number contains the typed text. Each result shows the name, card number, and phone number, with Edit and Reset Password buttons (staff panel and backend). The same screen links to Add New Card and to the Mumukshu credit report.

Editing a card. The edit screen shows every card detail except the card number, which cannot change there. The centre list on this screen comes from the backend's centre list. If the card's centre is not on that list, the screen keeps it as an extra choice (staff panel). For a guest card, the screen also shows the reference card and the guest type, filled in from the guest's current link, with the host's name below. With no reference card on record, the field stays blank and says so, and the guest type is off until a card number is entered. A reference card on record can be changed to move the guest, but not cleared. A saved guest type that is not on the list, such as "RPL Guest", is kept as a choice. Changing a guest card to another member type asks staff to confirm. A refused save shows the backend's reason (staff panel). When at least one detail changes, a WhatsApp message goes to the card's phone. It lists the changed fields and the time of the change. If the phone number changed, the message goes to the new number (backend).

Resetting a member's password. After a confirmation, staff can reset a member's password to the shared starter password. A WhatsApp notice goes to the member's phone (backend and staff panel).

Looking up a card by phone number. Some staff screens find a member by exact phone number: Utsav and Adhyayan registration, food management, and WiFi permanent codes. The lookup returns only the card number, name, centre, phone, member type, and gender. It follows the same role rule as the other card actions (backend).

AVT management (card and photo lookup)¶

Super admins and staff with the AVT admin role have a separate, read-only screen for looking up member cards (backend and staff panel). Staff type part of a name. The screen then lists every card whose name contains that text, with the name, card number, mobile number, email, and a link to view the member's photo. The screen cannot change a card (staff panel).

The photo view blocks right-click, dragging, and text selection to discourage casual copying. This is a deterrent, not a real safeguard (staff panel).

Once a card exists: how a member operates day to day¶

Everything in this section happens on top of an identity staff already created, a member is signing into, completing, and using a card, not creating one.

Signing in, and getting back in if you forget your password¶

A member signs in with their 10-digit phone number and their password, there's no one-time login code and no self-registration; the phone number itself only works because staff already put it on a card.

The member app enables the sign-in button only when the phone number has exactly 10 digits and a password is entered (member app).
The backend refuses an unknown phone number and a wrong password, with different messages (backend).
At sign-in, the member app sends the device's push address, and the backend saves it on the card (backend). See Push notifications.
The member app keeps the member signed in on that device, also after a restart, until the member signs out (member app).

If a member forgets their password, they enter their phone number, confirm they want to reset it, and the system sends a temporary password by both WhatsApp and email, the member app shows a "check your inbox" message pointing at the registered email. Once signed in, a member can change their password from their Profile screen, but doing so requires typing in the current password first.

Temporary password (backend). The temporary password has 5 characters, made of letters and digits. It replaces the old password at once, so the old password stops working before the member reads the message.
What is sent (backend). The email gives the member's name and the temporary password, and asks the member to change it from the profile. The WhatsApp message gives the temporary password, the support WhatsApp number, and a button to copy the password.
What the member sees (member app). The member app shows the registered email address that the backend returns.
Changing the password (member app and backend). The member enters the current password, the new password, and the new password again. The two new entries must match. The backend checks the current password. There is no minimum length for the new password. After a change, a WhatsApp confirmation goes to the member's phone.

Signing out stops push notifications for the member's card, on every device, until the member signs in again; nothing else about the member's account changes.

The backend clears the one push address saved on the card. The member app then forgets the signed-in member on that device (backend and member app).
The member app finishes the sign-out only when the backend confirms it. Without a connection, the member stays signed in (member app).
A member can also sign out from the photo and profile onboarding screens (member app).

Profile: what a member can see and change¶

A signed-in member can view and edit their own profile, name, gender, birth date, address, phone number, government ID type and number, email, country/state/city/postal code, and home centre, and can upload or replace their profile photo. Changing the phone number on file does not require any extra proof that the member actually owns the new number; changing it simply updates the login identifier going forward.

The same profile form is used for onboarding and for later edits on the Profile Details screen (member app):

Field	Rule in the member app
Name, gender, address, ID type, ID number, centre, country, state, city	Required
Birth date	Required; chosen between 1 January 1900 and today
Phone number	Required; exactly 10 digits
Email	Required; must look like an email address
Postal code	Required; 4 to 8 letters, digits, spaces, or hyphens
ID type	PAN or Passport
ID number	A PAN or passport number that does not match the expected pattern shows a warning, but the form still saves
Centre, country, state, city	Chosen from the backend's lists

After a save (backend). When at least one detail changed, a WhatsApp message lists the changed fields and the time. It goes to the new phone number if the number changed. The phone number must stay unique across cards.
Profile photo (backend and member app). The member picks a photo from the phone's photo library and crops it to a square. The backend accepts image files up to 3 MB. A new photo replaces the old one, and the old file is deleted.
Refreshing. Pulling down on the Profile screen loads the latest profile, photo, and credit from the backend (member app).

Members can also browse their own transaction history and see their available credit, broken down by category (room, food, travel, Utsav).

Transaction history, credits, and the card QR code¶

Transaction history (member app and backend). The list shows the member's own transactions, newest first, 10 at a time, with more loaded on scroll. Each row shows:
- the category (room, flat, travel, Adhyayan, Utsav, breakfast, lunch, or dinner) and the amount after any discount;
- the status (pending, completed, cancelled, failed, authorized, or credited);
- the dates and the Adhyayan or Utsav name, when there is one;
- "Booked for" with the attendee's name, and the description;
- the original amount and the amount saved, when a discount applied.
The backend can filter by status and category, but the screen offers no filter. - Credit (member app). The Profile screen shows the available credit for room, travel, food, and Utsav. An information panel says that 1 credit is ₹1, that credit comes only from cancelling a booking that was already paid, and that it is applied automatically at checkout. It also says that credit is non-refundable, non-transferable, and cannot become cash. Payments, Credits & Reconciliation owns the credit rules. - Card QR code (member app). The QR button in the bottom tab bar opens a QR code of the member's card number, with "Card ID" and the number shown under it. Staff screens that scan member cards read this code, for example at the gate (see Services: WiFi, Maintenance, Support & Gate).

Becoming "fully onboarded"¶

The member app decides where to send a signed-in member based on how complete their profile is:

If they haven't uploaded a photo yet, they're sent to add one.
If they have a photo but haven't filled in the rest of their profile, they're sent to complete it.
Once every required field is filled in, name, email, phone, address, birth date, gender, ID type, ID number, country, state, city, postal code, and home centre, plus a photo, they're considered fully onboarded and land in the main part of the member app.

This check runs only on the device, using whatever profile data it was last given. If a staff edit clears one of those fields later, the member can find themselves unexpectedly routed back into onboarding the next time they open the member app.

Photo step (member app). The screen asks the member to upload a picture so staff can recognize them. The member picks a photo from the phone's photo library and crops it to a square; the screen does not open the camera. Upload progress shows on screen, and an error message shows if the upload fails.
Profile step (member app). The screen shows the profile form, filled with what the card already holds. The member must pass every rule in the profile form table above before the form saves.
Leaving onboarding (member app). Both steps offer sign-out. Links that try to open other member app screens are ignored until onboarding is complete.

Guests¶

Guests are the one identity concept a member can bring into being themselves, though only in a limited way. Staff-issued cards hold the full identity details; a guest card made during a booking holds only the few details below. There are two different ways a guest shows up in the system:

A guest profile created on the spot, when a member books a stay, meal, Adhyayan, or Utsav for someone who doesn't have their own card, a lightweight guest record (name, type, phone, gender) is created and tied to the hosting member. This is just enough information to book on that person's behalf.
A returning guest who already has their own card, instead of creating a new profile, the host looks the guest up by phone number and links the two cards together with a relationship (e.g., family, friend). Because a guest can also be a fully independent cardholder, the same person can be both "a member in their own right" and "someone else's registered guest," and they can sign in and use the member app normally either way.

A guest record created during a booking is a card too. It gets a new card number and the shared starter password, so the guest can sign in with that phone number (backend).

Staff-side reporting and reference data¶

Two supporting pieces sit alongside the identity lifecycle above, neither is something a member interacts with directly.

Financial reporting for staff (accounts management)¶

Staff with the accounts/finance role have a reporting view into money movement across the whole system. It is mostly read-only, but uploading a payment-gateway settlement file saves data. It covers completed payments, pending payments, credit issued, credit spent, reconciliation against payment-gateway settlement files, and a list of every cardholder currently sitting on credit (see Payments, Credits & Reconciliation for the reports and upload rules). This sits alongside (but is distinct from) the day-to-day payment and credit rules described in Payments, Credits & Reconciliation.

Location reference data¶

Both the member app's profile form and the staff card forms offer a country → state → city dropdown, plus a separate list of home centres. This is reference data maintained by the product/ops side, not something a member or staff member types freely, picking a country narrows the state list, and picking a state narrows the city list.

Each list is sorted by name. The lists need no sign-in (backend).
The staff panel's edit card screen and the member app use the backend's centre list. The staff panel's create card screen uses its own fixed centre list instead (staff panel and member app).
If the country list cannot load, the staff card screens offer a short fallback list: India, USA, UK, UAE, and Canada (staff panel).
No staff panel screen adds or changes countries, states, cities, or centres. The backend has a bulk-load action that loads every country, state, and city from a data file (backend). See Known limitations below.

Mumukshu credit report¶

The Mumukshu credit report opens from Card Management and from Account Management (staff panel).

It lists every cardholder who has a credit record, sorted by name. Each row shows the card number, name, room, food, travel, and Utsav credit, address, email, and phone number (backend and staff panel).
Clicking a credit amount opens that category's history below the row. Each line shows the booking, the payment order, the amount, the date, and whether credit was added or used, with a total at the end (backend and staff panel).
In the food history, breakfast, lunch, and dinner all count as food. Credit used on a flat booking counts against room credit (backend).
The backend gives this report only to the super admin and the accounts roles. Payments, Credits & Reconciliation owns the credit rules.

Account and identity messages¶

Each message below is a WhatsApp message unless the table says otherwise. A failed message is only recorded in the backend log. The action still succeeds (backend).

Event	Recipient	Key content
A super admin creates a staff account linked to a card	The linked card's phone	The person's name
A super admin activates or deactivates a staff account	The linked card's phone	Name, username, and the new status
A staff password is reset, from the sign-in page or the staff list	The linked card's phone	Name and username
Staff issue a card	The card's phone	Name and card number
Staff edit a card, or a member edits their profile, and at least one detail changes	The card's phone; the new number if the phone changed	Name, card number, time, and the changed fields
Staff reset a member's password to the starter password	The member's phone	Name
A member changes their password	The member's phone	Name
A member uses forgot password	The member's phone, and an email to the card's email	The temporary password. The WhatsApp message also gives the support number and a copy button.

No message is sent for a new staff account without a linked card, a role change, a role catalog change, or a new profile photo (backend).

Known limitations today¶

A few gaps are worth knowing about, even though members don't see them day to day:

There is no real "session" behind a member sign-in. The backend identifies a member only by the card number sent with each request; it does not check a sign-in token. Once a device knows a valid card number, that's treated as sufficient proof for most member-facing actions, this is the single biggest identity gap in the product today.
A temporary or reset password is short and drawn from a small, guessable character set, so a freshly issued or freshly reset card is not meaningfully secure until the member changes the password themselves.
Resetting a staff account's password is not itself protected by a login check, which is a real security gap for the staff panel. The form is on the public sign-in page and needs only a username. It works for any active account, a super admin's included. The only warning is the WhatsApp notice to a linked card, and an account without a linked card gets none.
Forgot password can lock a member out. Anyone who knows a member's phone number can start a reset. The old password stops working at once, and the backend shows the member's email address to whoever asked.
The edit card screen can open the wrong card. The screen loads the card with a "contains" search on the card number and takes the first match. A card whose name, phone, or number contains the same digits can load instead.
The backend's card totals count only unpaid charges and credit. Paid charges are left out. No staff panel screen uses these totals today.
The Mumukshu credit report opens for roles that the backend refuses. The office admin and the card admin can open it from Card Management, but the backend allows only the super admin and the accounts roles. They see "No records found."
The phone lookup on some registration screens is refused. The Adhyayan admin and the Rajnandgaon Adhyayan and Utsav admins can open their registration screens, but the backend refuses the phone lookup for them.
The second accounts role (PRA accounts) cannot sign in to the staff panel. Some accounts pages allow it, but the sign-in page does not recognize it, so the panel says the account has no valid role.
A new role in the role catalog does nothing in the staff panel. The staff panel only knows a fixed set of roles. An account with only a new role is told it has no valid role.
There is no password length rule when a staff account is created, and none when a member changes their password. Only a staff password reset needs 8 characters.
ID types differ between the two clients. The staff panel offers PAN, Aadhar, or None. The member app offers PAN or Passport. A card with the Aadhar ID type has no matching choice in the member app.
The create card screen uses a fixed centre list. It does not follow the backend's centre list, so a new centre must be added in two places.
Members with phone numbers that are not 10 digits cannot use the member app. Sign-in, the profile form, and the staff card form all require exactly 10 digits.
The location bulk-load action has no login check. Anyone can run it. Each run adds every country, state, and city again, which would create duplicates in the dropdowns.
Read-only is a staff-panel rule, not a backend rule. The backend lets the read-only Utsav and read-only Adhyayan roles reach most Utsav and Adhyayan change actions. Only the panel hides those controls. A temporary access link carries the same role, so the same gap applies to it.
The backend checks a temporary access link's limits only on some views. Only the main Utsav lists are narrowed to the link's Utsav and location. Other Utsav views, and all Adhyayan views, are not narrowed to the link's scope. The panel's optional location field for a link to another page has no effect, because the backend drops it.
A link holder's check-in report leaves out people who are already checked in. The backend forces the confirmed filter for link holders, and that filter on the check-in report does not include checked-in bookings.
Card searches return more member data than the screens show. The AVT card search, the card management search for the six roles that the backend allows, and the full-card download for AVT and card staff send every stored field except the password and the push address, such as ID numbers and addresses, although the screens show far fewer. The backend never sends a stored password or a push address to the member app or the staff panel.
Revocation works per short name, not per link. The backend checks only whether the short name is active. It does not check which link was issued. Creating a new link under a name already in use leaves earlier links under that name working until their own expiry, and re-activates the name if it was revoked. Revoking or activating a name affects every link issued under it.
An older link format cannot be revoked. The backend still accepts a link that carries no short name. It cannot check revocation for such a link.
Some staff-facing lookups and a couple of admin endpoints have security weaknesses that go beyond the rules described here.

How this connects to other domains¶

Booking Lifecycle & Engine (03), every booking records both whose stay/booking it is and who created it on their behalf, both pointing back to a card; credit and the transaction ledger described here are the identity side of that system.
Travel (06), the bus-coordinator sign-in described briefly above is a member-card holder given a temporary, narrowly-scoped role; the full coordinator dashboard and boarding workflow live there.
Adhyayan & Utsav (07) and Short Links (10), a temporary access link opens Utsav or Adhyayan staff views, and each link is a short link.
Payments, Credits & Reconciliation (08), a member's credit and transaction history, and the accounts/finance reporting surface, are the money-facing counterpart to the identity records described here.