“May you live in interesting times.” Well, this has described the past few weeks. Apparently, the thing people love more than drama is continued drama, as last week’s numbers easily eclipsed those of the week before that, topping out last Thursday at 2.7k page views. No joke, last week’s post got 3,355 page views, which is a number I’m still wrapping my head around.

If you’ve just discovered this blog in the past few weeks, Welcome! Happy to have you come back. Today’s post should be more along the lines of what you should expect – which are tutorials and best practices. One of the last posts I did before I started the annual “Team event” posts was on the Jira Object Model, a tool that helps you understand how Jira determines which fields are displayed to you. Today, I want to continue along that thread and discuss how Jira determines which permissions get assigned to you. Unfortunately, permissions are not as clean a flow as the Jira Object Model is, but I’ll do my best to guide you through it.  

For the most part, I’ll be talking about Jira Server and Data Center today – as Cloud access and permissions is a different beast that deserves its own post. So, let’s dig into this!

Applications -> Jira Application Access

Jira needs to determine the first thing: “Is this person even supposed to be on this App?” To do this, it looks to its Application Access list. This is a list of groups – per Application – that can use that Application’s features. These are also what Jira uses to determine your license count.

The trick here is that Jira can use any group it’s aware of for this access, including groups from a remote directory. This means you can somewhat automatically handle Access permission by including a Remote Group that includes everyone in your Org. However, a word of caution. Depending on how your users are provisioned, you can easily add more people into your system than your license allows – which will disable Jira entirely. So, where possible, use a “Just-in-time” provisioning that creates users in your Jira instance as they log in for the first time, rather than the AD sync that immediately creates everyone in your Active Directory.  

System -> Global Permissions

The next set of permissions I want to discuss are global permissions. These permissions don’t apply to any particular Jira project – but Jira as a whole. As with the Application Access, you must assign a list of groups per Permission node. Let’s look at each permission individually.

Jira System Administrators

This permission node allows you to do anything within the Jira Administration panel. Once upon a time, this was combined with the “Jira Administrators” role, but it was split off so you can have multiple levels of Administration – and save the risky configurations for those you trust.  

Jira Administrators

This, like the Jira System Administrators permission node, allows you access to the Jira administration panel. However, there are several features that a Jira Administrator will not be able to do – like adjusting the server’s SMTP settings, configuring listeners & services, and running the integrity checker, among others. You can check out the complete list of what a Jira Administrator cannot configure here. 

Browse Users

In Atlassian’s words, this permission node allows you to “View a list of all Jira user names and group names.” However, this is an essential permission if you wish to @mention someone, use a user picker or group picker field anywhere in Jira.

Generally, I don’t mind having almost everyone in this permission node – as a user needs to be logged in anyways for this permission node to work.    

Also, as Atlassian Notes in their documentation:

“Note that the Assign User permissions also allows a limited version of this on a per-project basis.”

Created Shared Objects

This is the permission you need to share your Dashboard or Filter with other users. This is also a permission node that I also like to have as many people as possible. After all, not being able to share the dashboard you made to manage data in Jira defeats the whole point of Jira. 

Manage Group Filter Subscription

Did you know that in Jira, you can schedule a report to go out regularly with the results of a filter? You can, but you need this permission node to do so.  

However, this is a permission I’m not particularly eager to share out. One of Jira Server/DC’s Achilles heels is that of outgoing mail. It’s not hard to overload that mail processor. Making a dedicated postfix mail relay can help, but it’s not impossible to create a problem even then. 

And now imagine some well-intentioned user adding a subscription for the “Everyone in the Org” Group that goes out daily. Depending on the size of your organization, that could be thousands of emails generated within a few seconds. But I wouldn’t nor shouldn’t expect a general user to worry about that – It’s my job to worry about Jira’s capabilities, not theirs.  

So when presented with something like this, I prefer to keep this permission with the Jira Admins. I’m happy to work with a manager who wants to set up a Subscription for their group, but that puts me – as the Jira Admin – in the conversation so I can let the Manager know some of the risks. And if the ask is too extreme, like my “Everyone in the Org” example, I am in a place where I can deny it. 

Now a nuance I do want to say is that there is no permission node for disabling users from creating personal subscriptions – you are free as a user to create as many as you want to go to yourself. This permission node only affects whether you can send it to a group or not. 

Bulk Change

This permission allows you to run a bulk change off a filter or search result. The operations included in a bulk change are:

• Bulk Edit
• Bulk Move
• Bulk Transition
• Bulk Delete 

You still need the relevant Project-level permissions for each issue in your search to do any of these activities. All this permission does is if you are allowed to perform an activity on an individual issue in a project, allow the same in a bulk factor. 

And I should note that Bulk changes are limited to 1000 issues at a time to prevent you from overloading Jira with changes. Given that limit, I don’t mind more people having this permission. It simplifies people’s work within Jira and poses a low risk to the system. Win-win!

Browse Archive

This permission node is an oddity – as it appears in my Jira instance but not in the official documentation. However, from what I can understand, this is the node to allow you to see archived issues – either individually or as part of an Archived project. 

Given that understanding (which is an undocumented feature, so I could be wrong), I’d be hesitant to share this permission widely. Instead, I’d rather keep this with either the Jira Admins or Sysadmins. The whole point of archiving issues is to clean up clutter for everyday Jira Users. Granting them access to then see it seems counter-productive. 

System -> Project Roles

The next place I want to visit is the Project Roles configuration page. This page allows you to define the Project roles you have system-wide and is one of those settings that will impact every project in your instance. So be sure of what you wish to do before acting.  

However, all this does is create different buckets for Project Admins (or yourself) to place users and groups into on Jira projects.

If you click the “Manage Default Members” option, you can specify groups that will be automatically added to the roles when you create a new project. As a best practice, I try to include both the groups for Jira System Administrators and Jira Administrators in the Administrator role, so that as you create new projects, you should automatically have Admin permissions on them. 

Issues -> Permission Schemes

So, we’ve covered all the global permissions – let’s talk about Projects. Permission schemes are used to manage project permissions. I’ve already talked about Permission Schemes and the various permission nodes they contain at length, so I’ll avoid rehashing it here. 

However, having too many permission schemes can be a significant source of performance problems in Jira. So as a best practice, I like to reuse Permission schemes as much as possible. We can do this by assigning permission nodes to Project Roles, which can then act like a per-project mapping to users and groups for that project.  

Project -> Project Admin -> User and Roles

So, this is the final step for Project permissions. Here is where a project Admin can add users to their project roles, which then maps them to the permission nodes for that project. Typically, you will need a full Jira Admin to modify permission schemes. But, as Project Admin, you can modify users and roles as much as you need. This fact is yet another reason I prefer to use Project Roles for permissions – it allows Project Admins to self-service their projects without me being a bottleneck. 

So what do you think?

I love hearing your thoughts, tips, and best practices in the comments! Please let me know what you think or if you wish me to expand on something!

You can also find my social media link on Linktree! Interacting with you and seeing how much benefit you get from the blog is what drives me to keep doing these posts. So be sure to drop a like and comment on social media – it does help the blog!

You can also subscribe below to get new posts via email. It’s the fastest way to be notified about new content.  

But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

---