The difference between groups and project roles seems to confuse many JIRA administrators. This article explains the differences and what each one is good for. Up until a few years ago JIRA had users and groups of users, but no project roles. Groups were pretty powerful - wherever you could do something with a user, you could probably use a group instead.
For instance, if you wanted to allow a user John.Smith to change the reporter field in your issues, you could
1. Create a new permission scheme named something like "John.Smith can change reporter"
2. Add the John.Smith user to the appropriate Modify Reporter permission entry in the new permission scheme
3. Change the appropriate projects to use the new permission scheme
You could also do the same thing with a group
1. Define a new JIRA group "Can Modify Reporters"
2. Add the user John.Smith to the new group
3. Create a new permission scheme named something like "My new group can change reporter"
4. Add the group (instead of the user) to the appropriate Modify Reporter permission entry in the new permission scheme.
5. Change the appropriate projects to use the new permission scheme
All good so far, but there are two main problems with groups: scaling and updating
Scaling
If I want John.Smith to be able to edit the reporter in some of my projects, and also allow a different user Jane.Bloggs do the same in some other projects, then I have to create two permission schemes, one for each user. If I then decide that they are both allowed to edit the reporter in some shared projects, then I need a third permission scheme. With lots of users this leads to an explosion in the number of permission schemes (or any other JIRA scheme that supports groups). Keeping track of the difference between each of these schemes is tedious and error-prone, even with the scheme comparison tools.
Updating
Only JIRA administrators can change the membership of groups, which means extra work for them that could be better handled by JIRA project leads.
Project Roles
What was needed was another level of indirection and that's what exactly JIRA project roles are. Every JIRA project has three default project roles - Administrators, Developers and Users. The default roles can be changed, but for now let's stick with those three. For each role in every project, you can define who plays that role by adding a user or a group to the role.
Viewing a project's roles |
A project's default roles |
Once you've chosen who plays each role for each project, we can use the roles in our schemes. For instance, when you look at a permission scheme, you'll see that all of the permissions are granted to project roles, not to users or groups. The key thing about roles is that they can be changed per project by people who aren't JIRA administrators.
Creating a New Role
Another way to understand what's going on here is to create a new role. Let's say for some reason we want to allow a Technical Publications user assigned to each project to modify the reporter of an issue.
The default permission scheme allows users in the Administrator role for a project to modify the reporter of an issue. We don't want to allow tech pubs to administer the project, just give them that one specific permission.
We can create a new role "Technical Publications" in Admin, "Users, Groups & Roles", Project Role Browser. We can also add our Tech Pubs lead Bobby.Jo as a default member of the new role so that she will be in the Tech Pubs role for all projects by default.
Adding the new "Technical Publications" project role |
Now every JIRA project has this new role. We can add the appropriate tech pubs user (or group) to the Tech Pubs role for each project. Once the users for this role have been added, we can edit the permission scheme and add the Tech Publications role to the Modify Reporter permission entry. The permission scheme now checks which users are in the role for each project, rather than looking at a fixed list of users or groups of users.
If the tech pubs person changes for the project, then the people with the project Administrator role can change the members of the Technical Publications role for their project. And there is no need to ask the JIRA administrator to make the changes.
Should I use a group or a project role?
If you want to refer to the same set of users across multiple projects, use a group. If you want to refer to a set of users that is different per project, use a role.
JIRA Versions
All
Documentation
http://confluence.atlassian.com/display/JIRA/Managing+Groups
http://confluence.atlassian.com/display/JIRA/Managing+Project+Roles
This is very good.
ReplyDeleteI wish I had been able to read this when I set up all my JIRA projects a few years ago! My groups/roles are really untidy but luckily they do not change much.
You mention that it's possible to configure the default groups a new user is assigned to (which by default are "jira-*". Where can one do this?
ReplyDeleteThanks!
The default roles for projects can be changed. When a new user is created, they are only a member of jira-users, and I don't think that can be changed without custom work.
ReplyDeleteHi,
ReplyDeleteI do believe you need both.
User and groups is to structure the user in accordance with the organisation, read same as Active Directory and that structure.
Roles is to define a project and without knowing who will work in the project you setup a security/permission model.
The you map the user/group to the role.
If you would compare to Active Directory and Microsoft standard the user goes into global groups and global groups goes into local groups and local groups get the permission. In jira the local group is the role.
Anyhow that is how we view it and set it up to easy the administration and delegation of jira.
/Carl-Johan Wik
I agree. The problem is that many people still use just groups in JIRA, when I think that they should be using roles, and those roles should use groups as necessary. They're both necessary.
ReplyDelete~Matt
Hi,
ReplyDeleteI am new to JIRA and need help. Specifically I wish to understand are Project Roles local i.e. if Project-Admin-of-Project-A creates a *Project-Role-Developer* then can the Project-Administrator-B of Project-B also use (or create) *Project-Role-Developer* but assign different users such that users assigned by Project-Admin-A to Project-Role-Developer may see only Project-A while the users assigned by Project-Admin-B to Project-Role-Developer may see only Project-B?
Currently at my work we wish to create multiple projects. In our case, one user (let's say John.Smith) should be able to see only his project (let's say 'Project-John'). John.Smith should not be able to see any other project. Similarly Mary.Lamb should be able to see 'Project-Mary'.
To accomplish the above I understand I can create a Project-Role-John and assign the user John.Smith to Project-Role-John, create a permission scheme Permission-Scheme-John and assign the Project-Role-John to appropriate permissions, and finally assign the permission scheme Permission-Scheme-John with Project-John. Similarly for the user Mary.Lamb.
Is it possible that only one project role Project-Role-Developer is created and John.Smith and Mary.Lamb are added to the same Project-Role-Developer but by their respect Project-Admin but John.Smith should see only Project-John and Mary.Lamb should see only Project.Mary?
It's a long question but any help is appreciated.
Yes, that's quite convoluted. It sounds like you have two projects Project-John and Project-Mary. You should use a role such as Developers (only create a new one if it does something different). Then add John to the Developers role in Project-John and add Mary to the Developers role in Project-Mary. Both projects can use the same permission scheme which should give Browse Projects permission to the Developers role.
ReplyDeleteNow John can only see Project-John and Mary can only see Project-Mary. Hope that helps.
Thank you Matt.
DeleteI tested and it worked. I had tried the same earlier as well but it didn't work at that time and that's why I had to ask such a long question. But I guess in my earlier attempt I might have used jira-users in my Permission scheme.
In any case, glad that it's resolved for me now.