When and how should one use project roles instead of groups within JIRA?

Question

I am having a little difficulty understanding when a person should configure JIRA permissions using groups and when they should use project roles. I have read the online documentation, however, the difference between the two seems subtle.

A group seems simple enough. Group users into a named bucket. Assign the group to one or more permissions within a permission scheme to enable access to functionality for any users within the group. Assign the permission scheme to a project to apply the permissions to that project.

A project role seems very similar. It does all of the above except that you can also add groups to project roles. It seems that a project role also allows a project administrator to add their own users to a project instead of requiring a system administrator.

However, I am not sure how I can leverage this. Here is an example of what I want to achieve.

1. Have multiple projects created in JIRA.
2. All of our managers, developers, etc. have the same permissions across all projects.
3. Our clients have access only to their projects.

I think that the best way to accomplish this is to:

1. Create an employees group to which I add all of our employees.
2. Create one or more project roles to which I add the appropriate clients.
3. Assign permissions to the Default Permissions Scheme using the employees group.
4. Copy the Default Permission Scheme to a new project specific scheme, e.g., client-scheme
5. Assign the client-scheme to the client specific project.

However, it seems that I am not leveraging project role membership. How does this come into play?

What is the best practice for using JIRA groups and project roles? What is the different between the two?

Answer 1

Historically, JIRA had groups first. Then roles came along and are the recommended way to control authorization in most cases.

~Matt

Answer 2

Groups are global. Roles can be thought of as per-project (local) groups.

Roles are much better: else with a large number of projects you quickly end up with a proliferation of Groups and permission schemes (one per project).

You lose nothing by using role-based permission schemes, since you can add a Group to a role.

But you gain a lot of flexibility. Eg you'd currently have the Employee role be filled with your Employees group for every project, but as your company and complexity grows, you can have different Employees per project, without having to change the permission schemes