Phân Quyền Theo Chức Năng Công Việc

Cấp quyền cho một thành viên trong workspace hiện đang là một thao tác thủ công, tốn thời gian, và dễ sai: super admin phải tick tay đúng các ô trong danh mục 55 chức năng, mỗi lần một thành viên mới. Bài này đặc tả một lớp mỏng đặt lên trên — preset "vai trò công việc" — cho phép cấp quyền theo Kế toán / Hỗ trợ / Vận hành chỉ trong một thao tác, mà không phải xây lại RBAC.

Tài liệu được tổ chức theo trình tự PRD chuẩn: thông tin chung trước, sau đó là bối cảnh và mục tiêu, rồi mới đi vào personas, luồng nghiệp vụ, business rules, và cuối cùng là acceptance criteria + quy trình bàn giao. Phần 6 (Bàn giao) liệt kê những điểm CTO cần chốt trước khi code — đọc kỹ phần đó nếu bạn là dev được giao ticket.

01 · Thông tin chung

Bốn trường meta cần đọc đầu tiên

Trước khi đọc bất kỳ phần nào khác, hãy đối chiếu bốn ô dưới đây để chắc rằng bạn đang đọc đúng phiên bản tài liệu và đúng feature. Feature ID là khoá nối tới ticket, Status cho biết tài liệu đã sẵn sàng để code hay chưa.

Feature ID

FT-PERM-ROLE-PRESET-01 — khoá nối tới ticket & branch.

Owner / PO

CTO — cũng là người Approve cuối cùng trước khi deploy Production.

Priority

P1 — High: cấp quyền tay 55 ô đang mất công, dễ sót/nhầm, hai người cùng vai trò dễ lệch.

Status

Draft — tạo 04/06/2026, cập nhật cuối 04/06/2026.

Hình 1.1 — Bốn trường meta của feature. ID / PO / Priority / Status — đối chiếu trước khi đọc tiếp.

Hệ thống: Dashboard quản trị workspace — màn phân quyền theo chức năng đã có sẵn (super admin tick trong 55 chức năng, chia nhóm Hệ thống / Audit & Log / Risk…, có "Chọn tất cả" / "Thu hồi tất cả", áp dụng sau khi bấm Xác nhận). Module Audit & Log có sẵn — sẽ tái dùng cho việc ghi nhật ký cấp quyền.

Quy mô: Bổ sung lớp "chức năng công việc" (preset vai trò) map sẵn một bộ chức năng cho từng vai trò. Khi cấp quyền, super admin chọn vai trò → bộ chức năng được tick sẵn, vẫn chỉnh tay từng ô trước khi Xác nhận. KHÔNG xây lại RBAC/role lồng nhau; không thay thế màn phân quyền hiện có — chỉ thêm tầng "chọn nhanh theo vai trò" lên trên nó.

02 · Bối cảnh

Vì sao cần lớp preset — và đâu là nguyên nhân gốc

Hiện tại, để cấp quyền cho một thành viên, super admin phải tick thủ công từng chức năng trong danh mục 55 chức năng (chia nhóm Hệ thống, Audit & Log, Risk…), rồi bấm Xác nhận để áp. Lớp phân quyền chỉ phơi ra mức chức năng đơn lẻ — không có khái niệm vai trò công việc.

Hệ quả khi ánh xạ "vai trò → các ô cần tick" nằm hoàn toàn trong đầu super admin:

Mất công & chậm: mỗi thành viên là một lần dò tick thủ công, càng nhiều thành viên càng tốn thời gian.
Dễ sai: dễ sót chức năng cần cấp hoặc tick nhầm chức năng thừa — thành viên thiếu quyền không làm được việc, hoặc dư quyền gây rủi ro.
Không nhất quán: hai kế toán do cấp ở hai thời điểm / hai người khác nhau có thể nhận bộ quyền lệch nhau, không có chuẩn chung.
Phụ thuộc trí nhớ admin: ánh xạ "vai trò → các ô cần tick" chưa được chuẩn hóa ở đâu trong hệ thống.

Tính năng cần bổ sung: định nghĩa sẵn các vai trò (Kế toán, Hỗ trợ, Vận hành…), mỗi vai trò map tới một bộ chức năng trong 55 chức năng. Khi cấp quyền, super admin chỉ cần chọn vai trò → bộ chức năng tương ứng được tick sẵn, sau đó chỉnh tay thêm/bớt nếu cần rồi Xác nhận. Việc cấu hình "vai trò nào gồm những chức năng nào" do Admin/CTO thiết lập một lần, dùng lại cho mọi thành viên.

        role-preset.shape
        SCHEMA
      

// Một preset = ánh xạ vai trò → bộ chức năng (subset của 55)
RolePreset = {
  name:          "Kế toán" | "Hỗ trợ" | "Vận hành" | ...,
  functions:     Set<FunctionId>,     // subset của 55 chức năng
  defined_by:    "Admin/CTO",           // một lần, dùng lại
  applied_as:    "snapshot"             // KHÔNG hồi tố sau khi cấp
}
      

Nguyên nhân gốc không phải là "admin lười tick" — mà là hệ thống chưa có tầng vai trò nào để gom đúng bộ chức năng theo nghiệp vụ. — Vì sao đây là vấn đề thiết kế, không phải vấn đề quy trình

03 · Mục tiêu & Chỉ số

Bốn chỉ số đo lường thành công

Phạm vi & cách làm — chốt rõ để dev không làm quá tay: KHÔNG xây hệ thống RBAC phức tạp (role lồng nhau, kế thừa role, toán tử điều kiện). Đây chỉ là preset "vai trò → bộ chức năng" để điền nhanh trên màn phân quyền 55 chức năng đã có. Super admin vẫn tick được từng ô như hiện tại — chọn vai trò chỉ là bước gợi ý/điền sẵn, không khóa cứng. Giữ tính năng đơn giản, đúng nhu cầu.

Sau khi làm xong: super admin cấp quyền theo vai trò (một thao tác áp đúng bộ chức năng) thay vì tick tay 55 ô; các thành viên cùng vai trò có bộ quyền nền nhất quán; cấp nhanh hơn, ít sót/nhầm. Release đầu hỗ trợ một vài vai trò khởi đầu (Kế toán, Hỗ trợ, Vận hành…); Admin/CTO cấu hình map vai trò → chức năng; super admin chọn vai trò khi cấp và vẫn tinh chỉnh tay trước khi Xác nhận.

Metric · 01

Nhanh hơn

Giảm thời gian/số thao tác để cấp quyền cho một thành viên mới — từ dò-tick 55 ô xuống chọn vai trò + chỉnh vài ô.

Metric · 02

Nhất quán

Các thành viên cùng vai trò có bộ quyền nền giống nhau — không còn lệch tùy người/thời điểm cấp.

Metric · 03

Ít lỗi

Giảm trường hợp thiếu/thừa quyền do tick tay sót/nhầm.

Metric · 04

Chuẩn hóa

Ánh xạ "vai trò → quyền" được lưu trong hệ thống thay vì nằm trong trí nhớ admin.

Hình 3.1 — Bốn chỉ số đo lường thành công. Không có chỉ số nào cần feature flag hay A/B — đây là cải thiện thuần workflow.

04 · Personas

Ai làm gì với feature này

Feature có ba persona active + một persona passive. Lưu ý kỹ phần phân quyền thao tác: chỉ Admin/CTO được cấu hình preset, chỉ super admin được cấp quyền cho thành viên — đây là ràng buộc bảo mật, không phải tuỳ chọn UX.

Super Admin

Người cấp/thu hồi quyền

Nay chọn được vai trò công việc để áp sẵn bộ chức năng lên màn phân quyền, rồi tinh chỉnh tay và Xác nhận.

Admin / CTO

Người cấu hình preset

Cấu hình danh sách vai trò và bộ chức năng mỗi vai trò map tới. Thiết lập một lần, dùng lại.

Member

Người nhận quyền (thụ động)

Hưởng lợi gián tiếp: được cấp đúng & nhất quán theo vai trò, nhanh hơn. Không truy cập cấu hình.

Hình 4.1 — Ba persona active. Persona thứ tư — lớp phân quyền 55 chức năng đã có — được tái sử dụng nguyên trạng; preset chỉ là tầng điền nhanh phía trên.

05 · Luồng nghiệp vụ cốt lõi

Sáu bước, theo thứ tự

Luồng nghiệp vụ chia hai pha: Admin/CTO cấu hình một lần (Bước 1), sau đó super admin áp & tinh chỉnh từng lần cấp (Bước 2–6). Lưu ý Bước 4 — tinh chỉnh tay sau khi áp — chính là chỗ super admin quyết định tập cuối cùng, không phải bộ gốc của vai trò.

Admin cấu hình preset

Tạo vai trò + chọn chức năng — một lần.

Mở màn phân quyền

Super admin mở màn của một thành viên.

Chọn vai trò

Hệ thống tick sẵn các chức năng của vai trò.

Tinh chỉnh tay

Thêm/bớt từng ô; có thể chọn nhiều vai trò.

Bấm Xác nhận

Áp đúng tập chức năng cuối cùng — qua cơ chế cũ.

Ghi log

Hành động + vai trò đã áp → module Audit & Log.

Hình 5.1 — Sáu bước. Bước 1 chạy một lần (Admin/CTO); Bước 2–6 chạy mỗi lần cấp (super admin).

Người kiêm nhiệm — vd vừa Kế toán vừa Hỗ trợ — có thể được áp nhiều vai trò ở Bước 3; các bộ quyền sẽ hợp nhất (union), ô trùng không nhân đôi. Chi tiết quy tắc hợp nhất ở Mục 08.

06 · Edge cases

Năm tình huống dev bắt buộc xử lý

Bên cạnh luồng chính ở Mục 05, đây là năm tình huống biên mà cách xử lý phải được code rõ ràng, không để mặc định. Dev tự tư duy & bổ sung thêm nếu cần.

Quan trọng

Áp vai trò lên lựa chọn đang có — cộng dồn hay thay thế?

Đề xuất cộng dồn (union): tick thêm chức năng của vai trò, không tự bỏ ô admin đã chọn. Hiển thị rõ thay đổi. Chốt ở Bước 0.

Kiêm nhiệm

Nhiều vai trò cho một thành viên

Vd vừa Kế toán vừa Hỗ trợ → hợp nhất (union) hai bộ chức năng; ô trùng không nhân đôi, không xung đột.

Khả dụng

Chức năng không khả dụng cho workspace/gói

Cần gói trả phí (biểu tượng vương miện) hoặc chưa bật → áp vai trò bỏ qua an toàn phần không khả dụng, nêu rõ, không crash.

Snapshot

Sửa preset sau khi đã cấp — KHÔNG hồi tố

Áp vai trò là điền một lần tại thời điểm cấp (snapshot), KHÔNG ràng buộc sống. Admin sửa preset sau đó không tự đổi quyền thành viên đã cấp trước đó.

Bảo mật

Phạm vi quyền cấu hình preset

Chỉ Admin/CTO cấu hình; chỉ super admin cấp; member không thấy/sửa được. Quyền áp qua vai trò không vượt phạm vi workspace.

Hình 6.1 — Năm tình huống biên + hành vi kỳ vọng. Các edge case phụ (vai trò rỗng, xoá vai trò đang dùng, danh mục 55 chức năng đổi) liệt kê trong văn bản dưới.

Ba edge case phụ cần xử lý gọn (không cần khung riêng): (1) Xóa một vai trò đang được dùng — thành viên đã cấp giữ nguyên quyền, chỉ là không còn chọn vai trò đó cho lần cấp mới; không văng lỗi. (2) Danh mục 55 chức năng thay đổi — chức năng không còn tồn tại thì bỏ qua, không lỗi; chức năng mới chưa nằm trong vai trò nào thì admin tự thêm. (3) Vai trò rỗng / cấu hình lỗi — chọn vào không tick gì, không lỗi; nên cảnh báo admin khi lưu một vai trò rỗng.

Snapshot là tính năng, không phải bug. Sửa preset hôm nay không được tự đổi quyền của ai đã cấp hôm qua. — Quy tắc không hồi tố

07 · User stories

Bảng tham chiếu nhanh

Năm user story định nghĩa scope chức năng của release đầu. P0 là phải có để release; P1 có thể chậm hơn nhưng vẫn nằm trong cùng feature, không tách ticket.

ID	Vai trò	Muốn / Để	Ưu tiên
US-01	Super Admin	Chọn một vai trò công việc (vd Kế toán) để tick sẵn đúng bộ chức năng cho thành viên — không phải dò tick tay từng ô trong 55 chức năng.	P0
US-02	Super Admin	Sau khi áp vai trò, vẫn thêm/bớt từng chức năng — để cấp đúng nhu cầu cụ thể của từng thành viên.	P0
US-03	Super Admin	Áp nhiều vai trò cho thành viên kiêm nhiệm — để người làm nhiều vai trò vẫn cấp nhanh, đúng.	P1
US-04	Admin / CTO	Cấu hình danh sách vai trò + bộ chức năng mỗi vai trò — để chuẩn hóa "vai trò → quyền", nhất quán, đỡ sai.	P0
US-05	Admin / CTO	Sửa/xóa bộ chức năng của một vai trò — để cập nhật khi nghiệp vụ vai trò thay đổi.	P1

Hình 7.1 — Năm user story. Ba P0 (US-01/02/04) phải có cho release đầu; hai P1 có thể chậm hơn nhưng cùng ticket.

08 · Business rules

Cấu trúc preset & quy tắc áp

Trước khi đọc danh sách rule, nhìn vào sơ đồ dưới: preset không phải là một "role" có quyền của nó — mà chỉ là một tập con của 55 chức năng, dùng làm khuôn để tick sẵn lên màn phân quyền có sẵn. Bảy thành phần trong sơ đồ tương ứng với cách tập quyền cuối cùng được tính tại thời điểm Xác nhận.

VAI TRÒ A Kế toán preset

∪

VAI TRÒ B Hỗ trợ preset

∪

TICK CŨ ✓ k cộng dồn
không tự bỏ

CHỈNH TAY ± super admin
thêm/bớt

∩

WORKSPACE khả dụng bỏ qua
không cấp được

TẬP CUỐI ✓ N áp khi
Xác nhận

→

SNAPSHOT freeze không hồi tố
+ ghi log

Công thức áp quyền

union(preset_A, preset_B, tick_cũ) + chỉnh_tay ∩ workspace = tập_cuối → snapshot

Hình 8.1 — Cách tập quyền cuối cùng được tính tại thời điểm Xác nhận. Bốn yếu tố cộng dồn (∪/+), một yếu tố lọc (∩), sau đó freeze làm snapshot.

Tám rule dưới đây là chuẩn mực để dev đối chiếu khi viết logic và QA đối chiếu khi viết test:

Preset là ánh xạ vai trò → bộ chức năng, do Admin/CTO cấu hình; dùng lại cho mọi thành viên.
Chọn vai trò chỉ là điền nhanh: super admin vẫn tick được từng ô và quyết định tập cuối cùng trước khi Xác nhận. Vai trò không khóa cứng lựa chọn.
Điền một lần (snapshot), không hồi tố: áp vai trò chốt tập chức năng tại thời điểm cấp; sửa preset về sau không tự đổi quyền thành viên đã cấp.
Nhiều vai trò → hợp nhất (union): ô trùng không nhân đôi; không phát sinh xung đột.
Tái sử dụng lớp phân quyền 55 chức năng có sẵn: việc áp quyền cuối cùng đi qua đúng cơ chế tick + Xác nhận hiện có; không đẻ cơ chế cấp quyền song song.
Không vượt phạm vi: bộ quyền áp qua vai trò không vượt phạm vi workspace cho phép; chức năng không khả dụng (gói/chưa bật) bỏ qua an toàn.
Phân quyền thao tác: chỉ Admin/CTO cấu hình preset; chỉ super admin cấp quyền; member không truy cập cấu hình.
Ghi log: mỗi lần cấp quyền (kèm vai trò đã áp) ghi vào nhật ký — tận dụng module Audit & Log có sẵn.

        apply-preset.pseudo
        LOGIC
      

// Áp một hoặc nhiều preset lên màn phân quyền của thành viên
final_set = union(roles.map(r => r.functions))
            ∪ existing_ticks       // cộng dồn, không tự bỏ
            ∩ workspace_available  // bỏ qua không khả dụng

// Super admin chỉnh tay → tập cuối
final_set += manual_adjustments

// Khi bấm Xác nhận: snapshot — KHÔNG hồi tố
member.permissions = freeze(final_set)
audit.write({ action: "grant", member, applied_roles, final_set })
      

Giao diện (gợi ý — dev tự tinh chỉnh UX)

Trên màn phân quyền thành viên (màn 55 chức năng hiện có): thêm khu vực "Cấp theo chức năng công việc" — danh sách vai trò dạng thẻ/dropdown; chọn vai trò → các ô tương ứng được tick sẵn; super admin vẫn thấy & chỉnh được từng ô; giữ nguyên "Chọn tất cả" / "Thu hồi tất cả"; áp dụng sau khi Xác nhận. Nên hiển thị thành viên đang được áp vai trò nào. Màn cấu hình vai trò (Admin/CTO): tạo / sửa / xóa vai trò; với mỗi vai trò, tick chọn các chức năng thuộc về nó trong danh mục 55 chức năng (cùng cách trình bày theo nhóm).

09 · Acceptance & Test cases

Tám tiêu chí nghiệm thu

Để feature được coi là "xong", cả tám tiêu chí dưới phải pass trên staging. Đối chiếu trực tiếp khi viết test:

Super admin chọn một vai trò (vd Kế toán) → đúng bộ chức năng của vai trò được tick sẵn trên màn phân quyền của thành viên.
Sau khi áp vai trò, super admin thêm/bớt từng chức năng được; chỉ tập cuối cùng (sau Xác nhận) mới thực sự được cấp.
Áp nhiều vai trò cho một thành viên → hợp nhất đúng (union), ô trùng không nhân đôi, không lỗi.
Admin/CTO cấu hình được danh sách vai trò + bộ chức năng từng vai trò; sửa/xóa được.
Sửa preset về sau KHÔNG tự đổi quyền của thành viên đã được cấp trước đó (không hồi tố).
Chức năng cần gói trả phí / chưa bật → bỏ qua an toàn, không tick cái không cấp được, không crash.
Chỉ Admin/CTO cấu hình preset; chỉ super admin cấp quyền; member không thấy/không sửa cấu hình.
Mỗi lần cấp quyền (kèm vai trò áp) được ghi log.

Ma trận test case

Test case chia ba nhóm: luồng chính, edge case, và TC bổ sung do dev tự dựng. Mỗi cột dưới là một nhóm:

GROUP · 01

Luồng chính

TC-01 → TC-04 — phải pass 100%.

→ TC-01 áp "Kế toán" → đúng bộ tick sẵn
→ TC-02 tinh chỉnh sau áp → tập cuối khớp lựa chọn
→ TC-03 "Kế toán" + "Hỗ trợ" → union, không nhân đôi
→ TC-04 tạo vai trò mới → chọn được ngay

GROUP · 02

Edge case

TC-05 → TC-09 — bảo vệ các invariant.

→ TC-05 sửa preset không hồi tố
→ TC-06 xóa vai trò đang dùng → A giữ quyền
→ TC-07 chức năng không khả dụng → bỏ qua an toàn
→ TC-08 member truy cập cấu hình → bị chặn
→ TC-09 chức năng bị gỡ khỏi hệ thống → bỏ qua

GROUP · 03

Dev tự dựng

Bám theo quyết định ở Bước 0.

→ Hành vi cộng dồn vs thay thế khi áp lên lựa chọn tay đang có
→ Vai trò rỗng (chưa map chức năng nào)
→ Tải lớn: nhiều thành viên × nhiều vai trò

Hình 9.1 — Ma trận test case ba nhóm. Cột 3 yêu cầu dev chủ động dựng thêm — không có sẵn ID.

10 · Quy trình bàn giao

Bước 0 — chốt năm điểm trước khi code

Trước khi viết dòng code đầu tiên, năm câu hỏi dưới phải có câu trả lời từ CTO. Đừng đoán — đoán sai ở Bước 0 thì refactor cả module áp quyền.

1

Danh sách vai trò công việc giai đoạn 1

Vd Kế toán, Hỗ trợ, Vận hành… — và bộ chức năng mỗi vai trò map tới.
2

Hành vi áp preset: cộng dồn hay thay thế?

Chọn vai trò thì cộng dồn vào lựa chọn hiện có hay thay thế toàn bộ? Đề xuất: cộng dồn (union), hiển thị rõ thay đổi.
3

Nhiều vai trò / 1 thành viên — có cho kiêm nhiệm?

Đề xuất: có, hợp nhất union. Ô trùng không nhân đôi.
4

Hồi tố — xác nhận snapshot, không live binding

Áp preset là điền một lần (mặc định không hồi tố). Có cần thêm tính năng "đồng bộ lại thành viên theo preset mới"? Mặc định: không, để sau.
5

Ai được cấu hình preset?

Chỉ CTO, hay cả super admin? Ảnh hưởng tới phạm vi UI cấu hình.

Hình 10.1 — Năm câu hỏi Bước 0. Có câu trả lời thì code; chưa có thì hỏi, đừng đoán.

Bàn giao & deploy gate

Sau khi xong + UAT trên staging, dev chuẩn bị Test Report kèm bằng chứng thực tế: (1) video cấp quyền vai trò "Kế toán" bằng một thao tác áp đúng bộ chức năng; (2) demo tinh chỉnh tay sau khi áp; (3) áp nhiều vai trò hợp nhất đúng; (4) sửa preset không làm đổi thành viên đã cấp; (5) chặn được member truy cập cấu hình vai trò. Họp demo/review trực tiếp với CTO duyệt logic áp vai trò / union / không-hồi-tố, phạm vi quyền và độ ổn định.

Deploy gate — bất di bất dịch

CHỈ KHI CTO APPROVE mới deploy Production. Không có shortcut, không có ngoại lệ. Module phân quyền đụng tới mọi vai trò trong workspace — sai một bước là member dư/thiếu quyền hàng loạt.

Đó là toàn bộ đặc tả của FT-PERM-ROLE-PRESET-01. Tài liệu được sắp xếp theo trình tự PRD chuẩn — nếu sau khi đọc xong bạn vẫn lăn tăn ở một mục nào, hãy quay lại đúng mục đó thay vì dò lại từ đầu. Mười mục, mười câu hỏi: bạn đang vướng câu nào?

— Last reviewed: 04/06/2026. Phản hồi gửi về owaf.fakku@gmail.com.

Phân Quyền Theo Chức Năng Công Việc: Map Vai Trò → Bộ Quyền Có Sẵn

01 · Thông tin chung

Bốn trường meta cần đọc đầu tiên

02 · Bối cảnh

Vì sao cần lớp preset — và đâu là nguyên nhân gốc

03 · Mục tiêu & Chỉ số

Bốn chỉ số đo lường thành công

04 · Personas

Ai làm gì với feature này

05 · Luồng nghiệp vụ cốt lõi

Sáu bước, theo thứ tự

06 · Edge cases

Năm tình huống dev bắt buộc xử lý

07 · User stories

Bảng tham chiếu nhanh

08 · Business rules

Cấu trúc preset & quy tắc áp

Giao diện (gợi ý — dev tự tinh chỉnh UX)

09 · Acceptance & Test cases

Tám tiêu chí nghiệm thu

Ma trận test case

10 · Quy trình bàn giao

Bước 0 — chốt năm điểm trước khi code

Bàn giao & deploy gate

Doanh Nguyễn

Tiếp tục đọc

Phân Quyền Theo Chức Năng Công Việc: Map Vai Trò → Bộ Quyền Có Sẵn

01 · Thông tin chung

Bốn trường meta cần đọc đầu tiên

02 · Bối cảnh

Vì sao cần lớp preset — và đâu là nguyên nhân gốc

03 · Mục tiêu & Chỉ số

Bốn chỉ số đo lường thành công

04 · Personas

Ai làm gì với feature này

05 · Luồng nghiệp vụ cốt lõi

Sáu bước, theo thứ tự

06 · Edge cases

Năm tình huống dev bắt buộc xử lý

07 · User stories

Bảng tham chiếu nhanh

08 · Business rules

Cấu trúc preset & quy tắc áp

Giao diện (gợi ý — dev tự tinh chỉnh UX)

09 · Acceptance & Test cases

Tám tiêu chí nghiệm thu

Ma trận test case

10 · Quy trình bàn giao

Bước 0 — chốt năm điểm trước khi code

Bàn giao & deploy gate

Doanh Nguyễn

Tiếp tục đọc

Khi nào RBAC đầy đủ thắng preset điền nhanh — và ngược lại

Khi một thành viên dư quyền 6 tháng: postmortem của một workspace bị leak

Bốn cách thiết kế UI "cấp nhanh" cho màn phân quyền nặng