"Right" way to administer JIRA permissions

[Kevin]

I have a simple use-case: for almost all of our JIRA projects, I want to have a collection of users that can view/create tickets, and another that can view/create/be assigned/work tickets. So to me it seems as if I would use the 'users' and 'developers' roles.

So now I would like to assign users to a role. How do I do that? Per https://<name>.atlassian.net/secure/project/ViewProjectRoles.jspa I can assign default users, but there is even a note there specifying that default users only apply on project creation, so thats not helpful for me. There are groups https://<name>.atlassian.net/admin/groups that also share the label 'users' and 'developers' .. but, do roles just magically inherit from them ... wat?

In the past I've just gone through the permission schemes and assigned groups instead of roles, but that seems the wrong way to do it, yet the right way using roles seems to baffle me, and google searches are awash in others confusion, which doesn't help me.

[Nic Brough -Adaptavist- · Accepted solution]

Ok, I run into groups and roles all the time.

Groups are simple, they do what you expect. A group is a set of users.

The advantage to using groups in permission schemes is that it's blindingly obvious. If you say "Group ABC can do action X" then everyone in group ABC can do X in the projects you give that permission scheme to. The downsides are that you need a new permission scheme for each usage of groups and your administrators are the only ones who can edit groups or schemes. It quickly becomes a total nightmare for admins.

Roles are much more useful. You define a role as a global thing. The role can then be used in permission schemes, so that you can say "role CDE can do action Y". But, although I've just said they are "global", the people you put into a role are NOT global, they are put in a role inside the project. So you can put Alice and Bob into the role CDE in one project, and Chuck into the same role in another project, and they only get access to those projects. You can now use one permission scheme on several projects and it only allows access to the poeple in the roles in the projects. And of course, your project admins can maintain the users in the roles for their projects.

One additonal complexity for roles is that you can add groups to them as well, but that's just saying "Alice, Bob and everyone in group ABC"

In short, roles look scary, but they're the best option.

[Kevin]

Ahh I see, so then role are meant to just define the actions, not the who. And I now see that you can add users to a project in https://<name>.atlassian.net/plugins/servlet/project-config/<proj>/roles . So for existing projects I ( the unfortunate admin ) will have to pay the penalty of adding all of the users to each project role, whereas in the future the default users from the role would be applied.

I guess then too a downside of roles is that when we get a new developer or user, they will need to be added to all projects that they need access to, correct?

[Nic Brough -Adaptavist-]

Sort of - the roles are a way to put users (and/or groups) into individual projects. But yes, you've summed it up well there.

Yes, the downside of roles is that you need to add new users manually. But;

1) You can delegate that to the project admins. I.e. "your new developer in your team - up to you what projects you add them to, you've got admin on the projects"

2) You can still use groups - if your project admin adds group "Mr Flibble" to the role of "developer", then anyone you add to "Mr Flilbble" is counted as a developer.

[Patrick van der Rijst]

We usually base all permissons on Roles. Within the admin roles section you can already assign default memberships, which we connect to groups. When there are other people that are involved in the project, we add them individually in the Roles section within a specific project.

This way you allow a project administrator to maintain the permissions for his project. He can also remove the default membership of the groups to a role in his project. This way it's easier for you, as JIRA Admin, to maintain the high level permission schema.