Wednesday, September 22, 2010

JIRA Groups and JIRA Project Roles

Summary: JIRA groups are made up of JIRA users and can only be changed by JIRA administrators. JIRA project roles are made up of JIRA users and JIRA groups and can be changed per project by project administrators.

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

5 comments:

  1. This is very good.

    I 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.

    ReplyDelete
  2. 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?

    Thanks!

    ReplyDelete
  3. 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.

    ReplyDelete
  4. Hi,

    I 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

    ReplyDelete
  5. 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.

    ~Matt

    ReplyDelete