Return to site

JIRA Best Practices: Cấp quyền trong JIRA

March 2, 2018

Khi mới bắt đầu sử dụng JIRA của Atlassian, có vẻ khó khăn để làm quen với tất cả các tính năng mạnh mẽ của nó. Trong bài này, chúng ta sẽ đi vào chi tiết về Project Roles và mối quan hệ giữa Project Roles và các khái niệm phân quyền khác trong JIRA. JIRA là một hệ thống mạnh mẽ và linh hoạt, cho phép mỗi công ty có thể tùy chỉnh theo nhu cầu của họ. Vì tính linh hoạt của nó, việc cấu hình JIRA có thể khá phức tạp cho người quản trị JIRA. 

Đầu tiên, có nhiều khái niệm rất quan trọng cần phải hiểu khi nói đến việc phân quyền trong JIRA. Những khái niệm đó là: Users, Groups, Global Permissions, Permission SchemesProject Roles. Tôi mất khá nhiều thời gian để hiểu các khái niệm này, cũng như làm thế nào để sử dụng nó.

  • Global Permission trong JIRA là nơi bạn cấp quyền cho user trên toàn bộ hệ thống, áp dụng cho tất cả các project. Các quyền này bao gồm: JIRA System Administrators, JIRA Administrators, JIRA UsersBrowse, Users (và còn nhiều nữa)

Một Permission Scheme là một nhóm các quyền trên project và mỗi một quyền này sẽ được cấp cho Users, Groups, hoặc Project Roles. Mỗi một project trên JIRA chỉ có thể sử dụng một Permission Schemes nhưng một Permission Schemes có thể được sử dụng bởi nhiều project JIRA. Bằng cách này, bạn có thể cấp cho user các quyền truy cập khác nhau khi họ tham gia vào các dự án JIRA khác nhau.

  • Users: là những người có thể đăng nhập vào ứng dụng JIRA của bạn.
  • Groups: chỉ đơn giản là nhóm người có thể đăng nhập vào ứng dụng JIRA của bạn.
  • Mỗi Project JIRA có Project Roles được gán cho user hoặc group. Project Roles được áp dụng cho tất cả các project JIRA. Project Roles mặc định là: Administrators, Developers và Users. Người quản trị JIRA có thể thêm Project Roles vào trong ứng dụng Jira bên cạnh các Project Roles mặc định.

Chúng ta nên làm thế nào

Chúng tôi đề nghị khi thiết lập quyền trong JIRA:

  1. Khi cấp quyền trong một Permission Scheme, chỉ cấp quyền cho Project Roles, và không cấp quyền cho một Users hay Groups cụ thể nào.
  2. Sau đó, bên trong bảng quản trị Project của JIRA, bạn có thể gán Project Roles cho Users hay Groups thích hợp.
  3. Bằng cách này, bạn có thể sử dụng cùng một Permission Scheme cho nhiều Project và giảm thiểu sự phức tạp trong cấu hình JIRA của bạn.
  4. Đôi khi, cần cấp cho từng User hoặc Group một quyền cụ thể trong Permission Scheme, nhưng đây là ngoại lệ chứ không phải quy tắc.

Dưới đây là một đồ thị minh họa cho cách thiết lập này:

Ba Project Roles

Như đã đề cập, mỗi Project JIRA có ba project roles mặc định; Administrators, Developers, và Users. Đây là những mẫu tốt để xác định từng Role trước khi gán cho bất kỳ quyền nào đối với Role. Đây là một ví dụ về các định nghĩa Role:

  • Administrators: Người / nhóm người quản lý dự án. Admins cần được cấp quyền thêm Users hoặc Groups mới vào Project và có thể quản lý Components và Versions.
  • Developers: Những người trực tiếp thực hiện các Issue trong project, có thể chỉnh sửa issues và nhật ký làm việc (worklogs). Những người trong Role này là những người được assign các issue.
  • Users: Những người không thực hiện công việc thực tế trên các Issue nhưng phải có khả năng tạo Issue, xem Issue và bình luận về chúng.

Bạn có thể muốn định nghĩa Project Roles của mình một cách khác nhau và tạo các role bổ sung dựa trên nhu cầu của bạn, đó là tốt. Chỉ cần đảm bảo rằng định nghĩa của bạn về roles được sử dụng nhất quán trên tất cả các dự án của bạn.

Xoá Quyền

Xoá Quyền thường bao gồm một số cuộc thảo luận. 

Một câu hỏi thường phát sinh là: Chúng ta có nên cho phép mọi người xóa bình luận về Issues, xoá các Issues, và xóa các nhật ký công việc(worklogs)? 

Một lý do để không cho phép mọi người xoá bình luận là bạn có thể mất một phần quan trọng của toàn bộ chuỗi bình luận trong Issues, điều đó có nghĩa là các bình luậnkhác đột nhiên không có ý nghĩa nữa. 

Một số công ty cảm thấy tương tự về xóa Issues - điều đó có nghĩa là mất đi một chủ đề quan trọng trong lịch sử các Issues của Project. Tuy nhiên, đối với quyền về Log Work, bạn thường muốn cấp cho người dùng quyền xóa Worklog của họ. Bởi vì khi di chuyển một worklog từ một Issue sang Issue khác, bạn đang thực sự xóa worklog trên một Issue và tạo nó trên một Issue khác. 

JIRA cung cấp tính linh hoạt đáng kể cho các tổ chức để quản lý các đội của họ và đạt được mục tiêu của họ, nhưng điều quan trọng là phải nắm bắt được project roles và các khái niệm phân quyền trước khi bắt đầu.