Nâng cấp tài khoản phòng khám
Nhiều phòng khám vào hệ thống dưới dạng danh tính nhẹ — không tài khoản, khoá theo số điện thoại — khi lần đầu đặt đơn qua QR hoặc được labo mời. Đến lúc muốn kiểm soát truy cập theo vai (RBAC), quản hoá đơn và người dùng riêng, phòng khám claim danh tính đó lên một tài khoản đầy đủ đã xác minh. Điểm cốt lõi: việc đặt đơn không bao giờ bị gián đoạn, và mọi đơn cũ tạo dưới danh tính nhẹ vẫn được giữ nguyên, gắn về tài khoản mới.
Bối cảnh
Một phòng khám ở VN sống trên Zalo/điện thoại, không cài app. Họ đặt hàng bằng cách quét QR của labo, nên hệ thống tạo cho họ một danh tính light khoá theo số điện thoại (hoặc labo đã seed sẵn khi mời → invited). Sau vài đơn, phòng khám muốn một tài khoản thật: nhiều lễ tân/nha sĩ đăng nhập với quyền khác nhau, xem lịch sử đơn, nhận hoá đơn. Chủ phòng khám bấm claim — hệ thống phải chắc chắn đúng chủ số điện thoại mới nhận được danh tính, tránh người lạ chiếm mất.
Diễn viên & quyền cần
| Vai trò | Quyền/điều kiện | Hành động |
|---|---|---|
| Nha sĩ / Lễ tân (clinic) | Đang cầm số điện thoại của danh tính | Đặt đơn đầu (sinh danh tính nhẹ); bấm claim; nhập OTP |
| Chủ phòng khám | Chủ thực của danh tính (đúng SĐT) | Sở hữu tài khoản sau claim; gộp các danh tính trùng của mình |
| Chủ labo / Điều phối (labo) | Có quan hệ với phòng khám | Seed danh tính khi mời; vouch khi OTP không tới (không tự claim hộ) |
| Hệ thống | — | Tự tạo danh tính theo SĐT; phát OTP về đúng số; phát hiện trùng; áp rate-limit |
Quy trình từng bước
- Danh tính nhẹ có sẵn. Phòng khám đã tồn tại ở
light(tự đặt đơn qua QR/connectionless) hoặcinvited(labo mời). Việc đặt đơn vẫn chạy bình thường ở mọi trạng thái này. - Bấm claim. Phòng khám yêu cầu nhận danh tính → chuyển
claim_pending. Hệ thống phát OTP về đúng số điện thoại đã đăng ký của danh tính (không phải số người claim tự khai) qua Zalo/SMS. - Xác minh chống mạo danh. Nhập đúng OTP → danh tính lên
claimed, thành tài khoản đầy đủ đã xác minh chủ. Đây là rào mạo danh chính: ai cầm được điện thoại đó mới là chủ. - Gộp trùng (nếu có). Nếu cùng một số điện thoại tồn tại nhiều danh tính nhẹ, hệ thống gộp theo SĐT chuẩn hoá (E.164, +84) về một bản sống → các bản còn lại
merged, chuyển toàn bộ đơn và cạnh quan hệ về bản sống, không tạo đơn mồ côi. - Bật kiểm soát truy cập. Sau claim, phòng khám có tài khoản đầy đủ: thêm người dùng, gán vai (RBAC), xem lịch sử đơn và nhận hoá đơn theo quyền.
Kết quả mong đợi
- Phòng khám lên tài khoản đầy đủ đã xác minh chủ (
claimed) mà không phải nhập lại gì. - Mọi đơn cũ tạo dưới danh tính nhẹ được giữ nguyên và gắn về tài khoản mới.
- Chỉ đúng chủ số điện thoại mới claim được — chống người lạ chiếm danh tính.
- Đặt đơn không bị chặn ở bất kỳ bước nào; claim/xác minh là luồng song song, không phải cổng chặn.
Khi nào hỏng & cách xử lý
| Triệu chứng | Nguyên nhân | Khắc phục |
|---|---|---|
| OTP không tới (đổi SIM, mất số, sai số khi seed) | Số đã đăng ký không còn dùng | Nhánh labo vouch: labo có quan hệ xác nhận đúng phòng khám → cập nhật số mới rồi phát OTP về số mới; vẫn phải có OTP đạt trước khi lên claimed (BR-W6) |
| Nhập sai OTP nhiều lần / hết hạn thử thách | Quá 5 lần sai hoặc quá 10 phút | Tự quay claim_pending → light (không mất đơn); resend bị rate-limit; tín hiệu lạm dụng thì → blocked (BR-W8, BR-W5) |
| Hai bên cùng đòi một danh tính | Tranh chấp sở hữu / OTP fail và không có vouch | Chuyển disputed: tạm dừng nâng cấp nhưng vẫn cho đặt đơn; người có quyền đối chiếu bằng chứng rồi kết về claimed/light/blocked (BR-W7) |
| Labo cố tự claim hộ phòng khám | Sai mô hình quyền | Từ chối — chỉ chủ thực claim/merge được; labo chỉ vouch, không chiếm danh tính (BR-W4) |
| Nghi mạo danh/lạm dụng ở bất kỳ bước nào | Rate-limit claim, báo gian lận | Chuyển blocked; gỡ chặn cần quyền và hiếm (BR-W5) |
Nâng cấp tài khoản là luồng song song, không phải điều kiện để đặt đơn: ở light, invited, claim_pending, thậm chí disputed, phòng khám vẫn tạo work order bình thường. Claim chỉ mở thêm kiểm soát truy cập, hoá đơn và quản người dùng — không đánh đổi bằng ma sát đặt hàng.