Best Practices: Restricting Projects in Jira

As your Jira Software instance grows, restricting project access becomes an increasingly pressing need. Whether you're working with clients or just trying to control project visibility, strategic restrictions are vital.

There are numerous ways you can restrict access in Jira Software, but not all methods are created equal. The process covered below is the most scalable way to approach locking down your work.

3 Fundamental Concepts

There are three important Jira administration concepts to understand before we dive in.

  1. Users/Groups - Users in Jira can be organized into groups, i.e. Client X, iOS developers, et al., which allows for a more convenient treatment of a collection of like users.
  2. Permission schemes - Every project has an associated permission scheme, which is a list of potential actions one can take in any given project. A single permission scheme can be applied to any number of projects.
  3. Project Roles - Project roles are a flexible way to associate users/groups with a Jira permission scheme. Project roles are somewhat similar to groups, in that they are groupings of like users. The main difference being that group membership is global whereas project role membership is project-specific.

Below, you'll find a handy chart on how all these concepts relate together. Don't worry if this strikes you as complicated right now; it'll make more sense in context.



Steps to Locking Down Projects

Say that you have two development projects, Project A and Project B. These projects should only be visible to their respective teams. Below, we'll cover how you can restrict said projects in a scalable fashion. We'll start with Project A. [Note: We'll assume that you will stick to out-of-box project roles (administrators, developers).]

User Management

  1. In your site administration, group your existing user base. For developers in Project A, create a "Developers-A" group, for administrators, "Administrators-A," and so on.
  2. Again in site administration, add your users to their determined group.
  3. Now, go to your project settings for Project A. In the "People" section, assign your user groups to their respective project roles, i.e. Developers-A to the developers role.

At this point, you've mapped out your users to project roles.

Permission Scheme Management

You'll now need to create a new permission scheme. Assuming you're starting from scratch, all of your projects map to a default permission scheme (i.e. default software scheme), which permits access to all Jira users.

  1. Toggle to the "Permission Schemes" section of your Jira administration. (A handy shortcut is to hit '.'  and type in "Permission Schemes.")
  2. Rather than build a permission scheme from scratch, clone the existing default permission scheme.
  3. Once you have created the cloned scheme, click "Edit."
  4. Of the many possible permissions, the one you'll want to really focus on is the "Browse Project" permission.
    1. To this permission, add the project roles of administrator and developer
    2. Remove the "any logged in user" access right.
  5. Save this permission scheme with a unique, descriptive name.

Project Settings Management

Now that you've mapped your user groups to project roles and created a new permission scheme, your final step is to simply apply your new permission scheme to your project.

  1. Go to Project A and in the lefthand toolbar toggle to "Settings" > "Permissions."
  2. At the top right, select "Use a Different Scheme."
  3. Choose the newly created permission scheme and you should be all set!

Project A should now be hidden from all users not in the user groups Developers-A and Administrators-A. To lock down Project B, you'll just repeat the steps above except you can skip creating a new permission scheme.

Final Considerations

As a whole, when you consider restricting projects, you'll want to keep 3 things in mind.

  1. How you group your users together.
  2. How user groups apply to project roles for a given project.
  3. What permissions you grant those project roles according to the project's permission scheme.

As you get more comfortable with this process, you can probably start thinking of ways you can introduce additional project roles (client groups, executives, etc.) and what permissions you'd like to grant them through your permission schemes.

Hopefully, this helps clarify an admittedly complex process in Jira and gives you the groundwork to move forward and experiment further with locking down work.

If you're an experience Jira user, how have you used permission schemes in the past? Comment below!




Log in or Sign up to comment
Community showcase
Published Aug 21, 2018 in Agile

What's new this quarter in Confluence Server - August 2018

Hello Atlassian Community! My name is Ada , and I'm the Product Marketing Manager for Confluence Server at Atlassian. If you missed   our last post, we're transitioning to quarterly updates&nb...

161 views 0 1
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you