When thinking about Jira administration, or really administration of any software, project, or endeavor, the old idiom “too many cooks in the kitchen” often comes to mind. There’s a fine line between empowering your user base and setting the stage for mass hysteria and confusion within your instance. Fortunately Jira offers some out-of-the-box options to help with setting up boundaries for those users who need more control over the instance but keep them from wreaking too much havoc.
We’ll start with the bottom, Project Admins. There was a time in ancient Atlasssian historical records when those who were managing projects almost had to be System Admins as well. This was because the permissions needed to make necessary regular changes to the projects these individuals were maintaining required as such. Atlasssian has been improving upon this incrementally as of Jira 7. Since that update it is possible for Project Admins to add Components and Versions to their projects and even as of 7.3, expanded with 7.4, make adjustments to the workflow among other things. So if you’re evaluating your System Admin group and discover that many of the individuals are really only responsible for maintaining specific projects it would behoove you to re-assign those you can to the Project Admin role within the projects they are responsible and get them out of your kitchen.
The next level of administration is the Jira Administrator. Now this is where things can maybe become a bit confusing because the powers granted to that of the Jira Administrator are very similar to that of the System Administrator, but there is a very key distinction which we’ll explore. Those within the Jira Administrators group are not able to make changes related to the server environment or network. This would prevent them from making changes to things such as configuring mail server settings, export/import data to and from XML, configure user directories, as well as many more functions related to the system as a whole. Where this could be useful is delegating out some of the more regular tasks such as creating new projects, creating users, etc. This gives larger organizations a way to separate out the tasks without increasing the risk of potential hazardous changes to the application.
After having covered the last two, the final role should be somewhat obvious. The System Administrator permission is for the Grand Poobah of the Royal Order of Buffalos. This role allows unlimited access to all aspects of the Jira instance. It is recommended that only 1 - 3 people maintain this permission as needed. Again, the idea is to ensure that there is concise and regulated changes being made to the instance as well as accountability. With great power comes great responsibility. When in doubt, opt for the lesser of two evils when granting administrative permissions. You can always bump them up If it’s not serving your needs. Again, the goal is to empower your user base, not have them overpower you.
For question on admins, or anything else Jira, contact us, and one of our Jira experts will get in touch.