create mvp path
This commit is contained in:
hamid
@@ -0,0 +1,13 @@
|
||||
# mvp/ — the only three documents you need right now
|
||||
|
||||
Everything else that used to live in `product/`, `docs/`, and the old `archive/` has been consolidated under
|
||||
[`archive/`](../archive/README.md) as historical/reference material. It is not required reading to answer
|
||||
"what's next" — these three files are:
|
||||
|
||||
| File | Answers |
|
||||
| --- | --- |
|
||||
| [test-flows.md](test-flows.md) | "How do I manually test that X works?" — plain-language, click-by-click walkthroughs of every user journey, no engineering knowledge required. |
|
||||
| [blockers.md](blockers.md) | "What has to be fixed before this is a real product?" — what's broken today, and what must happen before real money/real users touch it. |
|
||||
| [forgotten-features.md](forgotten-features.md) | "What's missing that we haven't clearly scheduled?" — planning gaps that don't show up as an app bug, plus a short list of things already deliberately cut so they don't get re-litigated by accident. |
|
||||
|
||||
> Last verified: 2026-08-02.
|
||||
+121
@@ -0,0 +1,121 @@
|
||||
# Blockers — what has to be fixed before this is a real product
|
||||
|
||||
Two different kinds of "blocker" here, and both matter:
|
||||
|
||||
- **A. The product itself is broken** — a real user would hit a wall or be shown wrong information, with or
|
||||
without real money involved.
|
||||
- **B. The launch gate** — things that must be true before a real stranger with real money is allowed to touch
|
||||
this, even on a day when part A is fully fixed.
|
||||
|
||||
Effort is a rough size, not a schedule: **S** = small/contained, **M** = a real but bounded piece of work,
|
||||
**L** = a project of its own.
|
||||
|
||||
---
|
||||
|
||||
## A. The product is broken or unusable
|
||||
|
||||
### Admin can't do anything
|
||||
- **No admin account can perform a single real admin action.** Every super-admin/finance account gets
|
||||
"access denied" on every real admin screen — approving a nurse, moderating a review, processing a refund,
|
||||
running a payout batch, managing tickets, all of it. The permission system only recognizes one hardcoded
|
||||
role name that nothing ever actually assigns. *(Effort: M)*
|
||||
- **On top of that, no demo account holds even that hardcoded role**, so fixing the permission bug alone
|
||||
still leaves nothing to test it with out of the box. *(Effort: S, bundled with the item above)*
|
||||
|
||||
*Why this matters more than it looks: a large share of the other items below — nurse verification,
|
||||
reviews, refunds, payouts, ticket handling — are gated behind this one fix. Fixing admin access is the
|
||||
single highest-leverage thing on this list.*
|
||||
|
||||
### Payments
|
||||
- **A card payment can never actually complete.** The test/demo payment page redirects to a page that
|
||||
doesn't exist. Nothing about the money logic itself is wrong — it's the very last step, handing off to a
|
||||
real payment provider, that isn't connected. *(Effort: M)*
|
||||
- **The 30-minute payment countdown can lie.** Booking deadlines are stored without a timezone, so the timer
|
||||
a customer sees can silently show hours more time than they actually have, and expire while they still
|
||||
think they're fine. *(Effort: S)*
|
||||
- **Installment (buy-now-pay-later) payments don't work at all.** No installment plan is ever actually set up
|
||||
behind the scenes, so every attempt fails immediately. *(Effort: S–M, two related issues)*
|
||||
- **Refunds are demo-only today.** The refund screens read fake, disconnected sample data; turning that off
|
||||
today would show a refund of the wrong amount (off by a factor of 100) for any real cancellation.
|
||||
*(Effort: M)*
|
||||
|
||||
### Trust — nurse verification
|
||||
- **A nurse's verification badge does not reflect reality.** The verified/unverified status shown to
|
||||
customers and to the nurse herself comes from a fake demo layer, not the real, already-working
|
||||
verification data underneath. A genuinely verified nurse can show as unverified everywhere in the app, and
|
||||
vice versa — silently hiding the real "you're not searchable yet" warning a nurse needs to see.
|
||||
*(Effort: L)*
|
||||
|
||||
### Patient records & visit notes
|
||||
- **Everything a nurse writes about a visit, and everything a family sees about a patient's care plan, is
|
||||
fake demo data.** Nothing typed in today is actually saved, and the real backend behind this expects
|
||||
slightly different data than the screens send — so simply "turning the mock off" would break on day one.
|
||||
*(Effort: M)*
|
||||
|
||||
### Nurse pay
|
||||
- **A nurse's earnings/payout screens show fake numbers**, hiding four features that already work for real
|
||||
underneath. There's also no button anywhere to actually run the "send the money" step — the one
|
||||
irreversible action in the whole payout process has no interface at all — and the "paid" status shown to a
|
||||
nurse can be wrong (it's set as soon as a payout is linked, not when it's confirmed to have gone through).
|
||||
*(Effort: M)*
|
||||
|
||||
### Partner / business-center accounts
|
||||
- **The whole "partner business center" section is fake, with zero real account matching.** Any signed-in
|
||||
user who opens it resolves to the same one fake center regardless of who they are, and several of its core
|
||||
pages (its own booking list, its own settlement report) don't exist on the server at all yet. This matters
|
||||
more than it sounds — see [forgotten-features.md](forgotten-features.md) for why the business plan leans on
|
||||
this feature specifically. *(Effort: L)*
|
||||
|
||||
### Search
|
||||
- **Search results aren't de-duplicated nurses — they're raw pricing-option rows.** One nurse with 3 services
|
||||
in 3 areas shows up as "9 nurses." The trust information on a result card is also fake, and a nurse who
|
||||
isn't verified yet can still be opened directly and shown as "verified" if you know her profile link.
|
||||
*(Effort: M)*
|
||||
|
||||
### Data safety
|
||||
- **Editing a saved home address can silently wipe out the recipient's name and phone number** on every save,
|
||||
because the edit form never collects those fields but the save action clears them anyway. *(Effort: S)*
|
||||
|
||||
### Booking lifecycle
|
||||
- **A booking whose remaining visits get automatically marked "missed" can get stuck forever** and never
|
||||
reach a state where the nurse can actually be paid for the visits she did complete. The "today's visits"
|
||||
list nurses see is also unfiltered — it shows a nurse's entire history, not just today. *(Effort: M)*
|
||||
|
||||
### Reviews
|
||||
- **A real review can never actually go live.** It gets submitted and saved correctly, but the approval step
|
||||
that would publish it sits behind the broken admin-access problem above, so nothing ever gets un-stuck.
|
||||
*(Effort: S once admin access is fixed)*
|
||||
|
||||
### Catalog / pricing
|
||||
- **Outside of the developer's own local setup, there are zero service categories or pricing options
|
||||
configured at all**, and there is no admin page to add them — only direct database editing. Deployed as-is,
|
||||
every "choose a service" screen collapses to a nearly useless two-step form. *(Effort: M)*
|
||||
|
||||
---
|
||||
|
||||
## B. Before a real stranger's real money touches this
|
||||
|
||||
These hold regardless of whether every item in section A gets fixed first.
|
||||
|
||||
1. **Rotate every credential currently committed to the codebase** — the database password, both encryption
|
||||
keys, and the API keys for SMS/maps/banking-lookup/bot services. This is a deliberate, known trade made to
|
||||
ship a demo fast; it must be undone before onboarding real users. One of these — the key that encrypts
|
||||
personal data like phone numbers and addresses — can't just be swapped; changing it requires re-encrypting
|
||||
everything already stored under the old one first, so treat that specifically as its own small project,
|
||||
not a quick config edit.
|
||||
2. **Turn off developer/debug mode on the live site.** Right now, the deployed site runs in a mode meant for
|
||||
local development. The single biggest consequence: **anyone who knows a person's phone number can read
|
||||
their login code directly from a public link** and sign in as them. This has to be closed before real
|
||||
strangers can reach the site.
|
||||
3. **Get real legal review of the Terms of Service and Privacy Policy.** They currently ship as placeholder
|
||||
text behind a visible "draft" banner.
|
||||
4. **Finish the real e-invoicing (مودیان) hookup.** The invoice data and tax math are already correct; the
|
||||
actual government-facing integration that registers each invoice isn't wired up yet, and the business plan
|
||||
calls this required, not optional, scope.
|
||||
5. **Obtain "e-namad" certification.** This is a business/paperwork step, not a code change — but a monetized
|
||||
Iranian website legally cannot get a real payment gateway without it, so nothing in item 6 below or in the
|
||||
card-payment blocker above can go fully live until this exists.
|
||||
6. **Build a real bank-transfer system for paying nurses.** Every other "fake" system in the app (SMS, maps,
|
||||
card payments, identity checks) already has a real version written and just needs real credentials to
|
||||
switch on. Paying nurses is the one exception — there is no real version yet at all. Even after everything
|
||||
else on this page is fixed, **nurses still can't actually be paid** until this is built from scratch.
|
||||
@@ -0,0 +1,88 @@
|
||||
# Forgotten features — gaps that should probably be in the MVP plan
|
||||
|
||||
This is not the full backlog. It's a short, opinionated list of things that are easy to lose track of because
|
||||
they don't show up as a bug in the app (there's nothing to click and see broken) — they're missing consoles,
|
||||
missing channels, or missing business steps that the product's own plan implies are needed, but that aren't
|
||||
clearly assigned to anyone right now.
|
||||
|
||||
---
|
||||
|
||||
## Worth reconsidering for MVP
|
||||
|
||||
**Nurses have no real way to get paid.** This is also in [blockers.md](blockers.md), but it's worth
|
||||
separating out as a planning gap, not just a bug: every other "fake" integration in this app (SMS, maps, card
|
||||
payments, identity checks) already has a real version written and waiting for credentials. Paying nurses does
|
||||
not — there is no real bank-transfer integration at all, for any provider. A home-nursing marketplace whose
|
||||
nurses can't be paid isn't really an MVP yet, so this deserves to be sized and scheduled as new work, not
|
||||
discovered late.
|
||||
|
||||
**Nobody can actually approve a nurse, even after admin login gets fixed.** The nurse-verification approve/
|
||||
reject buttons in the admin console point at server actions that don't exist yet. Fixing the admin-permission
|
||||
bug (the #1 item in blockers.md) will not make this work — it's a second, separate piece of missing work,
|
||||
easy to assume is "included" in the RBAC fix when it isn't.
|
||||
|
||||
**Nobody can review a refund before it happens.** Today, an admin action that creates a refund also executes
|
||||
it in the same step — there is no preview/approve/reject step, the way there is for other sensitive actions.
|
||||
For a marketplace holding customer money in escrow, having no human-review gate before money moves back out
|
||||
is worth a second look before launch, not just "eventually."
|
||||
|
||||
**There's no way to confirm whether a nurse payout actually succeeded or failed.** The system can generate a
|
||||
payout batch, but there's no console action to record "the bank transfer bounced" and reconcile it. Combined
|
||||
with the point above about there being no real bank-transfer system yet, payouts as a whole need a fresh look
|
||||
before this ships.
|
||||
|
||||
**Partner business centers — the business plan's stated fast, legal path to market — are 100% fake today**,
|
||||
with no real tenancy, no real onboarding, and several of the pages a partner would need (their own booking
|
||||
list, their own settlement report) not built server-side at all. This is flagged as a blocker, but it's worth
|
||||
naming explicitly as a *feature* gap too: if the go-to-market plan depends on partnering with already-licensed
|
||||
nursing centers, someone needs to own building the actual partner-facing product, not just unblocking the
|
||||
admin side of it.
|
||||
|
||||
**Only in-app notifications exist — no SMS or push.** That's a fine trade in general, except two flows are
|
||||
genuinely time-boxed: a nurse has roughly a day to respond to a booking request, and a customer has 30 minutes
|
||||
to pay once accepted. If nobody has the app open when that window opens, they simply miss it, silently. Worth
|
||||
a deliberate call on whether at least these two moments need a text message, rather than leaving it as "no
|
||||
SMS/push, full stop."
|
||||
|
||||
**There's no way to search for a nurse by name.** Only category, city, gender, and price filters exist. Minor
|
||||
on its own, but combined with the fact that search results aren't de-duplicated yet (see blockers.md), a
|
||||
returning customer who wants to rebook "the nurse she had last time" currently has no reliable way to find her
|
||||
again by name.
|
||||
|
||||
**The legal/compliance items already called out in blockers.md** — real Terms & Privacy copy, the
|
||||
مودیان e-invoicing hookup, and e-namad certification — are as much "features not yet built" as they are
|
||||
blockers. Listed here again only so they don't get read as pure security/ops cleanup and quietly deprioritized
|
||||
relative to product features.
|
||||
|
||||
---
|
||||
|
||||
## Deliberately cut — already decided, listed only so they don't get re-litigated
|
||||
|
||||
Everything below was already, explicitly ruled out of MVP scope by an earlier product or engineering decision.
|
||||
None of it is "forgotten" — it's recorded here as a single short list so a planning conversation doesn't
|
||||
accidentally re-open one of these by mistake.
|
||||
|
||||
- **"Nurses near me" (GPS-radius map search)** — coverage stays named-district-only, by design, permanently.
|
||||
- **Recurring / subscription bookings** — one-off bookings only for now.
|
||||
- **Company / organization accounts** (a business paying for multiple employees' care) — not modeled yet.
|
||||
- **Holiday/surge pricing, and a distinct "daily companionship" pricing tier** — out of scope per the pricing
|
||||
business rules.
|
||||
- **Two-way, double-blind reviews** — reviews are one-way (customer → nurse) only, by design.
|
||||
- **Automated fraud scoring** — manual suspension plus support alerts cover this for now.
|
||||
- **Automated license/credential lookup with the medical licensing authority** — manual verification is the
|
||||
intended MVP path; no public lookup API is confirmed to even exist yet.
|
||||
- **In-app calling/dialer for emergencies** — the emergency contact is a plain phone-dial link on purpose, not
|
||||
a built-in calling feature.
|
||||
- **Offline/installable app mode** — marked optional from the start.
|
||||
- **Scaling infrastructure** (a shared cache, a dedicated search engine, an analytics warehouse) — today's
|
||||
single-server setup is correct at MVP scale; each has a specific, measurable trigger for when to revisit it,
|
||||
not a date.
|
||||
- **An automated holiday calendar feed** — a yearly manual top-up is an acceptable trade for now.
|
||||
- **Collecting a customer's national ID** — deliberately never gated on this, by design.
|
||||
- **On-demand/instant nurse payout, or a different payout schedule per nurse** — one fixed weekly cycle for
|
||||
everyone is the MVP design.
|
||||
- **Automated recovery of clawed-back money beyond simple netting against the next payout** — the simple
|
||||
version covers MVP.
|
||||
- **A true desktop-width layout** — the phone-width layout is the whole app's deliberate design for now.
|
||||
- **Partner centers signing themselves up online** — centers are onboarded manually for now, separate from the
|
||||
partner-center product gap called out above.
|
||||
@@ -0,0 +1,486 @@
|
||||
# Test flows — walk the app like a real user
|
||||
|
||||
No engineering knowledge needed. Every flow below is a short list of clicks and taps you can do yourself on
|
||||
the live demo site, plus what you should expect to see, and any known problems along the way.
|
||||
|
||||
## Before you start
|
||||
|
||||
**Site:** open **https://balinyaar.ir** in your browser (the API behind it is `api.balinyaar.ir` — you won't
|
||||
need to touch that directly except for one step below).
|
||||
|
||||
**How to log in — every flow below starts here:**
|
||||
1. Go to the login page and enter one of the demo phone numbers below.
|
||||
2. Tap "send code." You will **not** receive a real text message — this is a test environment.
|
||||
3. To read the code, open this link in a new browser tab, replacing the number with the one you used:
|
||||
`https://api.balinyaar.ir/api/v1/dev/last_otp/09120000010` — a page appears with a `"code"` field. Copy
|
||||
that 6-digit number.
|
||||
4. Type the code into the app.
|
||||
|
||||
**Two things that will trip you up if you don't know them:**
|
||||
- **Only one person can be signed in to a given demo account at a time.** If a colleague logs into
|
||||
`09120000010` on their laptop while you're using it on yours, you'll be silently signed out.
|
||||
- **The demo data ages on its own.** A pending booking request, for example, auto-expires after a while. If a
|
||||
flow below says "find a pending request" and there isn't one, just create a fresh one yourself — the steps
|
||||
for that are in "Requesting a Booking" below.
|
||||
|
||||
### Demo accounts
|
||||
|
||||
| Phone | Who | Notes |
|
||||
| --- | --- | --- |
|
||||
| `09120000001` | Nurse — زهرا عزیزی (f) | Verified, has priced services, covers most of Tehran |
|
||||
| `09120000002` | Nurse — علی کریمی (m) | Verified, sponsored by a partner business center |
|
||||
| `09120000003` | Nurse — مریم احمدی (f) | **Not verified yet** — should never appear in customer search |
|
||||
| `09120000010` | Customer — سارا محمدی (f) | 2 people in her care circle, 1 saved address, owns most seeded bookings |
|
||||
| `09120000011` | Customer — رضا حسینی (m) | 1 infant patient, owns the installment-plan bookings |
|
||||
| `09120000020` | Admin (full) — نگار مدیری (f) | Can log in, but admin actions don't work yet — see [blockers.md](blockers.md) |
|
||||
| `09120000021` | Admin (finance) — کامران مالی (m) | Same admin caveat as above |
|
||||
| `09120000030` | Customer who owns a partner business center — بهنام رستگار (m) | Logs in as a normal customer, then opens the partner section by typing its address directly — nothing in the app links to it |
|
||||
|
||||
---
|
||||
|
||||
## Signing in and the public landing page
|
||||
|
||||
### Logging in with a phone number
|
||||
**Who tests this:** everyone (new visitors, customers, nurses, admins)
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. While logged out, try opening a nurse-only page (like "Today's Visits"). You should be sent to the login screen instead.
|
||||
2. On the login screen, enter phone number `09120000010` and request a code. Expect a 6-box code screen with a countdown timer.
|
||||
3. Read the code as described above and type it in. Expect it to auto-submit and take you to the family home screen (not the nurse page you originally tried).
|
||||
4. Repeat with `09120000001` (زهرا عزیزی, nurse). This time you should land on the nurse's "Today's Visits" screen instead.
|
||||
5. Try entering a wrong code five times in a row. Expect a lockout message; requesting a new code should still work.
|
||||
6. Log in as `09120000020` (نگار مدیری, admin). Login itself succeeds, but admin features don't work (known blocker).
|
||||
|
||||
**What you should see:** each account type lands on its correct home screen after login, and a page you tried to reach before logging in is remembered and opened afterward.
|
||||
|
||||
**Known issues:**
|
||||
- Admin accounts can log in but can't actually do anything yet (known blocker — see [blockers.md](blockers.md))
|
||||
- After too many wrong codes, the "try again later" message is wrongly shown as "wrong code"
|
||||
- Logging out on one device signs that account out everywhere, with no option to choose just one device
|
||||
|
||||
### The guest landing page (before logging in)
|
||||
**Who tests this:** anyone not logged in yet (a guest visitor)
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Open the app in a private/incognito browser window so you're logged out.
|
||||
2. Visit the home page. Expect a marketing landing page: what Balinyaar is, service category tiles, a "how it works" explainer, trust information, and a sign-up button for nurses.
|
||||
3. Open the Terms and Privacy pages from the footer. Expect placeholder legal text with a draft banner — not final legal copy yet.
|
||||
4. While still logged out, try opening a private page like "My Bookings." Expect to be sent to the login screen, and after logging in, expect to land back on the page you originally tried.
|
||||
|
||||
**What you should see:** the landing page loads properly, legal pages show draft text, and any private page tried while logged out sends you to log in first, then returns you there afterward.
|
||||
|
||||
**Known issues:**
|
||||
- There's no way yet to search or browse nurses without logging in first — that part isn't built
|
||||
- A nurse's profile photo never actually loads for anyone, including guests
|
||||
- A nurse who hasn't been verified yet can still be viewed directly if you know/guess her profile link, even though she should never be publicly visible
|
||||
|
||||
---
|
||||
|
||||
## Setting up an account
|
||||
|
||||
### New customer setup (choosing "family," adding your first person, filling in your profile)
|
||||
**Who tests this:** customer (new user)
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Log in as `09120000010` (سارا محمدی, customer) — see "How to log in" above.
|
||||
2. Open the home page. This account is already fully set up, so expect to land directly on the normal home screen (not a setup wizard), with her 2 people already listed.
|
||||
3. Open Account settings. Expect her name, masked phone number, and emergency contact already filled in.
|
||||
4. Note: every demo account is already onboarded, so the true first-time experience needs a brand-new phone number not in the list above. A first-time login instead walks you through picking "I need care" vs. "I am a nurse," then who you're arranging care for, then later nudges you from the home page to fill in your own contact and emergency details.
|
||||
|
||||
**What you should see:** an already-set-up account goes straight to its home page; a brand-new account is walked through picking a role, adding its first person, and is reminded afterward (via a home-page card) to finish its own contact details.
|
||||
|
||||
**Known issues:**
|
||||
- Saving any one part of Account settings re-saves the whole form, so an old, unrefreshed screen can silently overwrite your name with an outdated value
|
||||
- There's no way to set your own gender anywhere in the app
|
||||
- The page that lets you add the nurse role to your account has no warning before permanently changing your account — best not to open it just to look
|
||||
|
||||
### New nurse setup (profile, bank account, and going live)
|
||||
**Who tests this:** nurse
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Log in as `09120000001` (زهرا عزیزی, verified nurse) — see "How to log in" above.
|
||||
2. Open the nurse dashboard. Expect a setup checklist — but it will wrongly show verification as incomplete even though this nurse is actually fully verified (known blocker).
|
||||
3. Open the nurse's profile page, edit the bio text, and save. Expect a success message, still there after refreshing.
|
||||
4. Open the bank account page. Expect one card showing a verified account.
|
||||
5. Try adding that same bank account number again. Expect a vague "couldn't register" error rather than a clear "already registered" message.
|
||||
6. Open the public profile preview. Expect the profile photo to show a placeholder icon instead of a real photo.
|
||||
|
||||
**What you should see:** profile edits and bank details save correctly for real, but the setup checklist and any "profile not active" warning are unreliable and don't reflect this nurse's true, already-verified state.
|
||||
|
||||
**Known issues:**
|
||||
- A nurse's verification status shown on screen doesn't reflect their real state — it always looks incomplete (known blocker — see [blockers.md](blockers.md))
|
||||
- Profile photos never actually display anywhere, always a placeholder icon
|
||||
- Adding a duplicate bank account shows a vague error instead of saying it's already registered
|
||||
- All seeded nurse accounts already have a profile and bank account, so the very first-time setup screens can't be tested with the demo accounts
|
||||
|
||||
### Saved addresses & the map pin
|
||||
**Who tests this:** customer
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Log in as `09120000010` (سارا محمدی, customer) — see "How to log in" above.
|
||||
2. Open Account settings → "Manage addresses" (or go straight to the addresses page). Expect one saved address ("Home"), marked as primary, showing a registered pin.
|
||||
3. Add a new address: pick a province and city, tap the map area to drop a pin, fill in the street line, and save. Expect it to appear in the list tagged "pin saved."
|
||||
4. Set the new address as primary. Expect the primary badge to move to it (never two at once).
|
||||
5. Delete the test address when done.
|
||||
6. Try picking a province other than Tehran when adding an address — the map area may open centered on the wrong, empty spot instead of near that city (known issue).
|
||||
|
||||
**What you should see:** adding, editing, setting-primary, and deleting addresses all work and save for real. The map for choosing a location is currently just a simple tap-to-place grid, not a real interactive street map yet.
|
||||
|
||||
**Known issues:**
|
||||
- Editing a saved address can silently erase the recipient's name and phone number (known blocker — see [blockers.md](blockers.md)) — don't edit the pre-existing "Home" address for this reason; test with a newly added one instead
|
||||
- Outside Tehran, the map area often opens in the wrong location, far from the real city
|
||||
- The real interactive map (with street search and real tiles) isn't turned on in this test environment yet
|
||||
|
||||
### Care circle & patient records
|
||||
**Who tests this:** customer (nurses write visit notes on their side of the same records)
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Log in as `09120000010` (سارا محمدی, customer) — see "How to log in" above.
|
||||
2. Open the "care circle" page. Expect two people listed: فاطمه محمدی and حسن محمدی.
|
||||
3. Add a new person. Expect it to appear in the list immediately with a success message.
|
||||
4. Archive one of the people (not delete). Expect it to disappear from the list with a confirmation message — it isn't gone forever, and any of their existing bookings keep working.
|
||||
5. Tap a person to open their detailed record (medications, routine, visit history, tasks tabs).
|
||||
|
||||
**What you should see:** the list of people you arrange care for is fully real — adding, editing, and archiving all save properly. Opening a person's detailed record shows placeholder demo information, not real saved data.
|
||||
|
||||
**Known issues:**
|
||||
- Patient medical records and nurse visit notes are entirely fake demo data right now (known blocker — see [blockers.md](blockers.md))
|
||||
- Editing a person's details and saving can accidentally reset their birth date to January 1st of their birth year
|
||||
|
||||
---
|
||||
|
||||
## A nurse's professional profile
|
||||
|
||||
### Nurse service coverage areas
|
||||
**Who tests this:** nurse
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Log in as the verified nurse `09120000001` (زهرا عزیزی).
|
||||
2. From her main professional hub, open "Coverage areas" — check the count shown matches the list on the next screen.
|
||||
3. Try adding an area she already covers (same city, "whole city") — expect an inline warning, and nothing gets added.
|
||||
4. Add a brand-new district inside a city she already covers as "whole city" — expect it to save and appear as a new tag.
|
||||
5. Remove one of the areas and confirm the deletion in the popup.
|
||||
|
||||
**What you should see:** the list of covered cities/districts updates instantly after adding or removing one, and a warning message blocks true duplicates.
|
||||
|
||||
**Known issues:**
|
||||
- A nurse can end up covering both "whole city" and one specific district of that same city at the same time — when that happens, she shows up twice in search results for that district (known blocker — see [blockers.md](blockers.md))
|
||||
- If this screen fails to load properly, it wrongly displays "no coverage areas yet," which could make a nurse think she's invisible in search when she isn't
|
||||
- There's no way to edit an area — only remove and re-add, and she briefly disappears from search in between
|
||||
|
||||
### Nurse verification (ID & credential checks)
|
||||
**Who tests this:** nurse; admin (the admin part is broken)
|
||||
**Status today:** ❌ Mostly fake/broken — not really testable yet
|
||||
|
||||
1. Log in as `09120000003` (مریم احمدی), the nurse who is deliberately not yet verified.
|
||||
2. Open her verification screen — a step-by-step checklist appears, plus an on-screen "simulate admin review" panel with approve/reject buttons.
|
||||
3. Fill in the identity and credential steps, then tap the fake "approve" button. Expect the screen to turn green ("approved") — but reload the page and it resets, because none of this reached the real system.
|
||||
4. Log in as admin `09120000020` and open the admin verification queue — it shows nurses waiting for review, but this is also sample data, and the real approve/reject actions don't work.
|
||||
|
||||
**What you should see:** the on-screen experience looks like a complete, working verification journey, but nothing you do here changes any nurse's actual verification status.
|
||||
|
||||
**Known issues:**
|
||||
- The whole nurse-facing screen currently shows made-up demo data instead of the real system, so a nurse cannot actually be verified through the app today
|
||||
- A nurse's verification badge shown to users doesn't reflect her real, actual state (known blocker — see [blockers.md](blockers.md))
|
||||
- Admin accounts can't do anything yet, including approving nurses (known blocker — see [blockers.md](blockers.md))
|
||||
|
||||
### Setting up services & prices
|
||||
**Who tests this:** nurse (results also show up when customers browse)
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Log in as the verified nurse `09120000001` (زهرا عزیزی).
|
||||
2. From her hub, open her services/offerings list — note how many services she currently offers.
|
||||
3. Tap to add a new service and pick a category (e.g. "Elderly care").
|
||||
4. Answer the required question for that category (e.g. shift type), set a price and unit, and submit.
|
||||
5. Try adding the exact same category, choices, and price again — expect an inline warning that she already offers this, instead of a duplicate.
|
||||
6. Deactivate one service — expect it to stay in her own list marked inactive, but disappear from her public profile preview.
|
||||
|
||||
**What you should see:** the price list updates immediately after each change, duplicates are blocked with a clear message, and deactivated services vanish from what customers can see.
|
||||
|
||||
**Known issues:**
|
||||
- Only a developer can add brand-new service categories or pricing choices — there's no admin page for it yet (known blocker — see [blockers.md](blockers.md))
|
||||
- If a nurse changes a price while a customer is mid-way through requesting a booking for that service, the customer could end up being charged the new price instead of the one shown to them
|
||||
- Some Persian text can display with slightly different spacing than what was typed (cosmetic only)
|
||||
|
||||
---
|
||||
|
||||
## Finding and booking a nurse
|
||||
|
||||
### Searching for a nurse
|
||||
**Who tests this:** customer
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Log in as customer `09120000010` (سارا محمدی).
|
||||
2. Open the search page, choose a care category (e.g. "Elderly care") and a city.
|
||||
3. Tap to view results and note how many nurses are shown.
|
||||
4. Tap the "verified" checkmark on a result card to see her trust details.
|
||||
5. Open a nurse's profile card to browse her priced services and reviews.
|
||||
6. As a check, search a category only the unverified nurse (`09120000003`) offers — expect zero results, since she must never appear.
|
||||
|
||||
**What you should see:** a list of nurses matching the filters, each with a verified badge and an openable profile; the unverified nurse should never appear anywhere in results.
|
||||
|
||||
**Known issues:**
|
||||
- The same nurse can appear multiple times in one results list (once per price option/area combination), so a count like "9 nurses" can really mean 1 nurse repeated 9 times (known blocker — see [blockers.md](blockers.md))
|
||||
- The "verified" badge popup shows the same generic made-up credentials for every nurse, and can even say "verified" for a nurse who isn't (known blocker — see [blockers.md](blockers.md))
|
||||
- Nurse profile photos don't load and show initials instead (cosmetic only)
|
||||
- There's no way to search by a nurse's name — only by category/city/gender/price filters
|
||||
|
||||
### Requesting a booking
|
||||
**Who tests this:** customer and nurse
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. The pre-loaded demo requests have all expired, so create a fresh one first: log in as customer `09120000010`, search for and open nurse زهرا عزیزی (`09120000001`), and tap "request booking".
|
||||
2. Fill in a patient, a priced service, an address, a future date/time window, and a gender preference, then submit. Expect a screen showing "awaiting nurse response" with a roughly 24-hour countdown.
|
||||
3. In a separate login, log in as the nurse (`09120000001`) and open her requests inbox. Find the new pending request — note she only sees a rough neighborhood, not the full address.
|
||||
4. Accept the request. Expect the status to change to "accepted — awaiting payment" with a new 30-minute countdown, and the customer's screen to update automatically within about 15 seconds.
|
||||
5. Try accepting the same request again — expect a friendly "no longer available" message, not a crash.
|
||||
6. Optionally, submit a second request and have the nurse reject it with a short reason — expect the customer's screen to show the rejection and the reason.
|
||||
|
||||
**What you should see:** a full round trip — request created, nurse notified, accepted or rejected, and the customer's screen reflecting it live — without errors.
|
||||
|
||||
**Known issues:**
|
||||
- The countdown timers on this flow can show the wrong time and expire early due to a timezone bug (known blocker — see [blockers.md](blockers.md))
|
||||
- A nurse with many past requests may not see all of them listed in her "already responded" tab
|
||||
- The customer's booking list doesn't auto-refresh, so a countdown there can look stale until manually reloaded
|
||||
|
||||
### Checkout & payment
|
||||
**Who tests this:** customer
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Nothing is waiting to be paid in the seeded data, so first create and get a booking request accepted (see "Requesting a Booking" above) to open a live 30-minute payment window.
|
||||
2. As customer `09120000010`, open that booking's checkout/payment page. Expect a price breakdown, a live countdown, and an enabled "Pay" button.
|
||||
3. Known limitation: tapping "Pay" leads to a card-payment page that doesn't exist in this test environment and dead-ends there — treat this as a known gap, not something to keep troubleshooting.
|
||||
4. Instead, to see a completed example, open an already-paid booking's checkout page or its invoice page — expect an "already paid" message and a printable invoice with a price breakdown and a tax-status label.
|
||||
5. Open the wallet/money page's "Payments" tab — expect it to appear empty (not an error), since payment history isn't connected yet.
|
||||
|
||||
**What you should see:** everything up to pressing "Pay" behaves correctly and shows sensible numbers, but no card payment can actually be completed in this environment.
|
||||
|
||||
**Known issues:**
|
||||
- Card payment never actually completes in this test environment (known blocker — see [blockers.md](blockers.md))
|
||||
- The wallet's "Payments" history tab is always empty
|
||||
- Installment (buy-now-pay-later) payments don't work at all yet (known blocker — see [blockers.md](blockers.md))
|
||||
- The checkout summary and the invoice can show slightly different tax amounts for the same booking
|
||||
|
||||
### Booking payments in installments (buy-now-pay-later)
|
||||
**Who tests this:** customers checking out a booking
|
||||
**Status today:** ❌ Mostly fake/broken — not really testable yet
|
||||
|
||||
Everything on these screens is fake demo data, not a real installment plan.
|
||||
|
||||
1. Log in as رضا حسینی (`09120000011`) — he's the demo account tied to installment bookings.
|
||||
2. Start checkout on a booking and look for a "pay in installments" option — in today's demo world, no booking is actually in a state that lets this option go anywhere.
|
||||
3. Instead, open the Wallet page and tap the "Installments" (اقساط) tab to see what such a plan would look like.
|
||||
|
||||
**What you should see:** a fake, made-up installment plan with sample amounts and a fake provider name — none of it is a real payment, and it resets if you reload the page.
|
||||
|
||||
**Known issues:**
|
||||
- Installment (buy-now-pay-later) payments don't work at all yet (known blocker — see [blockers.md](blockers.md))
|
||||
- There is no working path from checkout into the installment screens today — the wallet tab is the only way to see them
|
||||
- All numbers shown (schedule, fees, provider) are invented, not calculated from a real order
|
||||
|
||||
---
|
||||
|
||||
## The visit itself
|
||||
|
||||
### Visit day: check-in, check-out, and care instructions
|
||||
**Who tests this:** nurse (does the visit) and customer (watches from their side)
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. If testing on a computer away from Tehran, ask an engineer to switch the app's location check to "in range" first — otherwise every check-in you do will look like a location mismatch.
|
||||
2. Log in as the nurse, `09120000001` (زهرا عزیزی), and open "Today's Visits."
|
||||
3. Note: the demo data has aged out, so this screen currently shows the nurse's whole visit history mixed together, not just today's — a known issue, not a crash.
|
||||
4. Open one of her bookings. Expect to see the patient's care instructions (allergies, medications, emergency contact) and a list of visit sessions.
|
||||
5. To actually walk a real check-in/check-out, you need a booking with a session scheduled for today — the seeded data doesn't have one, so create a fresh booking request and get it paid first (see "Requesting a Booking" and "Checkout & Payment" above).
|
||||
6. Check in to a session. Expect it to record your location and timestamp; a location mismatch (if it happens) quietly notifies the family — it never blocks or cancels the visit.
|
||||
7. Check out. Expect the visit to be marked complete and the nurse's payment for that visit to start its countdown to being payable.
|
||||
8. Log in as the customer (`09120000010`) and open the same booking. Expect to see the full address and a status timeline, but no check-in/check-out controls (those are nurse-only).
|
||||
|
||||
**What you should see:** the nurse can see care instructions only after the booking is confirmed, can check in/out, and the customer can watch the same booking's status update — without seeing the clinical notes or check-in controls.
|
||||
|
||||
**Known issues:**
|
||||
- The "Today's Visits" list isn't actually filtered to today — it shows a nurse's entire history (known issue)
|
||||
- A booking whose visits all got auto-marked "missed" can get stuck and never become payable for the nurse (known blocker — see [blockers.md](blockers.md))
|
||||
- The nurse currently can't see the customer's address on a confirmed booking, even though the app itself uses that address behind the scenes
|
||||
- There's no way yet for a customer to submit care instructions themselves — they only exist because the demo data was pre-loaded
|
||||
|
||||
### Patient care plan and nurse visit notes
|
||||
**Who tests this:** customers (manage a patient's care plan); nurses (add visit notes)
|
||||
**Status today:** ❌ Mostly fake/broken — not really testable yet
|
||||
|
||||
Everything shown is fake demo data that resets on reload; the real feature exists behind the scenes but isn't connected yet.
|
||||
|
||||
1. Log in as سارا محمدی (`09120000010`).
|
||||
2. Open her care circle, pick a patient, and open their care record — four tabs appear (medications, daily routine, history, tasks), all filled with sample content.
|
||||
3. Try editing something — note that reloading the page throws your change away; nothing is really saved.
|
||||
4. Log in as زهرا عزیزی (`09120000001`, nurse) and open one of today's visits, scrolling past the check-in/check-out section — you'll find a checklist and a note box, again all fake.
|
||||
|
||||
**What you should see:** both the family's care-plan screen and the nurse's visit-notes screen look fully working and populated, but every field is fabricated sample content, not real saved data.
|
||||
|
||||
**Known issues:**
|
||||
- Patient medical records and nurse visit notes are entirely fake demo data right now (known blocker — see [blockers.md](blockers.md))
|
||||
- If this were switched to real data today, nearly every patient's care plan would show up completely empty, since none have actually been filled in
|
||||
|
||||
---
|
||||
|
||||
## After the visit
|
||||
|
||||
### Cancelling a booking and getting a refund
|
||||
**Who tests this:** customers cancelling a booking; admins processing refunds (currently broken)
|
||||
**Status today:** ❌ Mostly fake/broken — not really testable yet
|
||||
|
||||
The screens you'll see show fake numbers, not what you would actually get back.
|
||||
|
||||
1. Log in as سارا محمدی (`09120000010`).
|
||||
2. Open one of her bookings and tap "Cancel booking" (لغو رزرو).
|
||||
3. Read the explanation of how much would be refunded versus kept as a fee, then continue — these numbers are demo/fake, not calculated from the real booking.
|
||||
4. After confirming, you land on a refund-tracking screen — also fake, not a real refund in progress.
|
||||
5. As an admin (`09120000021`), open a booking-linked support ticket and look for its refund panel — same story, fake data, and the buttons don't actually work.
|
||||
|
||||
**What you should see:** a two-step cancellation flow with a policy explanation, then a refund status tracker, both populated with placeholder numbers unrelated to the real booking.
|
||||
|
||||
**Known issues:**
|
||||
- Refunds are demo/fake data only, not connected to real bookings (known blocker — see [blockers.md](blockers.md))
|
||||
- Admin accounts can't actually process refunds yet (known blocker — see [blockers.md](blockers.md))
|
||||
- Think twice before pressing the final "confirm cancellation" button on a demo account's only remaining bookings — it permanently cancels them for everyone testing with that account
|
||||
|
||||
### Rating and reviewing a nurse after a visit
|
||||
**Who tests this:** customers (write a review); admins (approve reviews — currently broken); anyone (reads published reviews)
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Log in as سارا محمدی (`09120000010`).
|
||||
2. Go to Bookings — only one completed booking shows a "write a review" (ثبت نظر) button; the others already have a review or aren't eligible.
|
||||
3. Tap it, give a 1–5 star rating, optionally add a note and pick some tags, then submit — a notice warns it must be approved before anyone else can see it.
|
||||
4. The screen then shows your review as "pending review" (در انتظار بررسی) — this part is genuinely real and saved.
|
||||
5. Check a nurse's profile "Reviews" tab — only already-approved reviews show up; yours won't appear, because it's stuck waiting on approval.
|
||||
|
||||
**What you should see:** submitting a review actually works for real, but it never becomes publicly visible in this demo because the approval step is broken.
|
||||
|
||||
**Known issues:**
|
||||
- Reviews can never actually get published yet — stuck waiting on admin approval, which is broken (known blocker — see [blockers.md](blockers.md))
|
||||
- A nurse has no screen yet to see reviews written about them
|
||||
|
||||
### Nurse earnings and payouts
|
||||
**Who tests this:** nurses (checking what they're owed); admin/finance (running payout batches — currently broken)
|
||||
**Status today:** ❌ Mostly fake/broken — not really testable yet
|
||||
|
||||
Everything on these screens is fake, even though real payout numbers do exist behind the scenes.
|
||||
|
||||
1. Log in as زهرا عزیزی (`09120000001`, nurse).
|
||||
2. Open her "Finance" page — the one big balance number shown is a fake demo figure.
|
||||
3. Open "Earnings" and click through its tabs — sample bookings appear; tapping "view booking" on any of them leads nowhere, since those bookings don't really exist.
|
||||
4. Open "Payout history" and tap into a payout's detail screen — again fake reconciliation numbers.
|
||||
5. Log in as the finance admin account (`09120000021`) and open the payouts console — the batch list looks normal, but actually running or processing a batch doesn't work.
|
||||
|
||||
**What you should see:** every earnings/payout screen looks fully populated and correct, but none of the numbers come from the real server — they're fixed demo values that never change.
|
||||
|
||||
**Known issues:**
|
||||
- Nurse payout/earnings numbers are unreliable and there's no real way to send money yet (known blocker — see [blockers.md](blockers.md))
|
||||
- Admin accounts can't actually run or process a payout batch yet (known blocker — see [blockers.md](blockers.md))
|
||||
|
||||
---
|
||||
|
||||
## Everything else
|
||||
|
||||
### Messaging & support tickets
|
||||
**Who tests this:** customer, nurse, and admin/support staff
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Log in as the customer, `09120000010` (سارا محمدی).
|
||||
2. Open the support/messages page (linked from the account page). Expect a list of message threads — one open support conversation, a couple of refund-related threads, and several auto-created "booking coordination" threads (one per paid booking).
|
||||
3. Open the support conversation. Expect just the customer/staff messages — any internal staff-only notes never appear here.
|
||||
4. Type a reply and send it. Expect it to appear immediately, then confirm as sent.
|
||||
5. Log in as the nurse, `09120000001` (زهرا عزیزی), and open her support/messages page — same kind of list, nurse's own threads.
|
||||
6. Log in as an admin (`09120000020`) and try the admin support-queue page. Expect it to fail with an access-denied error (known blocker).
|
||||
|
||||
**What you should see:** customers and nurses can view and reply to their own threads normally; the admin/staff side of messaging is currently unreachable.
|
||||
|
||||
**Known issues:**
|
||||
- Admin ticket queue and admin view of a conversation are broken (access denied) (known blocker — see [blockers.md](blockers.md))
|
||||
- The little unread-messages counter in the header never lights up
|
||||
- The inbox list doesn't show a preview of the latest message
|
||||
- Auto-created booking conversations start completely empty, with nothing explaining what they're for
|
||||
- Attaching files to a message isn't available yet
|
||||
|
||||
### Notifications
|
||||
**Who tests this:** customer and nurse (admin has no notification bell)
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Log in as the customer, `09120000010` (سارا محمدی).
|
||||
2. Look at the bell icon in the header. Expect a number badge showing unread notifications.
|
||||
3. Tap the bell to open the notifications page. Expect items grouped by day (today/yesterday/this week).
|
||||
4. Tap a "booking confirmed" notification. Expect it to jump you to that booking, and the badge count to drop by one.
|
||||
5. Tap a notification about a booking request being accepted, rejected, or a missed visit. Expect nothing to happen except it gets marked as read — tapping doesn't take you anywhere (known issue).
|
||||
6. Skip the "mark all as read" button unless you don't mind resetting the shared test data — it can't be undone.
|
||||
7. Log in as the nurse, `09120000001` (زهرا عزیزی), and open her notifications page. Expect mostly "new booking request" notifications, none of which are tappable.
|
||||
8. As an admin, there's no bell and no real notifications page — only a placeholder if you type the address directly.
|
||||
|
||||
**What you should see:** the bell and unread count work, and a handful of notification types link to the right place; most others just sit there once tapped.
|
||||
|
||||
**Known issues:**
|
||||
- Most notification types (11 of 14) don't link anywhere when tapped — including a nurse's "you got paid" notification
|
||||
- Nurses are never notified about payouts at all
|
||||
- All notification text shows in English rather than Persian
|
||||
- "Load more" reloads the whole list instead of adding new items
|
||||
- Admins have no notifications screen worth using
|
||||
|
||||
### Admin backoffice
|
||||
**Who tests this:** admin accounts (super_admin and finance)
|
||||
**Status today:** ❌ Mostly fake/broken — not really testable yet
|
||||
|
||||
Right now every admin account gets an "access denied" error on essentially every real admin action on the
|
||||
server — this is one of the biggest known blockers. The admin screens in the app look fully populated and
|
||||
functional, but that's because almost all of them are showing made-up sample data built into the app, not
|
||||
real information. If that fake layer weren't there, clicking any real action would fail with access denied.
|
||||
|
||||
1. Log in as an admin, either `09120000020` (نگار مدیری, super_admin) or `09120000021` (کامران مالی, finance).
|
||||
2. Browse the admin sections: nurse verification, review moderation, payouts, refunds, support tickets/alerts, platform settings, holidays, audit log, and partner centers.
|
||||
3. Expect most sections to show full, editable-looking data, and "saving" a change to appear to work — but this is all fake, local sample data, not connected to the real system.
|
||||
4. Two sections (the ticket queue and review moderation) actually try to reach the server, and both show a visible error instead of data.
|
||||
|
||||
**What you should see:** a good-looking dashboard that mostly isn't real. Only two screens honestly show that something is broken; the rest hide it.
|
||||
|
||||
**Known issues:**
|
||||
- Admin accounts can't do anything for real yet (known blocker — see [blockers.md](blockers.md))
|
||||
- The "user directory" and "roles" admin screens have no real data behind them at all
|
||||
|
||||
### Partner center
|
||||
**Who tests this:** the partner-center owner (a customer account that also owns a nursing business center)
|
||||
**Status today:** ❌ Mostly fake/broken — not really testable yet
|
||||
|
||||
This section is 100% fake demo data — there's no real business-center account behind it yet.
|
||||
|
||||
1. Log in as the customer, `09120000030` (بهنام رستگار).
|
||||
2. Expect to land on the normal customer home screen — nothing in the app links you to a partner section.
|
||||
3. Type the partner section's address into the browser manually to open it.
|
||||
4. Browse the partner home, sponsored nurses, bookings, and settlement/earnings pages. Expect a business name, license numbers, a nurse roster, bookings, and invoices — all made-up sample data, not the real seeded business center.
|
||||
5. There is no way to actually manage the real center (add/verify/suspend nurses, etc.) — those admin actions also fail with access denied.
|
||||
|
||||
**What you should see:** a polished-looking partner portal where every name and number is fake and disconnected from the real database.
|
||||
|
||||
**Known issues:**
|
||||
- The partner business center is entirely fake demo data (known blocker — see [blockers.md](blockers.md))
|
||||
- Nothing in the app links to this section; you must type the address yourself
|
||||
- There's no separate partner login — it's just a customer account that happens to own a center
|
||||
|
||||
### Account & settings
|
||||
**Who tests this:** every signed-in user — customer, nurse, admin, partner
|
||||
**Status today:** ⚠️ Works, but has known issues
|
||||
|
||||
1. Log in as the customer, `09120000010` (سارا محمدی).
|
||||
2. Open the account page. Expect your name, a masked phone number, an emergency-contact card, and rows for personal info, addresses, language, appearance, notifications, support, and sign-out.
|
||||
3. Toggle the appearance setting (light/dark, «نمایش»). Expect the whole app to repaint instantly and the choice to survive a page reload.
|
||||
4. Change the language. Expect the app to switch language right away.
|
||||
5. Edit your personal info (e.g. last name) and save. Expect a "saved" confirmation and the name to update on screen.
|
||||
6. Tap sign out («خروج از حساب») and confirm. Expect to land on the login screen, with that account fully signed out everywhere, not just this device.
|
||||
7. Log in as the nurse, `09120000001` (زهرا عزیزی), and open her account/settings menu. Expect similar settings, but sign-out here happens on a single tap with no confirmation — be careful.
|
||||
8. As an admin, the account page shows a broken, untranslated label for the admin's role, and every admin section link on it leads to an access-denied error (known blocker).
|
||||
9. The partner account page is only reachable by typing its address manually and shows a fake business name (known blocker).
|
||||
|
||||
**What you should see:** appearance, language switching, editing personal info, and sign-out all genuinely work for a customer and nurse; admin and partner settings inherit the blockers from those areas.
|
||||
|
||||
**Known issues:**
|
||||
- If a customer hasn't saved an emergency contact yet, saving their name or language silently fails with no visible error
|
||||
- The language dropdown inside personal info doesn't actually do anything (only the separate language-switch button works)
|
||||
- Nurse profile pictures never load
|
||||
- Sign-out has no confirmation step for nurse, admin, or partner accounts — one accidental tap fully signs you out
|
||||
- Customers can't upload their own profile picture yet
|
||||
Reference in New Issue
Block a user