Kulcare Docs

Connect Practice QA Runbook

Scope: The manual checks for the Connect practice work. Part A covers what happened and what next, public profiles and the vendor practice. Part B covers practice phase 2: the staff work profile, one bio, vendor offerings, clients, group classes, visits, meal plans, refund requests, onboarding for every role, profile completeness, facility contact verification, fees and availability, vendor policies and attendance, facility numbers, photos and documents, the kulcare-admin screens and owed amounts. Part C covers the gateway contracts and security work. Part D covers the Connect issues run: connections, the Inbox, invite links, onboarding, profiles, the voice code call, referral provenance and the vendor follow-ups.

Issue: #2650 (documentation) · PRs: #2629 (Part A, merged), #2636 (Part B), #2653 (Part C, also inside #2636), #2681 (Part D) · Size: 4 parts, 39 groups

Related: Vendor payments and refunds (user guide) · Onboarding by role · Profile completeness · Onboarding and facility setup

Each case has an id: the part letter, the group number and the case number (for example B-3-2). Report each result against its id, so that each result points to the check that gave it. Mark a case Pass, Fail or Blocked. For each case that does not pass, write what you saw.

S - Setup

Servers and URLs

WhatHow
Connecthttp://localhost:3000/connect (the shell app, pnpm dev:shell in frontend/).
Patient apppnpm dev in patient/. Vite serves it on http://localhost:5173. Connect links to that URL in development. To use a different URL, set VITE_PATIENT_APP_URL for Connect.
Backendhttp://localhost:4000.
OTP and SMSOpen /dev/notifications on the backend. In development the backend sends no real SMS. Each OTP and SMS shows there and in the Slack dev channel.
PaymentsSandbox keys only, for Cashfree and Stripe. Activate the payment account of each test vendor in the sandbox. Never use a production key.

Part A data

  • Test Part A on staging, or locally with the Part B servers. The Part B branch includes the Part A work.
  • Run rake billing:seed_go_forward_plans DEACTIVATE_OTHER_PLANS=1 one time on the environment.

Part B data

  • Test locally. Run the servers from the branch of PR #2636 (feat/connect-practice-phase2), with all its migrations applied.
  • To test old vendor data, run these tasks from backend/. Without CONFIRM=1, each task only prints what it would change.
    • rake catalog:backfill_offering_kind CONFIRM=1
    • rake connect:backfill_vendor_clients CONFIRM=1
  • Use a practice X with a doctor and a nurse (staff), and a second practice Y.

Part B data for B-13 to B-19

  • kulcare-admin: copy admin/.env.example to admin/.env, so that VITE_API_BASE_URL is http://localhost:4000. Run pnpm dev --port 3016 --strictPort in admin/ (the folder at the repo root). Locally, port 3006 is taken by the Hospital app.

  • Platform admin for kulcare-admin: the seeded admin in backend/db/seeds/identity/04_users.rb. TEST_ACCOUNTS.md has no platform admin.

  • CMS: http://localhost:3000/cms (the shell app). The CMS profile settings are at /cms/settings/profile.

  • Facility contact verification: in development, FACILITY_CONTACT_VERIFICATION_ENFORCED is on when it is not set. In production it is off when it is not set. To test the off state, set it to false and restart the backend.

  • Vendor policies of old vendors: run rake connect:copy_vendor_practice_settings from backend/. Without CONFIRM=1, it only prints what it would copy.

  • Refunds in Part B and Part C: use a vendor package of 20.00 with the default commission of 5%, paid in the Cashfree sandbox. Activate the vendor payment account in the sandbox first.

  • Accounts on the dev database: Dr. Raj Kumar (+91 9876543210) is admin of City Hospital Group and owner of the other City Hospital practices; use him as the owner. Dr. James Wilson is not on the dev database. Rani Singh (the seeded nurse) also has a practitioner record, so she sees a practitioner profile; for B-1 and the other staff checks, invite a staff-only user.

  • Connect links to the patient app on http://localhost:5173. If the patient app runs on 5180, start Connect with VITE_PATIENT_APP_URL=http://localhost:5180.

  • Start the backend with LAUNCHY_DRY_RUN=true, so that dev emails do not open browser tabs. Every email and SMS also shows in /dev/notifications.

  • A code limit ("Too many tries") affects only that code panel. If the whole app shows a "Rate Limited" screen, report it as a failure.

Part C data

  • Test locally from the branch of PR #2636 (feat/connect-practice-phase2). It holds all of PR #2653 (fix/marketplace-gateway-contracts), so you can also test from the PR #2653 branch alone.
  • Cashfree: sandbox keys only, and the BILLING_CASHFREE_ENABLED feature flag on. Use a vendor package of 20.00 with the default 5% commission: the order is 2000 paise, the vendor share 1900, the commission 100.
  • Webhooks: run the backend on port 4000 and the dev tunnel (bin/dev-tunnel run, see docs/guides/local-webhook-tunnel.md). Set MARKETPLACE_WEBHOOK_BASE_URL to your tunnel URL, or local orders get no notify_url.
  • Support refunds: use "Support refund" in kulcare-admin, or call POST /billing/marketplace/orders/<MKT- order id>/refund as a platform admin with { idempotency_key: <new UUID>, amount_minor, reason }.
  • Read the refund ledger and the owed rows in the Rails console: Billing::MarketplaceRefund and Billing::MarketplaceVendorOwedAmount.
  • Emails and SMS show in /dev/notifications on the backend. The Connect shell runs on http://localhost:3000 and the patient app on http://localhost:5173.
  • A check that says "Cashfree dashboard", "Stripe dashboard" or "a person" needs a person with access to that dashboard or a signed test tool. Mark it Blocked when you do not have that access.

Accounts

Use the seeded accounts in backend/db/seeds/identity/TEST_ACCOUNTS.md. The passwords are in that file. Seeds exist only on developer machines. On staging, use staging accounts.

Role in the checksSeeded account
Doctor at practice XDr. Raj Kumar, dr.raj.kumar@example.com, +91 9876543210 (City Hospital; also at MedCare)
Nurse (staff) at practice XRani Singh, rani.nurse@cityhospital.com, +91 9876543212 (City Hospital Group, facility staff)
User at practice Y, with no role at XMaria Garcia, maria.reception@medcare.com, +91 5551234557 (MedCare)
OwnerDr. James Wilson, +91 9876543219 (Dr. Smith's Practice)
Practitioner with no practicestate.a.practitioner@example.com, +91 5555556000
Patientjohn.doe.patient@gmail.com, +91 9876543211 (the seeds also make this account a practitioner and staff)

Most checks need new users: a new owner, practitioner, staff member or vendor. Sign up with an unused +91 5 number and get the OTP from /dev/notifications.

Part A - What happened, profiles and the vendor practice (#2629)

A-1 What happened and what next

  • A-1-1 Sign up as a Doctor and finish onboarding. Make sure that the dashboard shows "What just happened", with the documents sent for review and up to three next steps. The Verification tile says "In review".
  • A-1-2 Close the "What just happened" card and reload the dashboard. Make sure that the card does not show again.
  • A-1-3 Skip a step in onboarding, then finish. Make sure that the "Continue setup" card has a "Continue with " button that names the skipped step and opens it.
  • A-1-4 Open Goals from the dashboard footer, change a goal, and press "Save and return". Make sure that you go back to the dashboard.

A-2 Public profiles

  • A-2-1 As a practitioner, open My profile. Press "View as patients see you". Make sure that /doctor/:id opens in the patient app.
  • A-2-2 Open a colleague from Discover. Make sure that /connect/people/:slug shows their profile.
  • A-2-3 As a vendor with payments not active, open My profile. Make sure that it says the page goes live when payments are active, and that there is no live link.
  • A-2-4 Activate the payment account of the vendor in the sandbox. Make sure that the listing becomes public and that "View public page" opens /vendors/:slug.
  • A-2-5 Turn "Show in search" off. Make sure that the page stays private after payments activate.
  • A-2-6 As staff, open My profile. Make sure that it shows "Who can see you" and your facilities.
  • A-2-7 Approve the KYC of a vendor on staging (#2204). Sandbox KYC stays "pending", so do this step before A-2-4 and A-3-2 on staging. A-2-5 needs a vendor whose payments are not active, so use a second vendor for A-2-5:
    1. As the vendor, submit the KYC form on the Payments page. The status shows "pending".
    2. Sign in to kulcare-admin as a platform admin. Open Vendors.
    3. Set the filter to "KYC pending". Open the vendor.
    4. In the "Payment account" card, press "Mark KYC approved".
    5. Read the dialog. Make sure that it says the action is for testing environments only. Press "Mark approved".
    6. Make sure that a toast says "KYC approved. The vendor page is live."
    7. Make sure that the status is "Active" and that the "Mark KYC approved" button is gone.
    8. As a patient, open /vendors/<vendor-slug>. Make sure that the working days show and that you can book a slot. The Cashfree sandbox does not know about the approval, so it can refuse a paid package order for this vendor.
    9. In kulcare-admin, open Audit, then Activity Logs. Make sure that a mark_kyc_approved row shows your user and the vendor.
    • Do not do this step on production. There the button does not show and the endpoint answers 404.
    • The button also does not show when the backend uses the live Cashfree account, or when the vendor is not on Cashfree.

A-3 Vendor practice

  • A-3-1 Sign up as a vendor, add two offerings in onboarding, and finish. Make sure that the offerings are on the offerings page and that Payments does not ask for a second wizard. The sidebar name of the offerings page follows the vendor category, for example "Classes" or "Sessions".
  • A-3-2 As a patient, book a vendor slot. Make sure that the booking shows on the Schedule of the vendor with the client name, and that the client shows on Clients.
  • A-3-3 Sign in as a second vendor. Make sure that you see none of the bookings, clients or payments of the first vendor.

A-4 Owner and billing

  • A-4-1 As a CMS owner from before #2613, open /connect. Make sure that Connect does not offer you a second practice.
  • A-4-2 As a practitioner with no practice, use Add a facility and create the facility. Make sure that you have a physician role at the new facility.
  • A-4-3 Suspend a practice for compliance. Make sure that billing actions are refused. Then suspend a practice for non-payment. Make sure that billing actions are available.
  • A-4-4 On a suspended practice, make sure that these actions are disabled and show the read-only reason: CMS booking, encounter save, patient save, Hospital admissions, Growth campaign actions.
  • A-4-5 Sign up with a number whose SMS fails. Make sure that the OTP page warns that the code was not sent and highlights Resend.
  • A-4-6 In development, send an OTP to a +91 5 number. Make sure that it shows in /dev/notifications and in the Slack dev channel, and that no SMS goes out.
  • A-4-7 In the Connect sidebar, "Other apps" lists only apps the user can open: a vendor sees no group; an owner sees Facility CMS, Growth CRM and Reports; staff see CMS, and Growth or Reports only with those permissions. Each shown link opens its app.

A-5 Cleanup tasks (staging, dry run first)

  • A-5-1 Run rake identity:delete_empty_draft_tenants. Make sure that it prints the draft tenants it would delete. Run it again with CONFIRM=1. Make sure that it deletes them.
  • A-5-2 Run rake connect:publish_active_vendors. Make sure that it prints the vendors it would publish. Run it again with CONFIRM=1. Make sure that it publishes them.

Part B - Practice phase 2 (#2636)

  • B-1-1 As the nurse, open My profile. Add languages, a qualification and a bio, then save. Reload. Make sure that the values stay. Make sure that Work history shows the role at X with "Verified by Kulcare".
  • B-1-2 As the doctor at X, open the facility page of X. Make sure that "People at your practices" lists the nurse. Open the nurse. Make sure that the colleague view shows the same values, with no connect or refer button.
  • B-1-3 As a user with no role at X, open the facility page of X. Make sure that there is no "People at your practices" list.
  • B-1-4 As a doctor at a facility where no other staff work, open the facility page. Make sure that it shows "No colleagues to show yet."
  • B-1-5 As the nurse, select the 30-day expiry, press "Create link" and copy the link. As a signed-in user from practice Y, open the link. Make sure that the profile shows under "Shared with you."
  • B-1-6 As the nurse, press "Make a new link". Open the old link. Make sure that it shows "This link does not work."
  • B-1-7 Search Connect and the patient app for the nurse. Make sure that the nurse does not show.

B-2 One bio

  • B-2-1 As a doctor, edit the bio on My profile. Make sure that the colleague page and the doctor page in the patient app show the new text.
  • B-2-2 As a vendor, edit the intro on My profile. Make sure that the vendor page in the patient app shows the new text.
  • B-2-3 On My profile, paste a bio of more than 5000 characters. Do this as a doctor, a vendor and a staff member. Make sure that the box keeps all of the text, and that the count under it shows the length in red, for example "5,120 / 5,000 characters". Press Save. Make sure that the save is refused with "Keep your bio to 5,000 characters or fewer." Do the same with the vendor onboarding "Intro for clients" and the doctor onboarding "Short bio". Make sure that Continue keeps you on the step.

B-3 Vendor category words and offerings

  • B-3-1 Onboard a new vendor as a home care nurse. Make sure that the category question shows and that the offerings step defaults to "Home visits". After you finish, make sure that the sidebar says "Visits" and "Visit schedule", and that no screen says "Lamaze" or "Classes".
  • B-3-2 Onboard a trainer. Make sure that the sidebar says "Sessions" ("Class schedule" only when the trainer has a group class), and the dashboard says "sessions", never "classes". Onboard a meal provider and add a meal plan. Make sure that the sidebar says "Meal plans" and "Deliveries". Onboard a wellness vendor. Make sure that the sidebar says "Services".
  • B-3-3 As an education vendor, change the category to "Home care and companions" on My profile. Make sure that the page says the words change, and that the sidebar then says "Visits".
  • B-3-4 In the offerings editor, make one offering of each kind: 1:1 session, group class, home visits, meal plan. Make sure that each kind shows its own fields and that each card shows its kind label.
  • B-3-5 Edit the title of a sold offering. Make sure that the save works. Change the price of a sold offering. Make sure that the editor asks you to duplicate it.
  • B-3-6 As a home_care vendor with no verified registration, mark an offering "Nursing care" and list it. Make sure that the save is refused with a Verify link.

Note: "Visit schedule", "Class schedule" and "Deliveries" show in the sidebar only when the vendor has an offering of that kind.

B-4 Vendor clients

  • B-4-1 Setup: press "Add client" and add two clients by hand. Give one of them a "Due date" key date and private notes.
  • B-4-2 Press "Import", choose a CSV file with 3 rows, and check the preview. Make sure that nothing is saved before you press Import. Press Import. Make sure that the table shows the new rows.
  • B-4-3 Import the same CSV file again. Make sure that it reports 0 added, 0 updated and 3 skipped. Import a CSV file with a bad phone number, for example 12345678 or 3876543210 for +91. Make sure that the preview shows the error with its row number, and that Import adds only the good rows. In "Add client", the same number shows "Enter a valid phone number". On staging, a +91 number that starts with 5 is an SMS test number and is accepted (#2622).
  • B-4-4 Archive one client. Make sure that the table shows 4 active clients. Make sure that search finds a client by name and by phone, and that the key date column sorts.
  • B-4-5 Use a vendor whose payments are active (on staging, "Mark KYC approved" in kulcare-admin). On a client, open "Send booking link" and press "Copy link". Make sure that the link starts with the patient app address (patient-stg.kulcare.com on staging). As a new user, open the link, press "Create account", choose "Register with Email/Password", sign up and enter the code. Make sure that the user returns to the vendor page with "You are linked", and that the client row shows "Linked".
  • B-4-5a As a vendor whose payments are not active, press "Copy link". Make sure that the dialog says the page goes live when payments are active, and that no link is made (#2622).
  • B-4-6 Send a booking link by SMS to a client with a phone number. Make sure that the SMS shows in /dev/notifications. With no DLT template id set, make sure that the SMS option is hidden and that Copy still works.
  • B-4-7 Accept a link from an account whose phone does not match the client row. Make sure that the vendor sees "Confirm link" with the account name. Press it. Make sure that the row shows "Linked".
  • B-4-8 As a second vendor, open Clients. Make sure that none of the clients of the first vendor show.

B-5 Group classes

  • B-5-1 Setup: as a vendor with a group class offering, create a 6-week batch on Tuesday and Thursday at 18:00. Set Seats to 2 in the batch dialog. Open the batch and make sure that it shows 2 seats. A batch keeps the seats it was created with: a later change to the offering's seats does not change it.
  • B-5-2 Create a batch with a date that clashes with a booking. Make sure that the create is refused with the date that clashes, and that no batch is saved.
  • B-5-3 Use three different patient accounts. With each one, enrol in the batch of B-5-1 and pay. Make sure that two users are enrolled and the third is on the waitlist at position 1. Make sure that the vendor sees the roster and the waitlist.
  • B-5-4 Start a checkout for a seat and do not pay. Make sure that the hold ends after 15 minutes and that another person can then take the seat.
  • B-5-5 Move one session to a new date and time. Make sure that each enrolled and waitlisted person gets a notice, and that the session shows at the new time on Schedule.
  • B-5-6 Remove one paid enrolled user and select "Full refund". Make sure that the sandbox shows a full refund and that My classes shows "Cancelled". Make sure that the waitlisted user gets "A seat is free" and can pay within 12 hours.
  • B-5-7 Remove a paid user and select "No refund". Make sure that no refund goes to the gateway.
  • B-5-8 On My classes, make sure that a paid seat shows "Request a refund" and no Cancel action, and that a free seat has Cancel and a waitlist place has "Leave the waitlist".

B-6 Repeat visits and care notes

  • B-6-1 As a patient, request a weekday visit plan at 09:00 for a parent (dependent) and pay. Make sure that the vendor sees a requested plan with "Answer by <date, time>".
  • B-6-2 As the vendor, confirm the plan. Make sure that Schedule shows the next visits and that My visits in the patient app shows them.
  • B-6-3 Request and pay for a second plan, then select "Cancel request" before the vendor answers. Make sure that My visits shows "You cancelled this request. You get a full refund." and that the sandbox shows a full refund.
  • B-6-4 Leave a paid request with no answer for more than 72 hours, or set respond_by in the past. Run Connect::VisitRequestSweepJob.perform_now in the Rails console (the schedule runs it every 15 minutes). Make sure that the request is declined with a full refund and that the buyer gets a notice.
  • B-6-5 As the vendor, pause an active plan for a week, then resume it. Make sure that no visit rows exist in the pause.
  • B-6-6 As the vendor, open a visit on Schedule and add a care note. Make sure that the patient, and the manager who acts for the parent, can read it in Care notes in the patient app.

B-7 Meal plans

  • B-7-1 As a patient, order a Monday, Wednesday and Friday meal plan with an address, a contact phone and dietary notes, and pay. Make sure that the Deliveries page of the vendor lists the patient on the plan days.
  • B-7-2 Pause the plan for one week. Make sure that the Deliveries page leaves out the patient in that week and that the end date moves by 3 deliveries.
  • B-7-3 Try a pause inside the cut-off (24 hours unless the offering sets a different value). Make sure that it is refused.
  • B-7-4 Change the delivery window or the address. Make sure that the change applies from the first delivery after the cut-off.

B-8 Refund requests

  • B-8-1 As a patient, send "Request a refund" for half the price of a meal plan. Make sure that the vendor gets an in-app notice and sees the request on the Payments page.
  • B-8-2 As the vendor, reject the request with no note. Make sure that the form asks for a note. Reject with a note. Make sure that the patient sees the note.
  • B-8-3 Send a new request, then withdraw it. Make sure that the patient sees "You withdrew this request."
  • B-8-4 Send a third request. As the vendor, approve it. Make sure that the patient sees "Refund approved: ." and that the sandbox shows one refund of half the price, in rupees.
  • B-8-5 Send a request for the full remainder. Make sure that the approve dialog says that the refund also ends the meal plan. Approve it. Make sure that, from the next day, Deliveries does not list the patient, and that My meal plans shows "Ended on . You got a full refund."
  • B-8-6 Send a full refund request for a paid class seat that has a waitlist. Approve it. Make sure that the seat is free and that the waitlisted person gets the offer.
  • B-8-7 As a platform admin, call POST /connect/admin/refund_requests/:id/approve on a request that is open 3 days. Make sure that it answers 422 REFUND_REQUEST_NOT_OVERDUE. Call it on a request that is open 8 days. Make sure that the approve works.

B-9 Account deletion (development only, no screen)

  • B-9-1 In development, make a patient who is a linked client of two vendors, with an enrolled seat, an active visit plan with care notes, an active meal plan and a pending refund request. Run Identity::User.find(<id>).destroy! in the Rails console.
  • B-9-2 Make sure that the destroy succeeds. Make sure that the Clients page of each vendor shows "Deleted user" with no contact details, and no "Send booking link" or "Confirm link" action.
  • B-9-3 Make sure that the vendor can still read the care notes, the client notes and the dietary notes, and that the visit plan and the meal plan have no address or phone.
  • B-9-4 Make sure that the seat is cancelled and that the waitlist moves up. Make sure that the visit plan and the meal plan have ended. Make sure that the refund request is still pending and that the vendor can approve it.

B-10 Onboarding for every role

For B-10-1 to B-10-3, use an owner who finished onboarding, for example the new owner from B-10-4.

  • B-10-1 Sign in as the owner. Make sure that the dashboard opens, with no onboarding and no card to continue a facility. Press "Add a facility", type a name, press Continue, then press "Do this later". Make sure that the dashboard button reads "Continue adding a facility to ". Make sure that the rail in the flow reads "Adding a facility" with "to " under it.
  • B-10-2 In that run, press "Stop adding this facility", then "Stop adding". Make sure that the dashboard opens with "The facility was not added." Sign out and sign in again. Make sure that the dashboard opens with no onboarding.
  • B-10-3 On the Stop confirm, press "Keep going". Make sure that the confirm closes and that you stay on the step.
  • B-10-4 Sign up as a new owner. Make sure that the first step shows the owner intro and "Setting up your practice". Finish, sign out and sign in. Make sure that the dashboard opens.
  • B-10-5 Sign up as a new practitioner. Make sure that the first step shows the practitioner intro and "Setting up your professional profile". Finish, sign out and sign in. Make sure that the dashboard opens.
  • B-10-6 Sign up as a new staff member from an invite. Make sure that the first step shows the staff intro and "Setting up your work profile". Finish, sign out and sign in. Make sure that the dashboard opens.
  • B-10-7 Sign up as a new vendor ("Wellness and care provider"). Make sure that the first step shows the vendor intro and that no step asks for a facility type. Finish, sign out and sign in. Make sure that the dashboard opens.
  • B-10-8 As a practitioner who finished onboarding, press "Add a facility". Make sure that the rail reads "as a new practice" or names your practice. Type a name, press Continue, then press "Do this later". Sign out and sign in. Make sure that the run opens again at its step.
  • B-10-9 As an owner who finished onboarding, press "Add a facility" and leave. Do not type anything. Sign out and sign in. Make sure that the dashboard opens, not the run.
  • B-10-10 On the first step, press Continue, then Back. Make sure that the intro is one line, "What happens in this setup". Press it. Make sure that the full intro opens again.

B-11 Saved details, profile and email

  • B-11-1 Open each onboarding step. Make sure that each grey example text starts with "e.g.", for example the placeholder of the facility name field.
  • B-11-2 As a practitioner, skip Practice. On My profile, change your bio. Add a registration with its council. Open /connect/onboarding/practice. Make sure that Practice shows the new bio, and the registration number with its council.
  • B-11-3 On that Practice step, type a new bio and press Continue. Open the step again. Make sure that your typed bio shows. Leave it unchanged and press Continue. Make sure that no save goes to your profile unless you changed the bio.
  • B-11-4 As a practitioner, open Verify from the dashboard. Make sure that the documents you already sent show as "Already sent: ...", that a rejected document is not in that list, and that Continue with no new file does not change your review status.
  • B-11-5 As a staff member in a flow that is not finished, go Back to About. Make sure that your name, photo and languages come from your work profile.
  • B-11-6 As a vendor made before phase 2, open About. Make sure that your saved category is selected, and that Continue needs you to press "Keep " or select a different category.
  • B-11-7 As a vendor with offerings, open Offerings. Make sure that the offerings show as read-only rows with a link to the offerings page, and that they count toward the step. Make sure that an old offering with no length does not block Continue.
  • B-11-8 As a vendor, skip Listing, change your intro on My profile, then open Listing from the dashboard. Make sure that it shows the new intro.
  • B-11-9 Start "Add a facility". Make sure that Facility, Address, Team and Operations start blank with "e.g." placeholders. For an existing practice, make sure that Plan shows the current subscription of the practice.
  • B-11-10 On the dashboard "Finish setting up" card, make sure that the "Your account" task names what is missing (for example "Verify your email, add a photo"), and that the card shows how many tasks are done ("N of M done"). Make sure that the main button goes to the first task that has a screen.
  • B-11-11 As an owner who skipped the facility address step, press the dashboard task "Add your facility address". Make sure that it opens the facility profile page, not onboarding.
  • B-11-12 On My profile (practitioner, staff and vendor), make sure that the profile strength card lists each missing item with a link, and that the account card lets you change the photo and the email.
  • B-11-13 On My profile with an email that is not verified, press "Send code". Make sure that the code arrives in /dev/notifications. Enter it and press Verify. Make sure that "Your email is verified" shows and that the dashboard item is ticked.
  • B-11-14 Enter a wrong code. Make sure that it says "That code is wrong. Check it and try again." After 5 wrong codes, make sure that it says "Too many wrong codes. Send a new code." Make sure that "Send a new code" waits 30 seconds before you can press it again.
  • B-11-15 Send a code, then change your email in a different tab before you enter the code. Make sure that the old code no longer verifies.

B-12 Profile completeness

For B-12-1 to B-12-3, use an owner whose facility profile still has missing items, for example the new owner from B-10-4.

  • B-12-1 Sign in as the owner. Make sure that the dashboard shows a task with the facility name, which names the first missing facility items, and a separate "Your account" task. Make sure that no item shows in two tasks.
  • B-12-2 Press the facility task. Make sure that the facility profile opens in edit mode with no "Open this facility" step, scrolled to the first missing field and with that field in focus.
  • B-12-3 On the facility profile, make sure that the completeness card at the top lists "Needed to be found", then "Recommended", and that each item links to its field. Fill one item and save. Make sure that it is ticked.
  • B-12-4 On a new facility, make sure that the address you typed in onboarding fills the edit form, but that the address items stay open until you save.
  • B-12-5 On a facility with no State, edit only the phone or the description. Make sure that the save works. Change the street with no State. Make sure that the save asks for State and puts State in focus.
  • B-12-6 Sign up as a new owner. Make sure that the onboarding Address step asks for State.
  • B-12-7 Add two other specialties with the chips editor, save and reload. Make sure that they stay. Make one of them the primary specialty and save. Make sure that it saves with no error and leaves the other specialties list.
  • B-12-8 Open /connect/facility/<id>/profile for a facility that is not the current one. Make sure that the completeness links stay on that facility.
  • B-12-9 As a practitioner, open My profile. Make sure that the needed items come first: listed in search, a facility role, the primary specialty, the council registration and the verification documents. Make sure that the "Headline and links" section saves the headline, the website and LinkedIn, and that you can add education and work history.
  • B-12-10 As a practitioner with a non-doctor role, make sure that nothing asks for a primary specialty.
  • B-12-11 As staff, open My profile. Make sure that it lists only recommended items: bio, photo, languages, qualifications, work history and education.
  • B-12-12 As a vendor, open My profile. Make sure that the needed items are "Get listed in search" (or "Turn on payments to go live", which links to Payments), the category, the intro and an offering ("Add a class or package", which links to the offerings page).
  • B-12-13 Start onboarding as a new owner and finish Review. Make sure that the facility is selected one time, and that the step does not flash or sign you out.
  • B-12-14 Set a slow network in DevTools. Open the practitioner profile and press Edit before it loads. Save. Make sure that your existing headline and links stay.

B-13 Facility contact verification

  • B-13-1 As the owner, open the facility profile in Connect (/connect/facility/<id>/profile). Make sure that the Contact section shows the saved email and each saved phone with the tag "Unverified" and a "Verify" button.
  • B-13-2 With FACILITY_CONTACT_VERIFICATION_ENFORCED not set, make sure that the line under the Contact title reads "Patients see an email or phone only after you verify it." With the switch set to false, make sure that it reads "Verify each email and phone. Soon patients will see only verified contacts."
  • B-13-3 Press "Verify" on the email, then press "Send code". Make sure that the panel says "We sent a code to ." and that the code shows in /dev/notifications.
  • B-13-4 Type a wrong code and press "Verify". Make sure that the panel says "That code is wrong. Check it and try again."
  • B-13-5 Type the correct code and press "Verify". Make sure that the toast says "The facility email is verified" and that the tag changes to "Verified".
  • B-13-6 Press "Verify" on the Reception phone, then press "Send code". Make sure that the SMS shows in /dev/notifications, and that the panel shows "No code arrived? A landline cannot get an SMS. Contact Kulcare support to verify it by call." On the PR #2681 branch, a +91 number that Kulcare can call shows a different line and a call button. D-11 has those checks.
  • B-13-7 Type the SMS code and press "Verify". Make sure that the toast says "The phone number is verified", and that the other numbers stay "Unverified".
  • B-13-8 Open the panel of one phone, then press "Verify" on a second phone. Make sure that only the panel of the second phone is open.
  • B-13-9 Send a code, then look at the resend link. Make sure that it reads "Send a new code in s" and that you can press it only after 30 seconds. A wait over 90 seconds reads in minutes, for example "Send a new code in 9 min".
  • B-13-10 Send 4 codes to one number in 10 minutes. Make sure that the fourth send shows "Too many tries. Wait a few minutes, then try again." Make sure that no "Rate Limited" screen shows, in this tab or another, and that a profile save right after it works.
  • B-13-11 Press "Edit" and change the Reception number. Make sure that the row shows "Unverified" and no "Verify" button before you save.
  • B-13-12 Save the changed number. Make sure that the toast says "Saved. Verify the new contact before patients see it." and that the row now has a "Verify" button.
  • B-13-13 Change only the type of a verified number, from "Reception" to "OPD", and save. Make sure that the number stays "Verified".
  • B-13-14 Set the facility email to your own verified sign-in email and save. Make sure that the email shows "Verified" at once, with no code.
  • B-13-15 Type a phone number with letters, for example 98765abc10, and save. Make sure that the save is refused with Phone numbers can hold only digits, spaces, "+", "-", "." and brackets.
  • B-13-16 Remove every phone number and save. Make sure that, in view mode, "Public phone numbers" reads "No numbers to show" and the list reads "No phone numbers added. Edit this profile to add one."
  • B-13-17 Sign in as the nurse at X (no "Manage facilities" permission) and open the facility profile. Make sure that the tags show, and that no "Verify" button, no "Edit profile" button and no completeness card show.
  • B-13-18 As an owner with no verified phone, open the Connect dashboard. Make sure that the facility task names "Verify a phone number". Press it. Make sure that the page scrolls to the "Verify" button of the first unverified phone.
  • B-13-19 As an owner with an unverified facility email, open the facility completeness card. Make sure that "Verify the facility email" is under "Recommended".
  • B-13-20 In the CMS, open /cms/settings/profile as the owner. Make sure that each email and phone shows "Verified" or "Unverified", and that the "Verify" flow works as in B-13-3 to B-13-7. Give the facility two "Reception" numbers in Connect first: the CMS shows the second under "Other phone numbers", and a CMS save keeps both in the database.
  • B-13-21 In the CMS, as an owner with an unverified contact and the switch on, open any page. Make sure that the banner reads "Patients cannot see your facility email or phone until you verify them."
  • B-13-22 Set the switch to false and restart the backend. Make sure that the CMS banner reads "Verify your facility email and phone numbers. Soon patients will see only verified contacts."
  • B-13-23 Press "Verify now" on the banner. Make sure that /cms/settings/profile opens.
  • B-13-24 Press "Close" on the banner and reload the page. Make sure that the banner stays closed in this browser tab session.
  • B-13-25 In the CMS, sign in as the nurse at X. Make sure that the banner does not show.
  • B-13-26 In the CMS, as a user with no account email at a facility with an unverified email, export the patients. Make sure that nothing is sent and that the dialog says "We cannot send the export. Add an email to your account, or verify the facility email in Settings."
  • B-13-27 In kulcare-admin, open the facility (/facilities/<id>), "Basic" tab. Make sure that the "Contact verification" card shows the email and each public phone with "Verified" or "Unverified".
  • B-13-28 In the card, press "Send code" on an unverified phone. Make sure that the toast says "Code sent to . A practice user enters it in the facility profile." and that the code is not on the admin screen.
  • B-13-29 As the owner in Connect, press "Verify" on that phone. Make sure that the panel says "Kulcare support sent a code to . Enter it here." with no "Send code" button.
  • B-13-30 Type the code from /dev/notifications and press "Verify". Make sure that the phone shows "Verified".
  • B-13-31 In the kulcare-admin card, press "Verified by call" on an unverified landline. Make sure that the dialog "Mark the phone verified by call" opens. Press "Mark verified". Make sure that the toast says " is verified by call."
  • B-13-32 Make sure that the admin card row now reads "Verified by call on <date, time> by ", and that the facility email row has no "Verified by call" button.
  • B-13-33 As the owner, open the facility profile and the dashboard. Make sure that the landline shows "Verified" and that the phone task is done.
  • B-13-34 With the switch on, open the public booking page of the facility and search for the facility in the patient app. Make sure that no unverified phone or email shows.
  • B-13-35 Verify a phone, then run bin/rails typesense:reindex_collection[facilities] and bin/rails typesense:reindex_collection[practitioners]. Make sure that search now shows the verified phone.
  • B-13-36 Set the switch to false, restart, and run the two reindex commands. Make sure that public search shows the unverified phone again, and that Connect still shows the tags and the "Verify" buttons. Set the switch back.
  • B-13-37 Set "Public phone numbers" to "Hidden from patients" and save. Make sure that public search and the booking page show no facility phone, verified or not.
  • B-13-38 Book an appointment for tomorrow at a facility with a verified phone. In the Rails console, run Clinical::AppointmentReminderJob.perform_now(<appointment id>, :day_before). Make sure that the reminder SMS shows in /dev/notifications with the facility phone.
  • B-13-39 Do B-13-38 again at a facility with no verified phone. Make sure that the SMS has no facility phone and never contains the word "true".
  • B-13-40 Book a public appointment at a facility with no verified phone. Make sure that the confirmation SMS in /dev/notifications has no phone and no "true".
  • B-13-41 At a facility with an unverified phone, email a prescription to a patient. Make sure that the email shows no facility phone. Print the same prescription in the CMS. Make sure that the print shows the saved phone.
  • B-13-42 At the same facility, email an invoice to the patient, then download the same invoice in the CMS. Make sure that the email shows no unverified phone, and that the download shows the saved phone on its "Phone:" line.
  • B-13-43 Run bin/rails identity:facility_contacts:coverage. Make sure that it prints "Active facilities", "With a verified phone", "With a verified email" and "With both", with counts that match the facilities you verified. Make sure that it changes no data.
  • B-13-44 Run bin/rails identity:facility_contacts:notify_unverified. Make sure that it prints "Facilities notified", "Emails sent" and "Emails failed". Run it again. Make sure that "Emails sent" is 0.

B-14 Fees and availability

  • B-14-1 As Dr. Raj Kumar, open My profile in the sidebar, then "Fees and availability". Make sure that /connect/fees-and-availability opens with the title "Fees and availability" and a "Facility" picker with City Hospital and MedCare.
  • B-14-2 As a vendor, open /connect/fees-and-availability. Make sure that the page says "This page is for practitioners" with a "Back to dashboard" button, and that the sidebar has no "Fees and availability" entry.
  • B-14-3 Under "Consultation fees", type 500 for "In person", turn "Video" off, and press "Save fees". Make sure that the toast says "Fees saved for " and that the values stay after a reload.
  • B-14-4 Type 0 for "In person" and save. Make sure that the save works and that the fee shows 0 after a reload.
  • B-14-5 Type abc as a fee and press "Save fees". Make sure that the form says "Type an amount in numbers, for example 500. Type 0 for a free visit."
  • B-14-6 Select the other facility in the picker. Make sure that the address changes to ?facility=<id> and that the page shows the fees, hours and leave of that facility only.
  • B-14-7 Under "Weekly hours", select Mon and Tue, 09:00 to 13:00, slot length 15 min, and press "Add hours". Make sure that the toast says "Hours added" and that the row shows "09:00 to 13:00" and "15 min slots".
  • B-14-8 Add hours on Mon from 12:00 to 14:00. Make sure that the form shows the server message "Schedule (...) overlaps with existing availability on Mon (...)" and keeps your values.
  • B-14-9 Add hours with no day selected. Make sure that the form says "Select one day or more." Add hours with the end before the start. Make sure that it says "The end time must be after the start time."
  • B-14-10 Press "Edit" on a row, change the end time and press "Save hours". Make sure that the toast says "Hours changed". Press "Remove". Make sure that the toast says "Hours removed".
  • B-14-11 Under "Leave", select "Dates", set the first day and the last day, and press "Save leave". Make sure that the toast says "Leave saved" and that the summary reads "On leave from to ."
  • B-14-12 Select "Until further notice" and save. Make sure that the summary reads "On leave until further notice." Press "Remove leave". Make sure that it reads "No leave set."
  • B-14-13 Set a last day before the first day. Make sure that the form says "The last day must be on or after the first day."
  • B-14-14 As the owner, take the "Manage practitioners" permission away from the practitioner role. As the practitioner, open the page. Make sure that the Leave section is read-only and names the permission that can change it.
  • B-14-15 Open the page at a suspended practice. Make sure that every section is read-only.
  • B-14-16 As a practitioner with no fees at a facility, press "Set your consultation fees" on My profile. Make sure that the page opens at the fees section with that facility selected.

B-15 Vendor policies, reach and class attendance

  • B-15-1 As a vendor, press "Policies" in the sidebar. Make sure that /connect/policies opens, and that "What clients see" says "Clients see no policies yet. Choose them above, then save."
  • B-15-2 As a practitioner, open /connect/policies. Make sure that the page says "Policies are for wellness vendors".
  • B-15-3 Set "Clients can cancel a booking up to" to "24 hours before" and "Refund on cancellation in time" to "50% refund". Make sure that "What clients see" shows "Save to update".
  • B-15-4 Press "Save". Make sure that the toast says "Your policies are saved. Clients see them now." and that "What clients see" lists "Cancellation: Up to 24 hours before the start" and "Refund if you cancel in time: 50% refund".
  • B-15-5 Press "Add a closure" and set a last day before the first day. Make sure that the row says "The last day must be on or after the first day." and that "Save" is disabled.
  • B-15-6 Add a closure from today to tomorrow with the note "Diwali break" and save. In the patient app, open the vendor page. Make sure that the "Policies" card shows a "Closed" line with the dates and "(Diwali break)".
  • B-15-7 In the patient app, open a package of the vendor and a class batch of the vendor. Make sure that each page shows the " policies" card.
  • B-15-8 Under "Reach", set "City" to "Bengaluru" and save. In the patient app vendor list, type "bengaluru" in "City". Make sure that the vendor shows. Type another city. Make sure that the vendor does not show.
  • B-15-9 Open the vendor page in the patient app. Make sure that it shows "Works in Bengaluru." and that the radius and the localities do not show.
  • B-15-10 Change a policy and do not save. Go to another tab of the browser and come back. Make sure that your unsaved change stays.
  • B-15-11 As a patient, open "Request a refund" on an order of the vendor. Make sure that the dialog shows the current refund policy of the vendor. As the vendor, open the approve dialog. Make sure that it shows "Your current refund policy. ".
  • B-15-12 Sign up as a new vendor, set policies and a city in onboarding, and finish. Make sure that the Policies page shows the same values.
  • B-15-13 Run rake connect:copy_vendor_practice_settings from backend/. Make sure that it prints "[vendor_practice_settings] dry run (CONFIRM=1 writes)" and a summary line "copied=N skipped_saved=N skipped_empty=N failed=N", and writes nothing.
  • B-15-14 Run the task again with CONFIRM=1. Make sure that the copied vendors show their policies on the Policies page. Run it a third time. Make sure that copied=0.
  • B-15-15 Open a published class batch whose next session starts in more than 1 hour. Make sure that the session has no "Attendance" button.
  • B-15-16 On a session that starts in less than 1 hour, or that has started, press "Attendance". Make sure that the "Attendance" dialog lists the enrolled people with "Present", "Absent" and "Late".
  • B-15-17 Mark one person "Present" and one "Absent", and press "Save attendance". Make sure that the toast says "Attendance saved." and that the marks stay when you open the dialog again.
  • B-15-18 Set the no-show policy to "Charge 50%", then mark a person "Absent". Make sure that the dialog says 'Your no-show policy is "Charge 50%". Kulcare records it with each Absent mark. It does not charge the client.' Make sure that no charge goes to the gateway.
  • B-15-19 Clear the no-show policy, then mark a person "Absent". Make sure that the dialog says "You have no no-show policy. Set one on the Policies page."
  • B-15-20 Select a mark again and save. Make sure that the mark is cleared.
  • B-15-21 Open the attendance of a cancelled session with ?attendance=<session id>. Make sure that the dialog says "This session takes no attendance. It is cancelled, or its batch is not published."
  • B-15-22 On Schedule, select a class session that takes marks. Make sure that the batch page opens with the "Attendance" dialog of that session.

B-16 Facility numbers, photos, documents and the admin document review

  • B-16-1 As the owner, open the facility profile. Under "Registration and licence numbers", press "Add numbers". Add a "State licence" and a "GSTIN", and press "Save numbers". Make sure that the toast says "Numbers saved".
  • B-16-2 Type a GSTIN with a wrong last character. Make sure that the form says "This GSTIN is not valid. It has 15 characters."
  • B-16-3 Add a second "State licence". Make sure that the form says "Add only one State licence."
  • B-16-4 Add an "NABH accreditation". Make sure that its switch is locked on with "Public. An accreditation is always shown." Turn the state licence to private. Make sure that it says "Only owners and admins can see it."
  • B-16-5 Open the profile of a facility outside India in edit mode. Make sure that "GSTIN" is not a type you can select.
  • B-16-6 As the nurse at X, open the facility profile. Make sure that only the public numbers show, with no edit controls and no "Verification documents" section.
  • B-16-7 As the owner, under "Photos", press "Add photos" and add 3 JPEG photos. Make sure that the toast says "3 photos added", the meta reads "3 of 12", and "Add at least 3 photos" is ticked.
  • B-16-8 Add a 6MB photo. Make sure that the page says " is larger than 5MB." Add a GIF. Make sure that it says ": use a JPEG, PNG or WebP image."
  • B-16-9 Press "Move photo 1 later", and type a caption. Make sure that the order and the caption stay after a reload.
  • B-16-10 Press "Remove photo 1". Make sure that the dialog "Remove this photo?" opens. Press "Remove photo". Make sure that the toast says "Photo removed".
  • B-16-11 Open the booking page of the facility in the patient app. Make sure that the photos and the public numbers show, and that the private state licence does not show.
  • B-16-12 Under "Verification documents", press "Upload a document" with no document type. Make sure that the page says "Choose the document type first."
  • B-16-13 Select "Licence" and upload a PDF. Make sure that the toast says "Document sent. Kulcare will check it." and that the row shows "Waiting for a check".
  • B-16-14 Upload an 11MB PDF. Make sure that the page says " is larger than 10MB." Upload a .docx file. Make sure that it says ": use a PDF, JPEG, PNG or WebP file."
  • B-16-15 In kulcare-admin, open the facility, "Documents" tab. Make sure that the document shows "Waiting". Press "Open". Make sure that the PDF opens in a new tab.
  • B-16-16 Press "Reject" and press "Reject document" with no reason. Make sure that the dialog says "Write the reason. The facility owner reads it in Connect."
  • B-16-17 Type a reason and reject. Make sure that the toast says " rejected", and that the owner gets the notice ": document not accepted" with the reason.
  • B-16-18 As the owner, open the documents. Make sure that the row shows "Not accepted" and "Reason: ".
  • B-16-19 Upload a second document. In kulcare-admin, press "Verify". Make sure that the owner gets ": document verified", that the row shows "Verified" with no "Remove", and that "Get a verification document checked" is ticked.
  • B-16-20 Upload a third document, then press "Remove" and "Remove document". Make sure that the toast says "Document removed", and that kulcare-admin shows "Removed by the facility" with no "Verify" or "Reject" button.

B-17 kulcare-admin refund requests and practitioner verification code

  • B-17-1 In kulcare-admin, open "Refund Requests" under "Billing". Make sure that /billing/refund-requests lists the requests with the columns "Requested", "Client", "Vendor", "Offering", "Requested amount" and "Status".
  • B-17-2 Select "Overdue only". Make sure that only requests that are open more than 7 days show, each with an "Overdue" tag. Press a vendor name. Make sure that the list shows only that vendor and a "Vendor: " chip.
  • B-17-3 Open a pending request that is open less than 7 days. Make sure that "Approve and refund" and "Reject" are disabled, with "The vendor decides first. Kulcare support can decide this request from <date, time>."
  • B-17-4 Open a pending request that is open more than 7 days. Press "Reject" with no note. Make sure that the dialog says "Write why. The client and the vendor read this note." Type a note and reject. Make sure that the page says "Rejected."
  • B-17-5 On another overdue request, press "Approve and refund", then "Approve and refund ". Make sure that the page says "Approved. The gateway refunds the client." and that the sandbox shows one refund.
  • B-17-6 On an overdue request, press "Support refund". Type an amount above "Left to refund". Make sure that the dialog says "Only is left to refund on this order."
  • B-17-7 Type the requested amount and a reason, then press "Continue" and "Refund ". Make sure that the page says "Refunded . is left. The refund request is closed as refunded by Kulcare support."
  • B-17-8 Make a support refund that is less than the requested amount. Make sure that the request stays pending.
  • B-17-9 Make sure that the footer of the detail page says "Kulcare records every view and action on this page with your name in the admin access log."
  • B-17-10 Open a practitioner (/practitioners/<id>) with an unverified phone. Press "Send verification code" under "Phone Number". Make sure that, on this branch, the toast says "This server cannot send a verification code yet." and the button goes away. The endpoint comes with PR #2648.
  • B-17-11 With PR #2648 merged, press "Send verification code". Make sure that the card says "Code sent to + . It expires at HH:mm. The doctor enters it when they sign in.", and that the SMS shows in /dev/notifications.
  • B-17-12 With PR #2648 merged, make sure that the button reads "Send again in s" for 60 seconds after a send.

B-18 Vendor payments: owed amounts and the gateway choice

  • B-18-1 As a vendor with no owed amount, open Payments. Make sure that no "Owed to Kulcare" section shows.
  • B-18-2 Approve a full refund on a Cashfree order of 20.00 before the vendor settlement. Open Payments. Make sure that "Owed to Kulcare" shows "The Kulcare fee part of a refund", "Order · " and ₹1.
  • B-18-3 Make sure that the section text starts with "A refund comes out of your share of the payment." and ends with "You do not need to do anything now."
  • B-18-4 Sign in as a second vendor. Make sure that the "Owed to Kulcare" rows of the first vendor do not show.
  • B-18-5 With the BILLING_CASHFREE_ENABLED feature flag on, sign up a new vendor in India and open Payments. Make sure that the page does not ask "Choose your payment provider" and opens the Cashfree form at once, with no Razorpay choice.
  • B-18-6 Open Payments as an India vendor that has a Razorpay provider with no active account. Make sure that the page opens the Cashfree form.

B-19 Refund request changes

  • B-19-1 Approve a refund request. Approve it again from a second browser tab. Make sure that the second approve says "This request is already closed." and that the sandbox shows one refund only.
  • B-19-2 Keep a support refund open with no clear answer. This step needs a person (stop the gateway call after it went out). As the vendor, approve a refund request on the same order. Make sure that the dialog says "An earlier refund on this order has no clear result yet. Try again in a few minutes. If this message stays, contact Kulcare support."
  • B-19-3 While that support refund is open, press "Support refund" again with a new key. Make sure that the answer is 409 REFUND_IN_PROGRESS and that the sandbox shows no second refund.
  • B-19-4 Make a refund of an approved request end FAILED at the gateway (a signed REFUND_STATUS_WEBHOOK with refund_status FAILED, from a test tool). This step needs a person. Make sure that the request is pending again.
  • B-19-5 After B-19-4, make sure that the vendor and the buyer each get the notice "The refund of for failed at the payment gateway. No money went back." In Connect, make sure that the label is "Refund request open again".
  • B-19-6 After B-19-4, as the vendor, press "Reject" on the request. Make sure that the dialog says "The refund of this request failed at the payment provider, so you cannot reject it. Approve it again, or contact Kulcare support."
  • B-19-7 After B-19-4, approve the request again. Make sure that the sandbox shows a new refund whose id ends in _a2, and that the request closes as approved.
  • B-19-8 In kulcare-admin, open a request whose approve got no clear answer. Make sure that the page shows "An approve of on this order got no clear answer, and the money may have moved." and a "Check with the gateway" button.
  • B-19-9 Press "Check with the gateway" less than 15 minutes after the last try. Make sure that the answer says "The last try of this refund was less than 15 minutes ago, and it may still reach the gateway. Check again later."
  • B-19-10 Press "Check with the gateway" after 15 minutes, for an approve that the gateway has. Make sure that the page says "The gateway has this refund of . Kulcare recorded it. The request is closed as approved by Kulcare support."
  • B-19-11 Do B-19-10 for an approve that the gateway does not have. Make sure that the page says "The gateway has no refund from this approve. The request stays pending, and it can be approved again."
  • B-19-12 Remove a paid class seat with "Full refund", and make the refund end FAILED at the gateway (as in B-19-4). Make sure that the roster shows "Refund failed" on the seat. Remove the seat again with "Full refund". Make sure that the refund goes out.

Part C - Gateway contracts and security (#2653)

C-1 Cashfree marketplace refunds

  • C-1-1 Pay an order of 20.00 in the Cashfree sandbox. Make a support refund of 5.00. Make sure that the answer has remainder_minor 1500, and that the Cashfree dashboard shows one refund of 5.00 with a vendor split of 5.00.
  • C-1-2 After C-1-1, make sure that the order is still succeeded (not refunded) and that no owed row exists for the order.
  • C-1-3 Make a second support refund of 5.00 with a new key. Make sure that the Cashfree dashboard shows two refunds, that the ledger has two rows, and that remainder_minor is 1000.
  • C-1-4 Send the call of C-1-3 again with the same key and the same amount. Make sure that the answer has meta.replayed: true and that the Cashfree dashboard shows no new refund.
  • C-1-5 Send the same key with another amount. Make sure that the answer is 422 IDEMPOTENCY_KEY_REUSED.
  • C-1-6 Send a refund of 10.01 with a new key. Make sure that the answer is 422 with "The refund amount is more than what is left to refund on this order, so no refund went out."
  • C-1-7 Send a refund of exactly 10.00 (the remainder) with a new key. Make sure that Cashfree gets a refund of 10.00 with a vendor split of 9.00, and that the order becomes refunded.
  • C-1-8 After C-1-7, make sure that one owed row exists with amount_minor 100, reason commission_part and status open, and that the answer has meta.service_ended: true.
  • C-1-9 Send one more refund on the order of C-1-7. Make sure that the answer is 409 and that Cashfree gets no new refund.
  • C-1-10 Make a refund of a new order end FAILED at Cashfree. This step needs a person (Cashfree dashboard, or a signed REFUND_STATUS_WEBHOOK with refund_status FAILED from a test tool). Send the refund again with the same key. Make sure that a new refund goes out with an id that ends in _a2.
  • C-1-11 On an order with a full refund and an open owed row, deliver a signed REFUND_STATUS_WEBHOOK that moves the refund from PENDING to FAILED. This step needs a person. Make sure that the ledger row is failed, the owed row is void, and the order is succeeded again.
  • C-1-12 After C-1-11, make sure that the refunded amount of the order is lower by the failed refund. Make sure that the vendor no longer sees the row in "Owed to Kulcare".
  • C-1-13 Deliver the same FAILED webhook again. Make sure that the answer is 200 with duplicate: true and that no data changes.
  • C-1-14 Keep a support refund open with no clear answer (a person stops the gateway call after it went out). Send a support refund with another key. Make sure that the answer is 409 REFUND_IN_PROGRESS with "Another support refund on this order has no clear result yet. Only that refund can be sent again."
  • C-1-15 In the Cashfree dashboard, refund 2.00 on a paid order. This step needs a person. Run REFUNDS=1 bin/rails billing:marketplace:reconcile. Make sure that it prints "Marketplace reconcile (dry run: nothing written)" and a scope R row with record_gateway_refund for the order.
  • C-1-16 After C-1-15, make sure that the task prints a "CSV: tmp/marketplace_reconcile_.csv" line and that the ledger has no new row.
  • C-1-17 Run CONFIRM=1 REFUNDS=1 bin/rails billing:marketplace:reconcile. Make sure that the ledger has a gateway_dashboard row of 200 for the order. Run the dry run again. Make sure that the order has no scope R row.
  • C-1-18 On an order with a dashboard refund that Kulcare did not record, make a full support refund. Make sure that Kulcare first records the dashboard refund, and that Cashfree gets only the exact remainder.
  • C-1-19 Refund an order in full in the Cashfree dashboard (a person). Make a support refund of it. Make sure that the answer is 409 with "The gateway shows this order refunded in full already, so no new refund went out. Kulcare recorded the refunds that the gateway shows."
  • C-1-20 Refund in full an order whose vendor share Cashfree settled (on or after the settlement day). This step needs the Cashfree sandbox and a person. Make sure that Cashfree gets no vendor split and that one owed row of 2000 with reason vendor_share_settled exists.
  • C-1-21 After C-1-20, as the vendor, open Payments. Make sure that "Owed to Kulcare" shows "A refund after your share was paid out" and ₹20.
  • C-1-22 As a patient with an account email, pay an order. Make sure that the checkout success page says "We send a receipt to when the payment is confirmed."
  • C-1-23 After the payment webhook, make sure that one email with the subject "Your Kulcare receipt " shows in /dev/notifications, with "Receipt number", "Vendor" and "Total paid" lines.
  • C-1-24 Send the payment webhook again from the Cashfree dashboard (a person). Make sure that no second receipt email goes out.
  • C-1-25 As a patient with no account email, pay an order. Make sure that the success page makes no receipt promise and that no receipt email goes out.

C-2 Security

  • C-2-1 In the shell, sign in as Dr. James Wilson (owner, Dr. Smith's Practice). Open /account/users, then "Invite Staff Member". Type the phone of Maria Garcia (+91 5551234557, MedCare only). Make sure that it says "No member of this practice has this number. An invite will be sent." with no name or email.
  • C-2-2 In DevTools, read the answer of GET /identity/users/lookup for C-2-1. Make sure that it is 200 with "data": null. Call it again with facility_id of a MedCare facility. Make sure that data is still null.
  • C-2-3 Type the phone of a member of your own practice. Make sure that the matched user card shows the name, as before.
  • C-2-4 Send the invite to Maria Garcia from C-2-1. Make sure that the invite goes out.
  • C-2-5 Turn on SMS 2FA for a shell account whose phone is the mobile of a sandbox ABHA account (/account/security, "Set Up 2FA"). This step needs a person with an ABDM sandbox ABHA account. Make sure that 2FA shows as on.
  • C-2-6 In the patient app, select "ABHA Login", then "Login with Mobile", and enter the ABHA OTP. Make sure that the "Two-step sign-in" screen opens with "Enter the 6-digit code that we sent to ."
  • C-2-7 Type the 2FA code from /dev/notifications and press "Verify". Make sure that the toast says "ABHA login successful" and that the dashboard opens.
  • C-2-8 Do C-2-6 again and type 5 wrong codes. Make sure that the screen says "Account is temporarily locked due to failed attempts" and shows only "Back to sign in".
  • C-2-9 On the "Two-step sign-in" screen, wait for "Resend code in s" to end, then press "Resend code". Make sure that it says "We sent a new code." and that a new SMS shows in /dev/notifications.
  • C-2-10 Do C-2-6 with "Login with ABHA Address" and "Password". Make sure that the "Two-step sign-in" screen opens before the dashboard.
  • C-2-11 Sign in with ABHA for an account with no 2FA. Make sure that the dashboard opens with no "Two-step sign-in" screen.
  • C-2-12 Sign up with a phone number that is not valid. Make sure that the answer is 422 VALIDATION_FAILED with a one-line message and details of {field, message} only. Make sure that the body has no password, no names and no base object.
  • C-2-13 A developer makes the registration service raise an error (console or debugger). Make sure that POST /identity/registrations answers 500 REGISTRATION_FAILED with "We could not create your account. Please try again." and no exception text.
  • C-2-14 In browser 1, sign up phone P as "Real", real@example.com, password Old1234!. Do not verify. In a private window, sign up P again as "Mallory", mallory@example.com, password New1234!. Make sure that the account in the database is still "Real" with real@example.com.
  • C-2-15 After C-2-14, make sure that the second signup answer has meta.signup_token and shows only the fields that the private window sent.
  • C-2-16 In browser 1, sign in with P and Old1234!, and verify the phone with the code from /dev/notifications. Make sure that the name is "Real", the email is real@example.com, and Old1234! still works.
  • C-2-17 Do C-2-14 again with a new phone, and enter the code in the private window that made the second signup. Make sure that the "Mallory" fields apply and that the new email is not verified.
  • C-2-18 Run tail -f backend/log/development.log, then sign up and press Resend. Make sure that the log shows the phone as ***<last 4 digits> and the request params as "phone_number"=>"[FILTERED]".
  • C-2-19 Fail a sign-in with a wrong password. Make sure that the log line shows the identifier as ***<last 4 digits> or <first letter>***@<domain>, and no full phone or email.
  • C-2-20 For one phone from one IP, do 3 signups, 2 Resends and 1 password reset. Make sure that the sixth send answers 429 and that the shell says "Too many attempts. Please try again in a few minutes."
  • C-2-21 In the patient app, send 6 ABHA OTPs for one ABHA address. Make sure that the sixth send answers 429 and that the app says "Too many attempts. Try again in minutes."
  • C-2-22 Start the backend with CODE_SMS_DAILY_CAP_IN=0. Sign up an Indian number. Make sure that the OTP page says "We could not send the code. Try Resend.", that no SMS shows in /dev/notifications, and that the log has tag=code_sms_refused reason=daily_cap_reached country=IN.
  • C-2-23 Start the backend with CODE_SMS_DAILY_CAP_ACCOUNT_IN=0. Sign in as Dr. Raj Kumar (SMS 2FA). Make sure that no 2FA SMS shows in /dev/notifications and that the sign-in does not finish.
  • C-2-24 On /forgot-password, enter a phone, enter the code from /dev/notifications, and set a new password. Make sure that /signin opens with the phone number and the country code filled.
  • C-2-25 Do C-2-24 with an email as the login id. Make sure that the phone field on /signin stays empty. Open /signin directly. Make sure that the form is empty with country code 91.

Part D - Connect issues run (#2681)

Part D data

  • Test locally from the branch of PR #2681 (feat/connect-issues-2650), with all its migrations applied. Run rake reference:seed_medical_councils and rake db:referral_referee_role:provision from backend/ one time on each environment.
  • A check marked staging only needs a staging service: Ably for live updates, MSG91 for a voice call or a real SMS, or the Cashfree sandbox. Locally, mark it Blocked.
  • Doctor 1 and Doctor 2 are two practitioners at two different practices, each with a Connect profile. Use Dr. Raj Kumar as Doctor 1, and a new practitioner who is the owner of practice Y as Doctor 2.
  • To end the 7-day cooldown of D-1 locally, run Connect::ProfessionalConnection.find(<id>).update_columns(rejected_at: 8.days.ago) in the Rails console. To reset the request limit for one pair, run Rails.cache.clear.

D-1 Connection requests after a decline (#2448)

  • D-1-1 As Doctor 1, open /connect/network?tab=discover and press "Connect" on Doctor 2. As Doctor 2, open Network, Requests, and decline the request. Make sure that Discover shows "Connect" again on each side.
  • D-1-2 As Doctor 2 (the person who declined), press "Connect" on Doctor 1 at once. Make sure that the request goes, and that Doctor 1 sees it under Requests.
  • D-1-3 Do D-1-1 again with a new pair. As Doctor 1 (the original sender), press "Connect" on Doctor 2 at once. Make sure that the page says "You can send a new request to this person 7 days after they declined your last one", and that Doctor 2 gets no request.
  • D-1-4 End the cooldown of D-1-3 in the console (see Part D data). As Doctor 1, press "Connect" again. Make sure that the request goes.
  • D-1-5 As Doctor 1, send a request to a new profile, withdraw it, and do this two more times. Send a fourth request in the same 7 days. Make sure that the page says "You can send 3 requests to this person in 7 days. You can send a new request later."
  • D-1-6 In DevTools, copy the POST /connect/connections call of a "Connect" press. Send it again with a message of 501 characters. Make sure that the answer is 422 and that no request is saved. Make sure that a message of 500 characters goes.
  • D-1-7 As Doctor 1, send Doctor 2 a referral, so that Doctor 2 has an Inbox thread from Doctor 1. As Doctor 2, open that thread, press "Block ", then "Block sender". As Doctor 1, press "Connect" on Doctor 2. Make sure that the page shows the request as sent. Make sure that Doctor 2 gets no request, no notice and no push.

D-2 Live connection notices (#2448)

  • D-2-1 Staging only. As Doctor 2, keep Connect open on the dashboard. As Doctor 1, send a request to Doctor 2. Make sure that, with no reload, Doctor 2 gets the notice "<Doctor 1 name> wants to connect with you", and that Network, Requests lists the request.
  • D-2-2 Staging only. As Doctor 1, keep Network open. As Doctor 2, accept the request. Make sure that, with no reload, Doctor 1 gets "<Doctor 2 name> accepted your connection request", and that the network list shows Doctor 2.
  • D-2-3 Locally, do D-2-1 and reload the page of Doctor 2. Make sure that the notice is in the notification list, and that the backend log has no NoMethodError for the notice job.

D-3 Colleague profile privacy (#2650)

  • D-3-1 As Doctor 2, open the colleague page of Doctor 1 (/connect/people/<slug>). Make sure that the page shows no phone number and no email.
  • D-3-2 In DevTools, read the answer for the profile of D-3-1. Make sure that it has no phone_number, no phone_country_code and no email field.
  • D-3-3 Open Discover and read the answer of the search in DevTools. Make sure that each row has no tenant_id, no facility_id, no fee, no phone and no address.
  • D-3-4 As Doctor 1, open My profile. Make sure that your own phone and email still show.

D-4 Profile editors and the colleague page (#2650)

  • D-4-1 As Doctor 1, open My profile. Type dr_raj_kumar as the X handle and save. Reload. Make sure that the handle stays. Type dr raj!. Make sure that the field says "Use 1 to 15 letters, numbers or underscores."
  • D-4-2 Turn on "Open to opportunities". Make sure that the page says "Colleagues see that you are open to opportunities".
  • D-4-3 Edit a job in Work history. Add a location and a description, save and reload. Make sure that both stay. Paste a description of more than 1000 characters. Make sure that the save is refused.
  • D-4-4 Set the years of a specialization to 12, save and reload. Make sure that 12 stays. Type 71. Make sure that the field says "Enter 70 years or fewer." Type ten. Make sure that it says "Enter a whole number of years."
  • D-4-5 As Doctor 2, open the colleague page of Doctor 1. Make sure that it shows the photo, languages, qualifications, total years, the "Open to opportunities" tag, the X link, the job location and description, and the years of each specialization.

D-5 Inbox (#2380, #2464, #2475)

  • D-5-1 Staging only. As Doctor 2, keep /connect/inbox open. As Doctor 1, send Doctor 2 a referral. Make sure that the new message shows in the list with no reload, and that the Inbox count in the sidebar goes up by one.
  • D-5-2 Locally, do D-5-1 and reload. Make sure that the sidebar Inbox entry shows the unread count. Open the message. Make sure that the count goes down.
  • D-5-3 Sign up as a new practitioner and finish onboarding. Open the Inbox. Make sure that it has one message, "Welcome to your Kulcare Inbox". Save My profile again and reload the Inbox. Make sure that there is still one welcome message.
  • D-5-4 Make a thread with more than 50 unread messages (for example, in the Rails console). Open the thread one time. Make sure that the sidebar count goes down by all the unread messages of that thread, not by 50 only. Make sure that the older messages of the thread can still load.
  • D-6-1 As the owner, invite a staff member with phone P1. Copy the invite link from the SMS in /dev/notifications. In a private window, open the link and sign up with a new phone P2. Make sure that, after the code, the account is staff at the facility.
  • D-6-2 After D-6-1, as the owner, open notifications. Make sure that the notice "A new account used your invite link" shows, with the phone masked.
  • D-6-3 After D-6-1, check /dev/notifications. Make sure that a notice to P1 says that another number used the invite. For an Indian number, the SMS waits for DLT entry 24, so the notice goes by email when P1 has an email.
  • D-6-4 Open the same link again and sign up with a third phone. Make sure that the verify page says "Someone already used this invitation. Ask the facility to send a new one." and "Your account is ready, but it has no access to that facility."
  • D-6-5 Cancel a new invite, then sign up from its link. Make sure that the page says "The facility cancelled this invitation. Ask the facility to send a new one."
  • D-6-6 Send a facility admin invite to phone P1. Sign up from its link with phone P2. Make sure that the page says "A facility admin invitation works only with the phone number that got it. Ask the facility to send a new invitation to this number."

D-7 Onboarding lists and documents (#2545, #2498)

  • D-7-1 Sign up as a new Doctor. On the step with "Highest qualification", open the dropdown. Make sure that it lists degrees and "Other". Select "Other". Make sure that a text field opens.
  • D-7-2 On the reach step, select the city "Bengaluru". Make sure that the localities list shows only Bengaluru areas, for example "Koramangala". Select "Mumbai". Make sure that the list changes to Mumbai areas, for example "Andheri". Select "Other city". Make sure that a text field opens.
  • D-7-3 As a Doctor, open the council list. Make sure that medical councils come first, and that NMC is on the list. Do the same as a nurse. Make sure that nursing councils come first.
  • D-7-4 Use the staff account of D-6-4, which has no access to the facility. In onboarding, upload a government ID and press Continue. Make sure that the file stays on the step with "Ready to send: ", and that the page shows "Join your facility before you upload a document". On Review, make sure that the page says "Your account has no link to a facility yet, so we cannot save your languages. Ask the facility to send you a new invitation."
  • D-7-5 As a staff member with an active facility, upload a government ID and press Continue. Make sure that the file uploads and that the step keeps it.
  • D-7-6 As a practitioner, attach a registration certificate and a photo ID on Verify, then press Continue one time. Make sure that the admin verification queue has one submission with both files.
  • D-7-7 Sign in as one practitioner. On My profile, Registrations, add KMC 45812 for a council. With the same account, add kmc-45812 for the same council. Make sure that the second is refused with "You have already recorded this registration number for this council".
  • D-7-8 Sign in as a different practitioner. Add kmc-45812 for the same council as its only registration, and send it for verification. Make sure that the save works: several accounts may claim one number, so the first to type it cannot lock the real holder out. In the admin, open this submission in the verification queue. Make sure that the review dialog says "Another account claims this registration number." and names the first account.

D-8 Practice step (#2545)

  • D-8-1 On the onboarding Practice step, type 71 as the years of a specialty. Make sure that the field says "Enter 70 years or fewer." and that Continue stays on the step. Type 0. Make sure that Continue goes on.
  • D-8-2 In DevTools, block the request URL /connect/specializations. Change a specialty and press Continue. Make sure that a toast says "We kept your specialty here, but could not save it to your profile" and that the step stays open.
  • D-8-3 With the block of D-8-2, press Back, then "Do this later". Make sure that each one goes on with no hold. Remove the block, press Continue, and make sure that the specialty saves.
  • D-8-4 As an account with no professional profile, pick a specialty on Practice and press Continue. Make sure that a toast says "We kept your specialty on this form. Your professional profile is not set up yet, so we did not save the specialty to it." and that the flow goes on.

D-9 Invite modals (shell and kulcare-admin)

  • D-9-1 Start the backend with INVITE_TEXT_PLATFORM_DAILY_LIMIT=1. In the shell, invite two staff members by phone. Make sure that the second modal says "Invite saved, but the text did not go. We cannot send invite texts now. Ask them to sign up with this phone number, or try again later."
  • D-9-2 Start the backend with no limit override. Open "Invite Staff Member" and type the phone of a pending staff invite. Make sure that the button reads "Send the invite again". Press it. Make sure that the modal says the invite exists and "We sent the invite link again."
  • D-9-3 Press "Send the invite again" again within 10 minutes. Make sure that the modal says "We sent the invite link less than 10 minutes ago. Try again later."
  • D-9-4 Do D-9-2 in "Add Doctor" for a pending practitioner invite. Make sure that the same button and texts show.
  • D-9-5 In kulcare-admin, do D-9-1 from the facility invite dialog. Make sure that the toast says "Invite saved, but the text did not go." with the reason.

D-10 Vendor KYC test approval (#2204)

  • D-10-1 Staging only (Cashfree sandbox). Do A-2-7 on staging.
  • D-10-2 In kulcare-admin, open a vendor in state "rejected" or "suspended". Make sure that the "Mark KYC approved" button does not show.

D-11 Voice code call (#2650)

  • D-11-1 As the owner, open the facility profile in Connect and press "Verify" on a +91 phone. Make sure that the panel says "We will send a code to by SMS. For a landline, we can call the number and read out the code." and shows "Send code" and "Call me with the code".
  • D-11-2 Press "Call me with the code". Make sure that the panel says "We called . Enter the code from the call." Locally, no call goes out, and the code shows in /dev/notifications. Type the code and press "Verify". Make sure that the phone shows "Verified".
  • D-11-3 Staging only (MSG91 voice). Do D-11-2 on a real landline (011, 022 or 0172). Make sure that the call reads the code digit by digit, and that the code verifies the number.
  • D-11-4 In the CMS, open /cms/settings/profile as the owner and do D-11-1 and D-11-2. Make sure that the same buttons and texts show. Switch the CMS language to Hindi and Spanish, and make sure that the texts show in that language.
  • D-11-5 Press "Call me with the code" 4 times in one day for the same facility and number. Wait more than 10 minutes between the calls, so that the code limit of B-13-10 does not stop them first. Make sure that the fourth call shows "We cannot call this number again now. Send the code by SMS." Make sure that the call button is off and that "Send code" still works.
  • D-11-6 Staging only (MSG91 voice). Make a call fail (for example, with no voice template in the credentials). Make sure that the panel shows "The call did not go through. Try again in a minute." or "We cannot call this number now. Send the code by SMS, or contact Kulcare support."
  • D-11-7 Press "Verify" on a phone outside India. Make sure that the panel has no "Call me with the code" button.

D-12 Referral provenance (#2462)

  • D-12-1 As Doctor 1, refer a patient with a Kulcare patient account and a birth date to Doctor 2. As Doctor 2, accept the referral.
  • D-12-2 At practice Y, register the same person in the CMS, with the same phone, first name and birth date. As Doctor 2, open the patient. Make sure that the header shows "Referred by" with the name of Doctor 1.
  • D-12-3 As Doctor 1, open the referral in the CMS referrals list. Make sure that it shows "patient registered" with a day ("today", "yesterday" or a date) and no time.
  • D-12-4 As Doctor 1, open Referrals, Sent, in Connect. Make sure that the referral has the tag "Registered", and that its tooltip shows a date with no time.
  • D-12-5 As Doctor 1, send a new referral to Doctor 2. Make sure that Connect shows no "Accept" button on it for Doctor 1. Call POST /clinical/referrals/<id>/accept as Doctor 1. Make sure that the answer is 403 and that the status stays "pending".
  • D-12-6 Register a patient at practice Y first, then send and accept a referral for that patient. Make sure that the patient header shows no "Referred by".
  • D-13-1 As a vendor, open Payments and approve a refund request for a class seat. With no reload, open the class batch. Make sure that the roster shows the change. Go back to Payments. Make sure that the earnings show the refund.
  • D-13-2 Cancel a class session, remove a seat and decline a visit request. After each one, with no reload, open Payments. Make sure that the refund requests and earnings show the new state.
  • D-13-3 Create an online class batch and type meet.google.com/abc as the link. Save. Make sure that the batch holds https://meet.google.com/abc.
  • D-13-4 Type https://user@meet.google.com/abc as the link. Make sure that the form says "Type a full web address, for example https://meet.google.com/abc." and does not save.
  • D-13-5 In the Rails console, give an old batch a bad link (for example javascript:alert(1)). As an enrolled patient, open My classes. Make sure that the class shows "Online. The link from the provider does not work. Ask the provider for a new link." with no link.
  • D-13-6 As a vendor, open the approve dialog of a refund request whose order has no paid amount on record. Make sure that it says "We do not have the paid amount. If this refunds the rest, it also ends the ."
  • D-14-1 As a vendor, open a client and press "Send booking link", then "Copy link". As the patient, sign in to the patient app and open the link. Make sure that the toast says "You are linked with . Book or buy below." and that ?invite= goes off the URL.
  • D-14-2 Open the same link again in a new tab. Make sure that the vendor page shows, that ?invite= goes off the URL, and that the page does not say "This link does not work". Make sure that no second toast shows.
  • D-14-3 Sign in as another patient and open the same link. Make sure that the page says "This link does not work". Sign out and open the link. Make sure that the page says the same.
  • D-14-4 Call POST /connect/client_invites/<token>/accept as the first patient. Make sure that the answer is 200 with "already_accepted": true and the vendor slug. Call it as the second patient. Make sure that the answer is 404 with the same body as for the token not-a-token.

D-15 Push after logout, and signup on a used phone (PR #2702)

Push needs SNS and a phone with the patient or doctor app, so these checks are staging only. Locally, read the identity.devices row in the Rails console instead, and mark the push part Blocked.

  • D-15-1 Sign in on a phone as Doctor 1. Send Doctor 1 a notice that pushes (for example a connection request from Doctor 2). Make sure that the phone gets the push.
  • D-15-2 Log out on that phone. Send Doctor 1 another notice. Make sure that the phone gets no push. In the Rails console, make sure that the device row has no endpoint_arn and that push_signed_out? is true. Make sure that the log has [push] tag=signed_out_skip with the device id only, and no token.
  • D-15-3 Sign in again on the same phone as Doctor 1. Send two notices. Make sure that the phone gets the push again (the first notice asks for the endpoint, so the push can start at the second).
  • D-15-4 Sign in as Doctor 1 on two phones. In the session list of phone 1, revoke the session of phone 2. Make sure that phone 2 gets no push and that phone 1 still gets it.
  • D-15-5 On phone 1, use "log out all other devices". Make sure that only phone 1 still gets the push.
  • D-15-6 Sign in on a phone as Doctor 1. On the same phone, sign up a new account and enter the code. Send Doctor 1 a notice. Make sure that the phone gets no push for Doctor 1. In the Rails console, make sure that the device row of the new account has the newest push_token_claimed_at for that token, and that the row of Doctor 1 has no endpoint_arn. The case in which the new account already had a device row on the phone (an earlier verify that failed) has automated tests only.
  • D-15-7 As the owner, send a practitioner invite to phone P1, so a placeholder record is made. Copy the link. As the owner, send the invite again (the link gets a new token). In a private window, sign up from the old link with phone P2. Make sure that the verify page says "We did not find this invitation." In the Rails console, make sure that the placeholder has no user and that the invite is still pending. The race in which the resend comes after the signup read the link (reason replaced) has automated tests only.

Health Diary Test Pass

Previous Page

Hospital Instruction and Workspace Cleanup Record

Instruction corrections, exact plan preservation, merged-branch evidence, and local recovery files.

On this page

S - SetupServers and URLsPart A dataPart B dataPart B data for B-13 to B-19Part C dataAccountsPart A - What happened, profiles and the vendor practice (#2629)A-1 What happened and what nextA-2 Public profilesA-3 Vendor practiceA-4 Owner and billingA-5 Cleanup tasks (staging, dry run first)Part B - Practice phase 2 (#2636)B-1 Staff work profile and share linksB-2 One bioB-3 Vendor category words and offeringsB-4 Vendor clientsB-5 Group classesB-6 Repeat visits and care notesB-7 Meal plansB-8 Refund requestsB-9 Account deletion (development only, no screen)B-10 Onboarding for every roleB-11 Saved details, profile and emailB-12 Profile completenessB-13 Facility contact verificationB-14 Fees and availabilityB-15 Vendor policies, reach and class attendanceB-16 Facility numbers, photos, documents and the admin document reviewB-17 kulcare-admin refund requests and practitioner verification codeB-18 Vendor payments: owed amounts and the gateway choiceB-19 Refund request changesPart C - Gateway contracts and security (#2653)C-1 Cashfree marketplace refundsC-2 SecurityPart D - Connect issues run (#2681)Part D dataD-1 Connection requests after a decline (#2448)D-2 Live connection notices (#2448)D-3 Colleague profile privacy (#2650)D-4 Profile editors and the colleague page (#2650)D-5 Inbox (#2380, #2464, #2475)D-6 Signup from an invite link with another phone (#2614)D-7 Onboarding lists and documents (#2545, #2498)D-8 Practice step (#2545)D-9 Invite modals (shell and kulcare-admin)D-10 Vendor KYC test approval (#2204)D-11 Voice code call (#2650)D-12 Referral provenance (#2462)D-13 Refund caches and class meeting links (#2636 follow-ups)D-14 Accepted invite link opened again (PR #2702)D-15 Push after logout, and signup on a used phone (PR #2702)