Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Project Permissions – done right - X-Post


Well, this is a pleasant change—no talking about all the changes and upheaval in the Atlassian space. Just a good, old-fashioned technical guide.

So, do you know the number one mistake I see when I log onto a new Jira instance that hasn’t been managed well? The first thing I’ll often see is a bombardment of Permission Schemes – each individualized to a project and with permissions assigned directly to groups. Now, don’t get me wrong; this solution is functional. It’s just not efficient. You have to expend time and effort to figure out which Permission Scheme and which group to make any change. And there is no help if you have to make massive, sweeping changes. You’ll be at that all day.

So I thought I’d spend today talking about Project permissions, what they do, and how to use Project Roles to allow individualized permissions per project while minimizing the number of Permission schemes you have to manage.

So, what is the point of all this?

That is a fair question. For some people, the defaults will work just fine. So why bother with the minutia? Well, eventually, you will run across a use case that will require a slightly different permission setup. It could be a top-secret project to which you’d like to limit viewership. Or a process you’d like to be as transparent as possible. Understanding where and how to make changes will save you a lot of time when these situations come up.

There is also a performance concern. If you have one permission scheme per project on Very Large Jira Instances, that can quickly add up. Using an excellent method to share permission schemes can become key to helping your instance perform well. That’s why I always advocate the use of Project Roles. It’s a way to map permissions to users and groups so that you can reuse the permission scheme as much as possible.

Permission Nodes

So, what do all the permissions even do? If you read through the list on its own, it’s not immediately apparent. I mean, let’s take “Edit Sprints” and “Manage Sprints.” On the surface, they both sound like they should do the same thing, right? If you haven’t guessed, they are not the same thing. So – hold on, this section is going to pack a lot of information.

The first section here is “Project Permissions,” and they manage how you can interact with a given project and its issues – if at all.

Permission Node    What it does (In English)

Administer ProjectsGrants access to the Project Administration Screen
Browse ProjectsLets someone can see the project and its issues
Edit SprintsAllows editing of the Sprint Name and Goal, but nothing else
Manage SprintsComplete access to Create, Edit, Start/Stop, and Delete sprints
Service Desk AgentOn a Service Desk Project allows someone to interact with Customers and use the project’s JSM Features. Note: This will use up an Agent License on Jira Service Management
Start/Complete SprintsLets a person start or complete a Sprint
View Development ToolsDetermines whether a person can see the Development integrations on issues
View Read-Only WorkflowAllows you to view a chart of the workflow on an issue

The next section we have here is the “Issue Permissions.” This section determines how users interact with the issues in a given project, including who can create issues, be assigned to them, close them out, etc.

Permission Node    What it does (In English)

Assignable UserWhether issues can be assigned to a user or not.
Assign IssuesWhether you are allowed to assign this issue to other people
Close IssuesLets you move an issue into a final workflow state.
Create IssuesLets you create new issues in the project.
Delete IssuesGrants the ability to delete an issue.*  I’ll talk more about this shortly.
Edit IssuesLets you modify issue fields after creation.
Link IssuesAllows you to link this issue to another issue shortly.
Modify ReporterLets you modify the reporter to someone else.
Move IssuesAllows you to change the issue type or move it to another project. Note: If moving to another project, you must have the “Create Issues” permissions in that project.
Resolve IssuesAllows you to set the resolution on an issue.
Schedule IssuesGrants you the ability to set a due date on an issue.
Set Issue SecurityIf configured, allows you to set the issue security on a given issue.
Transition IssuesAllows you to change the status on an issue.

After this, we get a smaller section detailing how users can interact with voters and watchers on issues.

Permission Node    What it does (In English)

Manage WatchersAbility to add others as watchers on an issue
View Voters and WatchersSee who has voted on or is watching an issue

Next is the permissions related to issue Comments. This one is where I’ll usually spend a fair bit of time detailing, as comments are one of the main ways people interact with issues. For example, if you wish for comments to be a record and therefore immutable, you’d want to remove anyone’s ability to edit or delete comments – even their own.

Permission Node    What it does (In English)

Add CommentsGrants a user the ability to comment on issues within a project.
Delete All CommentsGive you the ability to delete anyone’s comments
Delete Own CommentsAllows you to delete only your comments
Edit All CommentsLets you edit anyone’s comments
Edit Own CommentsAllows you to edit your comments.

And now we have the Attachment permissions – which, as you can guess, controls who can post files to issues. These are set up very similarly to the Comment Permissions, so the same concepts apply.

Permission Node    What it does (In English)

Create AttachmentsLets you attach files to an issue
Delete All AttachmentsGrants you the ability to delete anyone’s files on an issue.
Delete Own AttachmentsGives you the ability to delete your files on an issue.

And lastly, we have the Worklog permissions. These permission nodes affect how users can interact with Work logs, one of Jira’s more obscure features. You can log work on an issue by going to an issue (where you have the appropriate permissions), Clicking “More” -> “Log work.” Here you can put how much time you’ve logged against an issue, when you did the work, and how much work is left to do. If you have already added a time-based estimate to the task, it will deduct the hours from the work log from the estimate automatically, as well.

Permission Node    What it does (In English)

Delete All WorklogsGives you the ability to delete anyone’s work log
Delete Own WorklogGrants you the ability to delete your work log
Edit All WorklogLets you edit anyone’s work log
Edit Own WorklogAllows you to edit your work log
Work on IssuesThe ability to go to “More“->”Log work” and submit a work log

And that’s all the Project Permission nodes, which will be the boring part. I promise, if you’ve made it here, it gets better.

How to Assign Permissions

So – knowing what these permissions do is one thing. But how do you map them to users? Well, if we go to edit a Permission Scheme, this is what we get:

Here, we can see the various permission nodes we just talked about and who is currently assigned. We click the “Grant Permission” button on the screen’s upper right-hand side to add a new assignment.

Here, we are presented with a screen asking for a Permission node and who to assign it to.

Note: I have already clicked “Show More” to show the full list.

Here, you can see we can assign permissions to a whole host of people based on several criteria. We can even specify it down to a custom field on an issue. However, I do not recommend you do too much anything below “Group” unless you have a particular use case for it (such as only the reporter can close an issue.) For the most part, I recommend you assign the vast majority of permissions to Project Roles. The exception here is you also want to add your Administrative group into the permissions schemes, so your Admin team doesn’t get locked out of projects.

So, what are these Project Roles you keep going on about?

Project Roles are a way to map users and groups to a project directly. You can see your current users assigned to the Project Roles by going to your “Project Administration Screen” -> “Users and roles.” Here you can see who is assigned to your Project and what roles do they currently reside in.

This feature is the key to how you can reuse permission schemes across projects without having to grant everyone access to all your projects. If you map a permission node to a Project Role and then a User to that same Project role, users get those permissions on your Project! This also lets your Project Admins control who can access their Project – greatly simplifying your workload.

Because who is on what Project Role is a per-project setting, the User is only granted permissions for your Project. Assigning them to a Project Role will not affect anyone else – even if you are using the same Permission Scheme. This method is how you reduce the number of Permission Schemes in your instance, by setting up Permission Schemes that use Project Roles and sharing them between projects.

So how do you setup your permission schemes?

The way I see it, there are five basic “Access Levels” for a given project. Generalized, they are as follows:

  • Anyone can see, create, comment, and work on issues
  • Anyone can see, create, and comment on issues, but only the Team can work on issues
  • Anyone can see or create issues, but only the team can comment or work on issues.
  • Anyone can see issues, but only the team can create, comment, and work on issues.
  • Only the team can see, create, comment, and work on issues.

So, I’ll typically create these five Permission schemes, and all mapped to the appropriate Project Roles to create the desired Access Levels. Those are my five standard permission schemes.

Then, when I coach a new team on Jira, I’ll pull their manager aside, explain these five access levels, and ask where he thinks his Team lies and why. Based on their response, I’ll suggest an appropriate access level. Unless I have a good reason not to, I’ll always guide towards more visibility than less, which means most of my projects tend to be somewhere in the top 3 permissions schemes.

And that's it for this week!

Last week's post did bring up some lively discussion - so I'm hoping this one is a little less controversial. If you are interested in seeing more from me, I post these articles a week earlier at Otherwise, I'll see you right here next week! And until next time, Have you updated your Jira issues today?

1 comment

Alexander Pappert
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Jan 10, 2021

Thank You for this guide.

Project Roles / Permissions are very useful.


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events