When and how should project roles be used instead of groups in JIRA?

Question

It’s hard for me to understand when a person needs to configure JIRA permissions through groups and when they need to use project roles. I read the online documentation, however the difference between the two seems subtle.

A group seems simple enough. Group users into a named bucket. Assign group one or more permissions in the permission scheme to allow access to functions for any users in the group. Assign permission scheme a project to apply permissions to this project .

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

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

• JIRA has created several projects.
• All our managers, developers, etc. have the same permissions for all projects.
• Our customers have access only to their projects.

I think the best way to accomplish this is:

• Create group employees to which I add all our employees.
• Create one or more project roles to which I add the appropriate clients.
• Assign permissions to the default permission scheme using group employees.
• Copy the default permission scheme to the new project scheme, for example, the client scheme
• Assign a client schema to a specific client project.

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

What are the best practices for using JIRA groups and project roles ? What is the difference between the two?

Answer 1

We recommend working with roles, as it has several advantages.

a. You can customize the full role-based configuration.

For example, you may have a “verified” workflow transition that can only be performed by someone who is a tester.

You have the choice to add a transition condition: "the user is in a group test" or "the user has a role tester."

If you work in an organization in which users have different roles in different projects, selecting the first transition condition (the user in the group test) will not work (or you will need a new workflow for each project)

The same goes for notifications.
You can configure a notification for the "Problem resolved" event by indicating that "users in the group test" receive a notification or "users who have a role tester."

When using roles, adding someone to the project is very simple - just check what role the person has in the project, add them to the project configuration (view the elements), and you're done. He will have the correct permissions, get the right notifications ...

b. Configuration

When using roles for configuration, you do not need system administration rights to add someone to the project. The project manager will be able to add the user. No need to disturb the system administrator.

---

Looking at your description, I would

• The role of the project "employee"
• The role of the customer project
• Group "
• configure the project role so that team members are a default member of the project employee

This way you can use the same permission scheme for all projects. When adding a new project, you just need to add the client user ID to the client role. When a new employee begins, you add him to the employee group.

On the day when you have a specific, top-secret project in which you need access to only a few employees, you can remove the group’s employees from the “employee” role and add specific users to this role.

Hope this helps

Francis

Answer 2

Historically, JIRA has had groups in the first place. Then came the roles and the recommended way to manage authorization in most cases.

~ Matt

Answer 3

Groups are global. Roles can be considered as design (local) groups.

Roles are much better: with even more projects, you quickly get proliferation of groups and permission schemes (one per project).

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

But you get more flexibility. For example, at present, the role of an employee should be filled by your group of employees for each project, but as your company grows and complexity you may have different employees for one project without the need to change permission schemes.