Project permissions

[Thomas Capacci]

Hi,

I want to create independent projects for different teams, so members of Software1's team cannot see project issues in Software2 team's project.

What is the best way to do so?

I have created my first test project but when I want to add people, I only have the option to grant them the administrator role.

[Joe Pitt · Accepted solution]

First, by default JIRA has a horrible permission scheme that violates security best practices by allowing everyone that can logon to do just about everything.

JIRA works by GRANTING access. You can't restrict access. By default, it grants access to the group used to logon (see Global permissions to see the "can use" groups and admin groups). This is where users are getting their access.

1. The FIRST thing you need to do to get control is to remove any groups with logon privileges from the permission scheme unless you absolutely want everyone to have that permission.
2. Then I suggest you setup Project Roles for the various functions like, tester, QA, Browse Only, etc.
3. By using project roles, one permission scheme will cover all projects. The project admin controls project role membership
4. If the project leads want everyone that can logon access to the project they can add the logon group to a project role with the desired permissions.

This may be a big effort, but it will pay off down the road by making it easy to control access.

Most of the 'old timers' use project roles. It meets the best practice for security and gives complete control to the project lead for access to their project. JIRA comes with many project roles, but you can add more if you have a special need.

[Thomas Capacci]

Thanks Joseph, 

Sounds tedious at first but as you said in the long run I guess I'll be glad to do it.

When I look at the scheme, there is the Default Permission Scheme and the Default software scheme.

I created to scrum projects and they all inherited the Default software scheme.

So would you advise to change both default software scheme to remove all the default permissions assigned to "Any logged in user", then use Project Roles to grant access in Projects permissions

OR

Create a new scheme for my projects?

[Joe Pitt]

Get rid of the any logged in user from all permissions schemes. The is the 'root of all evil' when it comes to controlling who can see what. As I said once you start using project roles the project admin can control who can do what in their project. The added benefit is you only need one permission scheme. If you want to 'archive' a project simply remove everyone from all roles. 

I'm not familiar with software schemes. That may be a cloud setting. I've always used the server version

[Thomas Capacci]

so this what I did for a test Project:

- created the project "IT Support"and set myself as project lead

- created a new permission scheme

- create a project role called IT Support Members

- Added the Project Role in my new permission scheme the permissions I want every member of the group to have

- Applied the permission scheme to my project

The thing in our case is that we will need to create a new permission scheme per project, as each project will generally be assigned to different teams (teams spread across different companies) so we really want access isolation between projects

[Joe Pitt]

That is the beauty of project roles. The roles are universal, but not the membership. Unless you add default users to the project roles every project begins with a blank slate. The project admin adds the users they want to have the permissions. They can also add groups if that is how you want to group users. Project roles should be functionally generic. For instance I use Team Member as a project roles and in the permission scheme that role has browse, create, edit, add attachment, etc. needed to work in the project. Only users needing to work in the project are assigned the Team Member role. I have a role Management they they are only assigned the Browse permission. That would be for anyone needing to browse, but not perform any real work in the project. Depending on the size of your company the personal assistants of managers may be assigned that rolse so they can run reports.  If you need multiple permission schemes you aren't using project roles correctly. 

[Thomas Capacci]

 >If you need multiple permission schemes you aren't using project roles correctly. 

Sorry I am missing something...please be patient with me :)

how can I use the same permission scheme while I make sure that members of "Project role1" can edit "Project1" -only-  while members of "Project role2" can edit Project2 only

If I give the "Project role 1 and 2" edit rights (in the permission scheme), this permission scheme will be applied to both projects, so all members whether they are members of 1 or 2 will be able to edit.

[Thomas Capacci]

@Joe Pitt 

I think I finally understood what you told me.

Project roles begin with a blank state, now I get it

Then inside my projects I can choose who's member of the group on the project level, now it makes sense and thats indeed pretty cool

[Ollie Guan]

Hi @Thomas Capacci ,

System administrators need to maintain project role first.

https://confluence.atlassian.com/adminjiracloud/managing-project-roles-776636382.html

[Thomas Capacci]

Once the project role is defined, what should I do?

By default all Jira users have access to all projects, how can I force only Project role group members to access defined projects?