PRD: Quản lý identifier & cấu hình người dùng
| Module | Quản lý User | PRD ID | PRD-USR-002 |
| Trạng thái | Sẵn sàng dev | FEAT | USR |
| Epic | — | Plane | BANA-1525 |
| Ngày | 2026-06-15 | Phiên bản | v1.0 |
| Gói | @nx/identity | URD | USR |
| Surface | Client · Chủ/QL | ||
| Phụ trách | Phát Nguyễn | ||
Quản lý identifier & cấu hình người dùng là gì
PRD-USR-001 đã thiết lập tài khoản: một người dùng có thể giữ nhiều định danh đăng nhập (Login Identifier), và một bộ cấu hình mặc định được seed khi đăng ký. PRD đó định nghĩa những bản ghi đó là gì - PRD này định nghĩa cách người dùng quản lý chúng về sau như những tài nguyên độc lập, có gác quyền: liệt kê, thêm, gỡ định danh; đọc và ghi cấu hình (User Configuration).
Mỗi định danh mang một loại định danh (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. Thêm một định danh luôn gắn cho chính người gọi và luôn bắt đầu ở trạng thái chưa xác minh, dù request khai báo gì đi nữa. Cấu hình nhóm theo system hoặc table, đánh khóa duy nhất theo code cho từng người dùng, và đọc được ngay sau khi đăng nhập - trước cả khi chọn organizer hay merchant - để app nạp tùy chọn từ màn hình đầu tiên.
Vì sao cần một surface quản lý riêng
Thiếu một surface quản lý, người dùng đã đăng nhập không thể thêm điện thoại thứ hai, không liệt kê được các định danh mình đang giữ, hay lưu layout bảng riêng - và không gì chặn hai cách mà việc tạo định danh đi sai: gắn nó cho người dùng khác, hoặc gắn một định danh đã đánh dấu sẵn là xác minh để né mã một lần. Việc gỡ định danh cũng thiếu một chốt chặn tương tự: không gì ngăn một người dùng tự gỡ email đã xác minh cuối cùng của mình, hoặc - với vai trò từ Owner trở xuống - gỡ số điện thoại đã xác minh cuối cùng, mất luôn cách đăng nhập lại đáng tin.
Cấu hình có một khoảng trống tinh vi hơn: chúng phải đọc được trước khi chọn organizer hoặc merchant - thứ đầu tiên client cần để hiển thị tùy chọn - nhưng mẫu tài nguyên tiêu chuẩn lại chặn việc đọc đằng sau một phạm vi merchant. Đợt này khép các khoảng trống trên, và thêm một view bảng tùy chỉnh (Custom Table View) theo từng người dùng, dựng bằng cách nhân bản layout bảng gốc.
Một định danh, từ lúc thêm tới lúc gỡ
Tại màn Hồ sơ trong Account Settings (đặc tả ở PRD-AUTH-001), một người dùng thêm một số điện thoại mới. Định danh đó lưu dưới chính tài khoản của họ và đánh dấu chưa xác minh, chờ mã một lần - dù request có gửi kèm tham chiếu người dùng khác hay cờ xác minh đi nữa. Người dùng đó thử gỡ số điện thoại đã xác minh cuối cùng của mình → bị từ chối, tài khoản vẫn giữ được ít nhất một cách đăng nhập lại đáng tin. 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 organizer hoặc 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.
Chỗ dễ sai nhất
Luật giữ lại định danh xác minh cuối áp dụng ở MỌI đường gỡ, không chỉ màn hồ sơ
Dễ nghĩ rằng chặn gỡ email hay số điện thoại xác minh cuối cùng chỉ là một validation trên form ở màn hồ sơ. Không phải vậy - luật này áp dụng ở mọi đường gỡ định danh, kể cả từ bên trong luồng xác minh.
Nếu chỉ chặn ở một chỗ, một người dùng vẫn có thể tự khóa mất cách đăng nhập lại của mình qua đường gỡ khác mà validation ở màn hồ sơ không phủ tới.