Accounts, Identity & Authentication¶

Part of the Aashray Business Logic. Related: Booking Lifecycle, Raj Pravas (Travel), Payments, Credits & Reconciliation. For implementation detail — exact routes, database structure, and known code-level defects — see the companion Technical Reference — Accounts, Identity & Auth.

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 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 admin dashboard with a username and password, and are assigned one or more permission levels tied to their job.
Travel/bus coordinators — a special case: an ordinary member who has been designated to help run a specific bus, 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 Raj Pravas (Travel).

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.

Staff accounts, and the cards staff issue¶

This is where a member's identity actually begins: staff hold their own accounts with permission levels 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.

Staff accounts and permission levels¶

Staff sign in to a separate web dashboard with a username and password. Every staff account is granted one or more permission levels 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, and support. Some of these permission levels are further narrowed to view-only access, or scoped to a single centre (for example, a study-program coordinator who can only see bookings for their own centre).

Only a top-level administrator account can create new staff accounts, change what permission levels an existing staff account has, or manage the catalog of permission levels itself. A staff account can be deactivated (locking it out without deleting it) and later reactivated. A staff member's password can also be reset by another administrator to a password of their choosing.

Issuing and managing member cards¶

Cards are issued and edited only by staff with the right permission level — 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 see a running total of a card's expenses and refunds. If needed, staff can rename a card's number (carrying its whole history with it), 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.

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.

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.

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 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.

Signing out simply stops the app from receiving push notifications on that device going forward; nothing else about the member's account changes.

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.

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

Becoming "fully onboarded"¶

The 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 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 app.

Guests¶

Guests are the one identity concept a member can bring into being themselves — though only in a limited way, and staff-issued cards remain the only full identity. 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, study session, or festival 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 app normally either way.

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 on the accounts/finance permission level have a read-only reporting view into money movement across the whole system: completed payments, pending payments, credits issued, credits spent, reconciliation against payment-gateway settlement files, and a list of every cardholder currently sitting on store credit. 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.

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. 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 admin dashboard.
Editing an existing guest relationship doesn't reliably save, even though creating one in the first place works correctly — today this mostly surfaces as a guest's linked-relationship details silently failing to update.
Some staff-facing lookups and a couple of admin endpoints have technical security weaknesses (detailed in the engineering reference) that go beyond what's described here.

Full engineering detail, and every other known defect, is tracked in the technical reference.

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; store credit and the transaction ledger described here are the identity side of that system.
Raj Pravas (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.
Payments, Credits & Reconciliation (08) — a member's store credit and transaction history, and the accounts/finance reporting surface, are the money-facing counterpart to the identity records described here.