Best Practices: Restricting Projects in Jira

[#1]

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!

[Coiram]

Do not  make this sound like users can modify "Users & Groups" in a Project. Because normal users by reading this article believe that they can administer users & groups by themselves . Yep I have been referenced to this article by an user and she followed the instructions saying "it is written there, it has to work".

Make sure to underline respective Administration and Project Owner Rights aka:

• Groups are created by system admin
• Users are created by System admins
• Users are inserted into groups by system admins

• Project owner can add/remove users

[Gonchik Tsymzhitov]

Thank you that article which helps to me write document for our company :)

[tamdvms]

good document

[Robert Horan]

I hope its ok - I added a tag named 'best-practices' - I feel that this tag could be really beneficial to others.  Definitely for me :)

[Terry Medearis]

This was extremely helpful.  Thank you

[Sam Ayres]

Very helpful! Thanks for taking the time to write this.

[PJ Singh]

This is extremely helpful indeed! The chart helps clarifies the concept even more. Thank you so very much!

[James Childs]

Great article, thank you!  Is it considered best practice to create a group for each project?  So, Project A might have a few groups, Project B the same and so on?  If I have understood the article correctly then we would be creating multiple user groups over time.

[Frode Nilsen]

Isn't it a good practice to lock down the default scheme so no one creates a new project with public access?