PRD: Quản lý định danh & cấu hình người dùng
| Module | Quản lý Người dùng (CORE-01) | PRD ID | PRD-USR-002 |
| Trạng thái | Shipped | Chủ sở hữu | Identity squad |
| Ngày | 2026-06-15 | Phiên bản | v1.0 |
| Packages | @nx/identity · @nx/core | URD | USR · CFG |
TL;DR
Biến hai thứ mà tài khoản đã giữ - định danh đăng nhập và cài đặt cá nhân - thành những bề mặt mà người dùng thực sự quản lý được. Mỗi định danh mang một scheme phân loại nó (username, email, điện thoại, cùng các scheme do hệ thống cấp), và việc thêm một định danh là an toàn theo thiết kế: nó luôn được gắn với người dùng yêu cầu và luôn bắt đầu chưa xác minh, bất kể request khai báo gì. Cấu hình được phơi bày theo cùng cách, nhóm và định danh duy nhất theo code cho từng người dùng, và đọc được bởi bất kỳ người dùng đã đăng nhập trước cả khi chọn merchant - để ứng dụng nạp được tùy chọn của người dùng lúc khởi động. Bên cạnh đó, người dùng có thể lưu một chế độ xem bảng tùy chỉnh theo tên, nhân bản từ layout bảng gốc, để giữ cột và bộ lọc của riêng mình.
1. Bối cảnh & Vấn đề
PRD-USR-001 đã thiết lập tài khoản: một người dùng có thể giữ nhiều định danh và một bộ cấu hình mặc định được seed khi đăng ký. Nó định nghĩa những bản ghi đó là gì - chứ không định nghĩa cách người dùng quản lý chúng sau đó như những tài nguyên độc lập.
Không có bề mặt quản lý, một người dùng đã đăng nhập không thể thêm điện thoại thứ hai vào tài khoản hiện có, không liệt kê được các định danh họ đang giữ, hay lưu layout bảng riêng - và nền tảng không có chốt chặn cho hai cách mà việc tạo định danh đi sai: ai đó gắn định danh cho người dùng khác, hoặc gắn một định danh đã đánh dấu sẵn là xác minh để bỏ qua OTP. Cấu hình có một khoảng trống tinh tế hơn: chúng phải đọc được trước khi chọn merchant (thứ đầu tiên client cần để hiển thị tùy chọn của người dùng), nhưng mẫu tài nguyên tiêu chuẩn lại chặn việc đọc sau một phạm vi merchant.
Gia tăng này khép cả hai khoảng trống. Nó phơi bày định danh và cấu hình như tài nguyên hạng nhất có kiểm soát quyền, làm cho việc tạo định danh an toàn theo thiết kế, mở việc đọc cấu hình cho bất kỳ người dùng đã xác thực, và thêm chế độ xem bảng tùy chỉnh theo từng người dùng được dựng bằng cách nhân bản layout bảng gốc.
2. Mục tiêu & Mục tiêu Loại trừ
Mục tiêu
- Phơi bày định danh như một tài nguyên có quản lý - liệt kê, tìm kiếm, đếm, đọc đơn lẻ, cập nhật, gỡ - giới hạn theo người gọi.
- Làm cho việc thêm định danh an toàn theo thiết kế: nó luôn gắn với người dùng yêu cầu và luôn được tạo ở trạng thái chưa xác minh.
- Phân loại mọi định danh bằng một scheme (username, email, điện thoại, cùng các scheme do hệ thống cấp) lấy từ một tập cố định.
- Phơi bày cấu hình như một tài nguyên có quản lý, nhóm và định danh duy nhất theo code cho từng người dùng.
- Cho phép đọc cấu hình trước khi chọn merchant (tài nguyên cấp người dùng), trong khi vẫn chặn tạo / cập nhật / xóa.
- Cho người dùng lưu một chế độ xem bảng tùy chỉnh từ code + tên hiển thị, nhân bản từ layout bảng gốc, từ chối trùng lặp.
Mục tiêu Loại trừ
- Bản thân luồng khởi tạo tài khoản (đăng ký tạo tài khoản, hồ sơ, định danh, cấu hình mặc định) - đặc tả trong PRD-USR-001.
- Luồng yêu cầu / gửi / xác minh OTP - chúng thuộc vùng
AUTH(Xác thực); PRD này chỉ đặt trạng thái chưa xác minh ban đầu của định danh. - Mật khẩu và scheme thông tin xác thực (URD-AUTH).
- Định nghĩa vai trò / quyền tùy chỉnh → Quyền hạn.
- Nội dung của bất kỳ payload cấu hình cụ thể nào (cấu hình nhà cung cấp SMS, search pipeline, mặc định tài chính) - PRD này quản lý bề mặt quản lý, không phải schema của từng payload.
3. Chỉ số Thành công
| Chỉ số | Mục tiêu / tín hiệu |
|---|---|
| An toàn quyền sở hữu định danh | 100% định danh được tạo thuộc về người dùng yêu cầu; không thể gắn chéo người dùng |
| An toàn xác minh | 100% định danh email / điện thoại được tạo bắt đầu chưa xác minh; không cái nào bỏ qua OTP qua một cờ đặt sẵn |
| Đọc được trước khi chọn merchant | Người dùng đã đăng nhập đọc được cấu hình của mình trước khi chọn merchant |
| Toàn vẹn khóa cấu hình | Một cấu hình được phân giải duy nhất bằng code trong phạm vi một người dùng |
| Đúng đắn của chế độ xem tùy chỉnh | Một view được lưu bị từ chối khi trùng code, và bị từ chối khi layout bảng gốc của nó thiếu |
4. Chân dung & Tình huống
| Chân dung | Mục tiêu trong tính năng này |
|---|---|
| Chủ sở hữu / người dùng cuối | Thêm và quản lý email / điện thoại của mình, và lưu layout bảng cá nhân |
| Operator được ủy quyền | Duyệt và duy trì định danh trong phạm vi của mình dưới các quyền tường minh |
| Ứng dụng client | Đọc cấu hình của người dùng lúc khởi động, trước khi chọn merchant, để nạp tùy chọn |
Tình huống cốt lõi: một người dùng đã đăng nhập mở quản lý định danh → thấy các định danh họ đang giữ, mỗi cái hiển thị theo scheme → thêm một điện thoại mới; nó được lưu vào tài khoản của chính họ và đánh dấu chưa xác minh, chờ OTP. Tách biệt, ứng dụng nạp cấu hình của người dùng ngay khi họ đăng nhập - trước khi chọn merchant - và người dùng lưu một view bảng "Sản phẩm" tùy chỉnh; hệ thống nhân bản layout bảng sản phẩm gốc thành một view mới theo từng người dùng, từ chối một view thứ hai dùng lại cùng code.
5. User Story
- Là một người dùng, tôi muốn thêm email hoặc điện thoại vào tài khoản hiện có, để sau này xác minh và dùng nó đăng nhập.
- Là một người dùng, tôi muốn bất kỳ định danh nào tôi thêm đều thuộc về tôi và bắt đầu chưa xác minh, để không ai pre-trust một liên hệ hay gắn nó nơi khác.
- Là một người dùng, tôi muốn xem và quản lý các định danh tôi đang giữ, mỗi cái gắn nhãn theo loại, để biết bề mặt đăng nhập của tài khoản.
- Là một người dùng, tôi muốn tùy chọn của mình nạp ngay khi đăng nhập, trước khi chọn cửa hàng, để ứng dụng cá nhân hóa từ màn hình đầu tiên.
- Là một người dùng, tôi muốn lưu layout bảng của riêng mình theo tên, để cột và bộ lọc bền qua các phiên.
- Là một người dùng, tôi muốn một view trùng tên bị từ chối, để các view đã lưu không nhập nhằng.
6. Yêu cầu Chức năng
| # | Yêu cầu | Tham chiếu URD |
|---|---|---|
| FR-1 | Mọi định danh khai báo một scheme phân loại nó - username, email, điện thoại, cùng các scheme do hệ thống cấp - lấy từ một tập cố định, đã kiểm chứng | URD-USR-012 |
| FR-2 | Định danh là một tài nguyên có quản lý: liệt kê, tìm kiếm, đếm và đọc đơn lẻ, giới hạn theo quyền truy cập của người gọi | URD-USR-013 |
| FR-3 | Thêm một định danh luôn gắn nó với người dùng yêu cầu và tạo nó chưa xác minh; tham chiếu người dùng hoặc cờ xác minh cung cấp không thể ghi đè điều này | URD-USR-014 · URD-USR-005 |
| FR-4 | Định danh có thể được cập nhật và gỡ (đơn lẻ hoặc theo bộ lọc) qua soft-delete; dữ liệu định danh được bảo toàn | URD-USR-015 · URD-USR-009 |
| FR-5 | Mọi thao tác định danh (đọc / tạo / cập nhật / xóa) được kiểm soát quyền riêng lẻ và giới hạn theo merchant | URD-USR-016 |
| FR-6 | Cấu hình thuộc một tập nhóm cố định (system, table, integration) và được định danh duy nhất bằng code cho từng người dùng | URD-CFG-004 · URD-CFG-002 |
| FR-7 | Việc đọc cấu hình khả dụng cho bất kỳ người dùng đã xác thực trước khi chọn merchant; tạo / cập nhật / xóa được kiểm soát quyền | URD-CFG-005 |
| FR-8 | Người dùng có thể tạo một chế độ xem bảng tùy chỉnh từ code + tên hiển thị; hệ thống nhân bản layout đã lưu của cấu hình bảng gốc thành một view mới theo từng người dùng trong nhóm table | URD-CFG-006 |
| FR-9 | Việc tạo view tùy chỉnh từ chối một view trùng (người dùng + code + tên) và yêu cầu cấu hình bảng gốc được tham chiếu phải tồn tại | URD-CFG-007 |
Toàn văn yêu cầu và tiêu chí chấp nhận nằm trong URD Quản lý Người dùng - USR và CFG. PRD này tham chiếu chúng thay vì lặp lại. Các yêu cầu khởi tạo tài khoản (URD-USR-001..011, URD-CFG-001..003) được đặc tả trong PRD-USR-001.
7. Yêu cầu Phi Chức năng
| Lĩnh vực | Yêu cầu |
|---|---|
| Toàn vẹn quyền sở hữu | Tạo định danh lấy chủ sở hữu từ người gọi đã xác thực, không bao giờ từ thân request |
| Toàn vẹn xác minh | Một định danh được tạo luôn chưa xác minh; trạng thái đã xác minh chỉ đạt được qua luồng OTP |
| Phân quyền | Thao tác định danh kiểm soát quyền riêng lẻ; đọc cấu hình chỉ cần xác thực (cấp người dùng), ghi thì kiểm soát quyền |
| Truy cập trước merchant | Việc đọc cấu hình thành công trước khi tồn tại phạm vi merchant, để client nạp lúc khởi động |
| Soft-delete | Gỡ một định danh hoặc cấu hình bảo toàn bản ghi; không bao giờ xóa vật lý |
| i18n | Nhãn hiển thị (nhãn loại định danh và nhãn cấu hình) song ngữ ({ en, vi }) |
8. UX & Luồng
Màn hình chính (trong apps/client): quản lý định danh (thêm / liệt kê email và điện thoại theo loại), nạp tùy chọn lúc đăng nhập, và nút "lưu view" theo từng bảng giữ cột và bộ lọc của người dùng.
9. Dữ liệu & Miền
| Thực thể | Vai trò trong gia tăng này |
|---|---|
UserIdentifier | Một giá trị đăng nhập có phân loại - scheme (username / email / điện thoại, cùng các scheme hệ thống), identifier, một cờ verified, thuộc về một người dùng; quản lý như một tài nguyên |
UserConfiguration | Một cài đặt theo từng người dùng - group (system / table / integration), code, name hiển thị, giá trị lưu trữ - định danh duy nhất bằng code cho từng người dùng; một view tùy chỉnh là một hàng nhóm table nhân bản từ layout gốc |
Chỉ mang tính khái niệm - schema đầy đủ và bất biến nằm trong mô hình miền identity. Quyền sở hữu và tính duy nhất của định danh được thực thi ở tầng service, không phải bằng ràng buộc cơ sở dữ liệu liên bảng.
10. Phụ thuộc & Giả định
Phụ thuộc vào
- Tài khoản người dùng & cấu hình (PRD-USR-001, URD-USR-001..011, URD-CFG-001..003) - gia tăng này quản lý các định danh và cấu hình mà khởi tạo tài khoản tạo ra.
- Xác thực (URD-AUTH) - luồng OTP lật một định danh từ chưa xác minh sang đã xác minh; PRD này chỉ đặt trạng thái ban đầu.
- Vai trò & Phân phạm vi (URD-ROLE) - thao tác định danh kiểm soát quyền và giới hạn theo người gọi.
@nx/core- model định danh và cấu hình dùng chung, hằng số scheme/group, và layout bảng gốc.
Giả định
- Người dùng đã xác thực trước khi quản lý định danh hoặc cấu hình (trừ nơi việc đọc được mở có chủ ý ở cấp người dùng).
- Layout bảng gốc tồn tại như các cấu hình nhóm table được seed mà một view tùy chỉnh có thể nhân bản từ đó.
11. Rủi ro & Câu hỏi Mở
| Rủi ro / câu hỏi | Giảm thiểu / trạng thái |
|---|---|
| Một định danh gắn nhầm người dùng | Chủ sở hữu lấy từ người gọi đã xác thực, không bao giờ từ thân request |
| Một liên hệ đánh dấu sẵn là xác minh để bỏ qua OTP | Tạo luôn ép trạng thái chưa xác minh; xác minh chỉ đạt được qua luồng OTP |
| Đọc cấu hình bị chặn trước khi chọn merchant | Đọc chỉ cần xác thực ở cấp người dùng, nên client nạp được lúc khởi động |
| Hai view tùy chỉnh va chạm cùng code | Một view trùng (người dùng + code + tên) bị từ chối trước khi lưu bất cứ thứ gì |
| Một view nhân bản từ layout gốc thiếu | Việc tạo yêu cầu cấu hình bảng gốc được tham chiếu tồn tại, nếu không thì bị từ chối |
12. Kế hoạch Phát hành & Tiêu chí Ra mắt
| Khía cạnh | Kế hoạch |
|---|---|
| Phase | P1 (nền tảng) - mở rộng USR và CFG trong danh mục tính năng URD |
| Triển khai | Mọi người dùng; không feature flag |
| Di trú | Không - các bề mặt vận hành trên bản ghi định danh và cấu hình hiện có |
| Tiêu chí ra mắt | Định danh liệt kê và thêm được; một định danh được tạo thuộc về người gọi và chưa xác minh; cấu hình đọc được trước khi chọn merchant; một view tùy chỉnh nhân bản layout gốc và từ chối trùng lặp / thiếu gốc |
| Giám sát | Bất biến quyền sở hữu/xác minh khi tạo định danh, độ trễ đọc cấu hình lúc đăng nhập, tỷ lệ từ chối view tùy chỉnh theo lý do |
13. FAQ
Tôi có thể thêm định danh vào tài khoản của người khác không? Không - chủ sở hữu luôn là người gọi đã xác thực; mọi tham chiếu người dùng trong request đều bị bỏ qua.
Vì sao một email mới tôi thêm hiển thị là chưa xác minh? Mọi định danh được thêm đều bắt đầu chưa xác minh theo thiết kế; nó chỉ trở thành đăng nhập dùng được sau khi luồng OTP xác minh.
Vì sao tôi đọc được cài đặt trước khi chọn cửa hàng? Cấu hình là tài nguyên cấp người dùng, nên việc đọc mở cho bất kỳ người dùng đã đăng nhập - điều đó cho phép ứng dụng nạp tùy chọn của bạn ngay khi đăng nhập, trước khi chọn merchant.
Chế độ xem tùy chỉnh là gì? Một layout bảng cá nhân (cột và bộ lọc) lưu dưới tài khoản của bạn, nhân bản từ layout bảng gốc và định danh bằng code và tên.
Điều gì ngăn hai view va chạm? Một view dùng lại tổ hợp (người dùng + code + tên) hiện có bị từ chối, và một view có layout bảng gốc không tồn tại cũng bị từ chối.
Tham chiếu
- URD: Quản lý Người dùng - Tài khoản Người dùng · Cấu hình Người dùng
- Xây trên: PRD-USR-001 - Tài khoản người dùng & cấu hình
- Liên quan: Xác thực · Vai trò & Phân phạm vi
- Module: Quản lý Người dùng - tổng quan + năng lực
- Developer: @nx/identity · mô hình miền · @nx/core