Skip to content

URD: Quản lý Người dùng

ModuleCORE-01Phiên bảnv0.4
Trạng tháiIn-progressNgày2026-05-29

1. Mục đích

Định nghĩa Quản lý Người dùng phải làm gì cho người dùng: cách họ tạo tài khoản, xác thực và quản lý hồ sơ, và cách chủ doanh nghiệp quản lý nhân viên và khách hàng trong tổ chức của mình. Đây là nền tảng của nền tảng — mọi module khác đều tin cậy danh tính và phạm vi được cấp ở đây.

2. Phạm vi

Bao gồmLoại trừ
Tạo tài khoản (đăng ký) và xác thực (đăng nhập)Tạo vai trò tùy chỉnh → Quyền hạn
Quản lý mật khẩu (đổi, quên / đặt lại)Luồng đăng nhập OAuth / OAuth2
Xác minh OTP cho email và điện thoại; liên kết tài khoảnQuản lý phiên và thu hồi từ xa
Tám vai trò hệ thống cố định và truy cập theo vai tròHệ thống mời người dùng
Vòng đời nhân viên (tạo, gán, vô hiệu hóa, gỡ)Lịch sử kiểm toán / đăng nhập
Vòng đời khách hàng (tạo, cập nhật, soft-delete, nâng cấp)Truy cập nhiều tổ chức cho một người dùng
Quản lý hồ sơ, định danh và cấu hình theo từng người dùngBắt buộc xác thực hai yếu tố

3. Định nghĩa

Thuật ngữĐịnh nghĩa
UserMột danh tính đã xác thực — nội bộ (operator) hoặc bên ngoài (owner, employee, customer).
CredentialMột bí mật dùng để xác thực — hiện là mật khẩu băm; scheme 2FA / OAuth đã định nghĩa nhưng chưa bắt buộc.
IdentifierMột giá trị đăng nhập gắn với người dùng — username, email hoặc điện thoại. Mỗi giá trị duy nhất toàn cục trong loại của nó.
User ProfileThông tin cá nhân gắn với người dùng — tên, ngày sinh, locale, thông tin liên hệ. Một cho mỗi người dùng.
User ConfigurationMột cài đặt khóa-giá trị theo từng người dùng, nhóm theo code. Bộ mặc định được tạo khi đăng ký.
RoleMột phân loại xác định mức truy cập và phạm vi dữ liệu. Có tám vai trò cố định.
OwnerNgười dùng tạo doanh nghiệp khi onboarding; có toàn quyền truy cập tổ chức của mình.
CashierVai trò nhân sự cấp merchant cho thu ngân, giới hạn theo các merchant cụ thể (cùng tier với Employee).
EmployeeMột nhân viên giới hạn theo các merchant cụ thể trong một tổ chức.
CustomerMột khách hàng cuối liên kết với một tổ chức; có thể được nâng cấp từ dữ liệu cấp bán hàng thành người dùng đầy đủ.
GuestMột vai trò toàn cục kiểu chưa xác thực, không có quyền backend; ưu tiên thấp nhất.
OTPMã dùng một lần gửi qua email hoặc SMS để xác minh định danh hoặc đặt lại mật khẩu.
Session Token (JWT)Cấp khi đăng nhập; mang user ID, vai trò, ID tổ chức và ID merchant để phân quyền phi trạng thái.

4. Mô hình Khái niệm

Chỉ mang tính khái niệm — schema đầy đủ nằm trong mô hình miền developer.

5. Yêu cầu Chức năng

Mỗi vùng chức năng một bảng. Mã <AREA> khớp với ID test-case. Mức ưu tiên = MoSCoW (Must / Should / Could / Won't).

5.1 Xác thực (AUTH)

IDPYêu cầu
URD-AUTH-001MNgười dùng có thể đăng ký với username và mật khẩu
URD-AUTH-002MĐăng ký tạo tài khoản, hồ sơ, định danh và cài đặt mặc định trong một thao tác
URD-AUTH-003MNếu bất kỳ phần nào của đăng ký thất bại, không có gì được tạo (tất-cả-hoặc-không)
URD-AUTH-004MNgười dùng có thể đăng nhập bằng bất kỳ định danh đã xác minh (username / email / phone) + mật khẩu
URD-AUTH-005MĐăng nhập thành công trả về token phiên mang vai trò và phạm vi tổ chức / merchant
URD-AUTH-006MMật khẩu được băm an toàn trước khi lưu và không bao giờ lưu dạng văn bản thuần
URD-AUTH-007MNgười dùng có thể đổi mật khẩu (xác minh mật khẩu hiện tại trước)
URD-AUTH-008MNgười dùng có thể xác minh email qua OTP (yêu cầu → nhận mã → gửi)
URD-AUTH-009MNgười dùng có thể xác minh điện thoại qua OTP (cùng luồng)
URD-AUTH-010MNgười dùng có thể đặt lại mật khẩu đã quên (yêu cầu → xác minh mã → đặt mật khẩu mới)
URD-AUTH-011SNgười dùng có thể thêm (liên kết) một email hoặc điện thoại đã xác minh vào tài khoản đã xác thực
URD-AUTH-012SHệ thống ghi lại dấu thời gian đăng nhập gần nhất
URD-AUTH-013CBắt buộc xác thực hai yếu tố Planned
URD-AUTH-014CHỗ trợ đăng nhập OAuth / bên thứ ba Planned

5.2 Tài khoản Người dùng (USR)

IDPYêu cầu
URD-USR-001MMỗi người dùng có một ID duy nhất do hệ thống sinh
URD-USR-002MMột người dùng có thể có nhiều định danh (username, email, điện thoại)
URD-USR-003MMỗi định danh duy nhất toàn cục trong loại của nó
URD-USR-004MUsername là bắt buộc và tự động được xem là đã xác minh
URD-USR-005MĐịnh danh email và điện thoại bắt đầu chưa xác minh và cần OTP để xác minh
URD-USR-006MNgười dùng có thể xem và cập nhật hồ sơ của mình (tên, ngày sinh, locale, liên hệ)
URD-USR-007MNgười dùng được ủy quyền có thể đổi trạng thái người dùng (kích hoạt, vô hiệu hóa, chặn, lưu trữ)
URD-USR-008MNgười dùng bị vô hiệu hóa và bị chặn không thể đăng nhập
URD-USR-009MDữ liệu người dùng luôn được bảo toàn — tài khoản không bao giờ bị xóa vĩnh viễn (soft-delete)
URD-USR-010SNgười dùng có thể đặt tùy chọn ngôn ngữ / locale
URD-USR-011CARCHIVED là trạng thái cuối và không thể kích hoạt lại

5.3 Vai trò & Phân phạm vi (ROLE)

IDPYêu cầu
URD-ROLE-001MHệ thống cung cấp tám vai trò cố định: Super Admin, Admin, Operator, Owner, Cashier, Employee, Customer, Guest
URD-ROLE-002MVai trò có một hệ thống ưu tiên; ưu tiên cao hơn nghĩa là truy cập rộng hơn
URD-ROLE-003MSuper Admin và Admin bỏ qua mọi lọc dữ liệu
URD-ROLE-004MOwner chỉ thấy tổ chức của mình và các merchant của nó
URD-ROLE-005MEmployee / Cashier chỉ thấy merchant mà họ được gán
URD-ROLE-006MThao tác list và count được lọc theo phạm vi của người dùng yêu cầu
URD-ROLE-007MNgười dùng không thể quản lý vai trò bằng hoặc cao hơn ưu tiên của chính mình
URD-ROLE-008MVai trò Owner được tự gán khi đăng ký

5.4 Quản lý Nhân viên (EMP)

IDPYêu cầu
URD-EMP-001MChủ sở hữu có thể tạo tài khoản nhân viên
URD-EMP-002MNhân viên được liên kết với một tổ chức và một hoặc nhiều merchant
URD-EMP-003MNhân viên chỉ có thể truy cập merchant mà họ được gán
URD-EMP-004MNhân viên có thể đăng nhập bằng thông tin xác thực riêng
URD-EMP-005MTruy vấn dữ liệu cho một nhân viên được lọc theo các merchant họ được gán
URD-EMP-006MChủ sở hữu có thể cập nhật gán merchant của nhân viên (thay thế mọi gán trước đó)
URD-EMP-007MChủ sở hữu có thể vô hiệu hóa hoặc gỡ một tài khoản nhân viên
URD-EMP-008MHệ thống xác thực rằng chủ sở hữu thực sự sở hữu tổ chức và mọi merchant được liệt kê

5.5 Quản lý Khách hàng (CUS)

IDPYêu cầu
URD-CUS-001MChủ sở hữu có thể tạo tài khoản khách hàng
URD-CUS-002MKhách hàng được liên kết với một tổ chức và nhận vai trò Customer tự động
URD-CUS-003MHồ sơ khách hàng gồm tên và thông tin liên hệ
URD-CUS-004MThông tin khách hàng có thể được cập nhật và soft-delete
URD-CUS-005SMột khách hàng cấp bán hàng có thể được nâng cấp thành tài khoản người dùng đầy đủ
URD-CUS-006SViệc nâng cấp kiểm tra xung đột định danh trước khi tạo người dùng

5.6 Cấu hình Người dùng (CFG)

IDPYêu cầu
URD-CFG-001MCấu hình mặc định được tạo tự động khi người dùng đăng ký
URD-CFG-002MCấu hình được nhóm và định danh duy nhất theo code cho mỗi người dùng
URD-CFG-003SNgười dùng có thể xem và cập nhật cấu hình của mình

6. Tiêu chí Chấp nhận

AC-AUTH-01: Đăng nhập
ChoKhiThì
Thông tin xác thực hợp lệ, định danh đã xác minhNgười dùng đăng nhậpToken phiên được cấp với vai trò và phạm vi
Mật khẩu saiNgười dùng đăng nhậpXác thực bị từ chối
Định danh chưa xác minhNgười dùng đăng nhậpĐăng nhập bị từ chối — định danh chưa xác minh
Người dùng bị vô hiệu hóa / bị chặnNgười dùng đăng nhậpTừ chối truy cập
Đăng nhập thành côngDấu thời gian đăng nhập gần nhất được cập nhật
AC-AUTH-02: Đăng ký
ChoKhiThì
Username + mật khẩu + hồ sơ mớiNgười dùng đăng kýTài khoản được tạo với vai trò Owner
Username đã tồn tạiNgười dùng đăng kýLỗi xung đột
Đăng ký thành côngCài đặt mặc định tự tạo
Bất kỳ bước nào thất bạiToàn bộ đăng ký roll back
AC-AUTH-03: Xác minh OTP
ChoKhiThì
Email hoặc điện thoại chưa xác minhNgười dùng yêu cầu OTPMã được gửi, token phiên trả về
Phiên hợp lệ + mã đúngNgười dùng gửiĐịnh danh được đánh dấu đã xác minh
Mã hết hạnNgười dùng gửiLỗi — mã đã hết hạn
Quá nhiều lần thửNgười dùng thử lạiLỗi — vượt quá số lần thử tối đa
AC-AUTH-04: Quên mật khẩu
ChoKhiThì
Người dùng quên mật khẩuYêu cầu đặt lạiPhiên đặt lại được tạo
Mã đặt lại hợp lệNgười dùng xác minhPhiên được xác nhận
Phiên đã xác minhNgười dùng đặt mật khẩu mớiMật khẩu được cập nhật (đã băm)
AC-EMP-01: Tạo nhân viên
ChoKhiThì
Chủ sở hữuTạo nhân viên với danh sách merchantTài khoản được tạo với vai trò Employee, liên kết tới tổ chức + merchant
Chủ sở hữu không sở hữu tổ chứcTạo nhân viênBị cấm
Merchant không thuộc tổ chức của chủ sở hữuCó trong danh sáchLỗi xác thực
AC-EMP-02: Gán lại merchant
ChoKhiThì
Nhân viên hiện cóChủ sở hữu cập nhật gánGán trước đó được thay bằng gán mới
Nhân viên chỉ thấy merchant mới
AC-CUS-01: Nâng cấp khách hàng
ChoKhiThì
Khách hàng cấp bán hàngKích hoạt nâng cấpNgười dùng đầy đủ được tạo với vai trò Customer
Xung đột định danhThử nâng cấpBị chặn với lỗi xung đột

7. Ràng buộc & Mục tiêu Loại trừ

Ràng buộc

IDRàng buộc
C-01Mật khẩu phải được băm an toàn; cấm lưu văn bản thuần
C-02Tám vai trò cố định được seed sẵn và không thể sửa hoặc xóa
C-03Ưu tiên vai trò được thực thi — không người dùng nào quản lý được vai trò ở mức của mình hoặc cao hơn
C-04Tạo tài khoản là nguyên tử — không cho phép tạo một phần
C-05Mọi bản ghi dùng soft-delete — không bao giờ xóa vật lý
C-06Mỗi loại định danh duy nhất toàn cục (một email chỉ thuộc một người dùng)
C-07Nhân viên phải được liên kết với cả một tổ chức và ít nhất một merchant
C-08Token phiên là phi trạng thái — thay đổi quyền có hiệu lực ở lần đăng nhập kế tiếp
C-09Mọi thao tác trừ đăng nhập / đăng ký đều yêu cầu xác thực

Mục tiêu Loại trừ

  • Tạo vai trò tùy chỉnh và quản lý quyền động → Quyền hạn
  • Luồng đăng nhập OAuth / OAuth2 bên thứ ba
  • Quản lý phiên và thu hồi từ xa
  • Mời người dùng qua email hoặc điện thoại
  • Lịch sử đăng nhập và ghi log kiểm toán
  • Truy cập nhiều tổ chức cho một người dùng duy nhất
  • Chính sách bắt buộc MFA

8. Lịch sử Phiên bản

NgàyTác giảMô tảVer
2026-02-26P. Do — Product OwnerUser story ban đầuv0.1
2026-04-16ProductTái cấu trúc thành URD với ID yêu cầuv0.3
2026-05-29ProductChuyển sang quy ước module-docs; chỉnh trạng thái (BLOCKED, không IDSAFE), thêm liên kết tài khoản + khoảng trống trung thực về trạng tháiv0.4

Proprietary and Confidential. Unauthorized copying, distribution, or use of this software is strictly prohibited.