Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng thế này: bạn là PM của một sản phẩm fintech, và một buổi sáng đẹp trời, một bạn dev junior vô tình đóng (close) toàn bộ 40 issue trong sprint đang chạy vì bạn ấy "test nút bấm". Hoặc tệ hơn: một cộng tác viên bên ngoài (external contractor) vô tình nhìn thấy toàn bộ backlog chứa thông tin về roadmap nhạy cảm mà lẽ ra chỉ nội bộ mới được xem. Cả hai tình huống này đều không phải lỗi con người thuần túy — chúng là lỗi cấu hình phân quyền.
Trong Jira, ai được làm gì, ở đâu, với issue nào — tất cả đều được quyết định bởi hệ thống phân quyền. Với vai trò PM, bạn không nhất thiết phải là người thiết lập tận gốc (đó thường là việc của Jira Admin), nhưng bạn bắt buộc phải hiểu cơ chế này. Vì khi team gặp lỗi "không tạo được issue", "không thấy được project", "không assign được task", 90% nguyên nhân nằm ở phân quyền. Và bạn là người đầu tiên team sẽ hỏi.
Bài này giúp bạn nắm vững ba tầng phân quyền của Jira, hiểu Permission Scheme hoạt động ra sao, và quan trọng nhất: biết cách chẩn đoán và xử lý các vấn đề access control mà không cần chờ IT ba ngày mới trả lời email.
Khái niệm cốt lõi
Jira kiểm soát truy cập theo ba tầng riêng biệt, xếp chồng lên nhau. Hiểu được ranh giới giữa ba tầng này là chìa khóa để không bị rối.
Tầng 1 — Global Permissions (quyền toàn hệ thống)
Đây là tầng cao nhất, áp dụng cho toàn bộ instance Jira chứ không riêng project nào. Global permission trả lời câu hỏi kiểu: "Ai được quyền quản trị Jira?", "Ai được tạo project mới?", "Ai được quản lý user và group?".
Người có quyền Jira Administrators hoặc Site Administrators (trên Cloud) là người nắm quyền lực lớn nhất — họ có thể cấu hình mọi scheme, thêm/xóa user, thay đổi cả những thứ ảnh hưởng tới hàng trăm project. Vì thế, nhóm này nên cực kỳ nhỏ — thường chỉ 2–3 người trong một công ty vài trăm nhân sự.
Điểm PM cần nhớ: bạn thường không phải Jira Admin, và cũng không nên đòi quyền này. Quyền càng lớn, rủi ro càng cao.
Tầng 2 — Project Permissions & Project Roles (quyền cấp project)
Đây là tầng bạn — với tư cách PM — làm việc nhiều nhất. Mỗi project có một Project Administrator (quản trị viên dự án). Người này không đụng được vào hệ thống chung, nhưng toàn quyền trong phạm vi project của mình: thêm thành viên vào project, gán vai trò (role), cấu hình một số thứ trong project.
Khái niệm quan trọng nhất ở tầng này là Project Role (vai trò dự án). Jira mặc định có ba role: Administrators, Developers, và một số bản có thêm Users. Role là một cái "hộp" trừu tượng — bạn bỏ user hoặc group vào hộp đó, rồi Permission Scheme sẽ tham chiếu tới cái hộp, chứ không tham chiếu trực tiếp tới từng cá nhân.
Đây là ý tưởng thiết kế cực kỳ hay: thay vì phải sửa Permission Scheme mỗi khi có người mới vào team, bạn chỉ cần thêm họ vào đúng role của project. Scheme giữ nguyên, chỉ nội dung của role thay đổi.
Tầng 3 — Issue-level Permissions qua Permission Scheme
Đây là trái tim của bài học. Permission Scheme là một tập hợp các quy tắc quy định: với từng loại hành động lên issue, ai được phép làm.
Một Permission Scheme liệt kê nhiều permission cụ thể, ví dụ:
- Browse Projects — được nhìn thấy project và issue trong đó (quyền nền tảng nhất; mất quyền này là "vô hình").
- Create Issues — được tạo issue mới.
- Edit Issues — được sửa nội dung issue.
- Assign Issues / Assignable User — được gán issue cho người khác / được nhận issue.
- Transition Issues — được chuyển trạng thái (kéo qua các cột workflow).
- Close Issues, Resolve Issues — được đóng, giải quyết.
- Delete Issues — được xóa (quyền nguy hiểm, nên hạn chế tối đa).
- Add Comments, Manage Watchers, Add Attachments...
Điểm mấu chốt: một Permission Scheme có thể được dùng chung cho nhiều project. Đây vừa là ưu điểm (chuẩn hóa, dễ quản lý) vừa là cái bẫy (sửa một scheme dùng chung có thể vô tình ảnh hưởng 20 project khác).
Issue Security Scheme — tầng ẩn ít người biết
Ngoài ba tầng trên, còn một lớp tinh vi hơn: Issue Security Scheme. Nếu Permission Scheme kiểm soát "ai làm được gì trong project", thì Issue Security kiểm soát "issue nào được ai nhìn thấy" — ở mức từng issue riêng lẻ. Ví dụ: trong một project chung, các issue gắn nhãn "Confidential" chỉ hiển thị cho ban lãnh đạo, còn dev thường không thấy chúng tồn tại. Đây là công cụ mạnh nhưng dễ gây "issue biến mất một cách bí ẩn", nên dùng có chủ đích.
Tình huống thực tế
Tình huống 1 — Contractor nhìn thấy roadmap nhạy cảm ở một startup fintech TP.HCM
Một startup fintech ở Quận 1 (gọi là VíXanh) thuê 3 dev freelance để đẩy nhanh một tính năng. Jira Admin, vì tiện, thêm luôn cả 3 người này vào group jira-software-users — group mặc định có quyền Browse rất rộng. Kết quả: 3 contractor nhìn thấy toàn bộ các project, bao gồm cả project "Strategy 2027" chứa kế hoạch gọi vốn Series A và định giá dự kiến.
Ba tuần sau, một trong ba người rời đi và sang làm cho đối thủ. Thông tin định giá bị lộ.
Diễn giải: Vấn đề không phải contractor xấu, mà là cấu hình sai ở tầng grantee. Đáng lẽ contractor chỉ nên được thêm vào Project Role "Developers" của đúng project họ làm việc, và Permission Scheme của project "Strategy 2027" phải cấp Browse Projects chỉ cho role nội bộ, không cho group chung.
Bài học: Đừng bao giờ dùng group toàn cục (jira-software-users) làm grantee cho quyền Browse trên các project nhạy cảm. Hãy dùng Project Role, vì role có phạm vi gói gọn trong từng project. Nguyên tắc vàng: least privilege — cấp đúng mức tối thiểu cần thiết.
Tình huống 2 — Cả team "không transition được issue" tại một công ty outsourcing Đà Nẵng
Một công ty phần mềm outsourcing ở Đà Nẵng (khoảng 120 kỹ sư) chuyển 5 project sang một Permission Scheme mới do Admin thiết kế lại. Ngay sáng hôm sau, dev báo ầm lên: kéo thẻ trên board bị lỗi "You do not have permission to transition this issue". Sprint đứng hình gần nửa ngày.
PM vào điều tra và phát hiện: trong scheme mới, permission Transition Issues chỉ được cấp cho Project Role "Administrators", còn role "Developers" thì bị bỏ sót. Mà 95% team nằm trong role Developers.
Diễn giải: Đây là lỗi kinh điển khi thiết kế scheme — chỉ nghĩ đến quyền tạo/sửa mà quên mất quyền vận hành workflow. Transition là hành động dev làm hàng chục lần mỗi ngày.
Bài học: Khi review một Permission Scheme, đừng chỉ kiểm tra Create/Edit. Hãy đi qua cả nhóm quyền workflow: Transition, Resolve, Close, Assign. Và luôn test scheme mới trên một project thí điểm trước khi áp cho 5 project cùng lúc.
Tình huống 3 — "Ma issue" tại một ngân hàng số
Một ngân hàng số ở Đông Nam Á dùng Issue Security Scheme để ẩn các issue liên quan đến lỗ hổng bảo mật, chỉ cho phép group "Security Team" xem. Một PM sản phẩm báo cáo rằng dashboard của anh ta hiển thị "23 open bugs", nhưng khi anh xin số liệu từ team security thì họ nói có tới 31. Con số lệch nhau 8 issue.
Nguyên nhân: 8 issue kia được đặt Security Level "Confidential", nên với con mắt của PM chúng hoàn toàn vô hình — không xuất hiện trong JQL, không đếm vào dashboard, như thể không tồn tại.
Diễn giải: Issue Security hoạt động rất triệt để — issue bị ẩn không chỉ khỏi màn hình mà khỏi mọi phép truy vấn của người không có quyền. Điều này tốt cho bảo mật nhưng nguy hiểm cho báo cáo nếu bạn không biết nó đang bật.
Bài học: Khi số liệu report bị lệch một cách khó hiểu, hãy nghi ngờ Issue Security Scheme. PM cần biết project của mình có bật Issue Security hay không, và nếu có thì mình có nằm trong security level phù hợp để thấy đủ dữ liệu không.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để bạn kiểm tra và điều chỉnh phân quyền (áp dụng cho Jira Cloud; Server/Data Center tương tự).
Bước 1 — Xác định Permission Scheme mà project đang dùng. Vào Project settings → Permissions. Ở đầu trang bạn sẽ thấy tên scheme đang áp dụng (ví dụ "Default software scheme"). Ghi nhớ: nếu scheme này dùng chung nhiều project, mọi thay đổi sẽ lan ra tất cả.
Bước 2 — Đọc bảng permission theo cột grantee. Trong trang Permissions, mỗi dòng là một permission (Browse, Create, Edit...), cột bên phải là các grantee được cấp. Hãy đọc kỹ Browse Projects trước — đây là quyền gốc, mất nó thì mọi quyền khác vô nghĩa.
Bước 3 — Kiểm tra thành viên của các Project Role. Vào Project settings → People (hoặc Roles). Xem ai đang nằm trong role nào. Đây là nơi bạn — với quyền Project Admin — có thể tự thêm/bớt người mà không cần đụng vào scheme.
Bước 4 — Nếu cần cấp quyền cho người mới, hãy thêm họ vào role, đừng sửa scheme. Ví dụ dev mới vào: thêm vào role "Developers" của project. Xong. Scheme tự động áp quyền qua role.
Bước 5 — Nếu buộc phải sửa scheme, hãy nhân bản (copy) trước. Nếu bạn thấy scheme thiếu quyền và scheme đó dùng chung, đừng sửa trực tiếp. Yêu cầu Admin copy scheme, đặt tên mới, sửa bản copy, rồi gán bản copy cho riêng project của bạn. Tránh làm hỏng project khác.
Bước 6 — Dùng công cụ "Permission Helper" để chẩn đoán. Jira có công cụ Permission Helper (Admin mới truy cập được): nhập tên user + issue + permission cần kiểm tra, hệ thống sẽ giải thích chính xác vì sao người đó có/không có quyền, và grantee nào đang cấp quyền đó. Đây là "máy X-quang" cho phân quyền — khi bí, hãy nhờ Admin chạy công cụ này thay vì đoán mò.
Bước 7 — Kiểm tra Issue Security nếu số liệu bất thường. Vào Project settings → Issue security để xem project có bật security scheme không, và bạn thuộc level nào.
Lỗi thường gặp & mẹo
Lỗi 1 — Gán quyền trực tiếp cho từng user hoặc group toàn cục. Điều này biến việc quản lý thành cơn ác mộng: mỗi lần nhân sự thay đổi, bạn phải sửa scheme. Mẹo: luôn cấp quyền qua Project Role. Role là lớp trừu tượng giúp scheme ổn định, còn con người thì cứ ra vào role thoải mái.
Lỗi 2 — Quên cấp quyền Assignable User. Bạn thấy tên một người trong project nhưng không assign issue cho họ được. Nguyên nhân: họ có Browse nhưng thiếu Assignable User. Hai quyền này khác nhau: một cho "được nhận việc", một cho "được xem".
Lỗi 3 — Sửa scheme dùng chung mà không biết. Như đã nói, một scheme thường phục vụ nhiều project. Mẹo: trước khi sửa, hỏi Admin "scheme này còn project nào dùng nữa không?" hoặc xem danh sách associated projects.
Lỗi 4 — Nhầm lẫn giữa "không thấy project" và "không có tài khoản". Trên Jira Cloud, người dùng còn cần được cấp product access / application access (một license seat) thì mới đăng nhập vào Jira được — đây là điều kiện trước cả Browse Projects. Nếu ai đó "hoàn toàn không thấy gì", hãy kiểm tra họ có license không, trước khi ngờ scheme.
Mẹo vàng — Áp dụng nguyên tắc least privilege và định kỳ audit. Mỗi quý, hãy rà lại danh sách người trong các role, đặc biệt là quyền nguy hiểm như Delete Issues và Administer Projects. Người rời công ty, contractor hết hợp đồng — họ có bị gỡ khỏi role chưa? (Chủ đề audit log sẽ được đào sâu ở bài kế tiếp.)
Bài tập thực hành
Chọn một project Jira bạn đang tham gia (nếu không có quyền Admin, phối hợp với Jira Admin của công ty) và hoàn thành các nhiệm vụ sau:
- Lập bản đồ phân quyền. Vào Project settings → Permissions và ghi lại: ai (grantee nào) đang được cấp 5 quyền sau: Browse Projects, Create Issues, Transition Issues, Assign Issues, Delete Issues. Nhận xét xem có quyền nào đang được cấp quá rộng không.
- Kiểm tra role. Liệt kê thành viên trong role Administrators và Developers. Có ai lẽ ra không nên nằm trong role Administrators không?
- Mô phỏng tình huống. Giả sử có một contractor sắp vào làm 1 tháng, chỉ được xem và tạo bug, không được xóa hay chuyển trạng thái. Viết ra kế hoạch: bạn sẽ thêm họ vào đâu, cần scheme nào, và làm sao đảm bảo họ không thấy các project khác.
- Săn "issue ẩn". Kiểm tra project có bật Issue Security Scheme không. Nếu có, mô tả các security level và ai thấy được cái gì.
- (Nâng cao) Soạn một email đề xuất gửi Jira Admin, trình bày một điểm phân quyền bạn cho là rủi ro và cách khắc phục theo nguyên tắc least privilege.
Tóm tắt
Phân quyền trong Jira vận hành theo ba tầng: Global (quản trị toàn hệ thống, dành cho Jira Admin), Project (quản trị từng dự án qua Project Admin và Project Role), và Issue-level (kiểm soát chi tiết từng hành động thông qua Permission Scheme). Bên cạnh đó, Issue Security Scheme là lớp ẩn kiểm soát ai nhìn thấy issue nào.
Điều quan trọng nhất cần khắc cốt: luôn cấp quyền qua Project Role, không gán trực tiếp cho cá nhân; không sửa scheme dùng chung mà hãy copy trước; và luôn theo nguyên tắc least privilege — cấp đúng mức tối thiểu. Với vai trò PM, bạn không cần trở thành Jira Admin, nhưng khi hiểu rõ cơ chế này, bạn sẽ tự chẩn đoán được phần lớn sự cố "không làm được X" của team, bảo vệ được thông tin nhạy cảm, và trở thành người mà cả dev lẫn Admin đều tin tưởng khi có chuyện về access control.