Project Permission

[Darren Martz]

It seems the default permissions in Jira is if you have access, you see everything. If you want to create private projects and grant to all users on demand, it seems to require planning. Did I understand that correctly?

Adding a contractor to a single project, it looks like I need to go and fix all our other projects permissions to make that work. Then somehow fix projects other employees may create so the contractors do not see them.

Is there an easier way to default to private across the board, including newly created projects, but then optionally share with a larger audience per project?

[Update]

Wow, it has been a very long time since I jumped into the community and it looks very healthy with quality responses. I'm impressed!

[Mikael Sandberg · Accepted solution]

Yes, you are correct, the default permission scheme basically allows anyone with access to your instance to do almost everything.

And changing it to limit what can be done does require planning. To make it easier I would start by limiting who can create new projects, and for existing projects either change the default permission scheme to be more strict or create a new one that fits the way you want most of your projects to work. I would avoid using groups, instead use project roles, that way the Project admin can decide who gets access rather than having an Jira admin add/remove users from groups.

[Jack Brickey]

Generally speaking folks have it so new users go into a default role and that role is the default for the default permission schemes. So, assuming you have a contractor come on board and you wish to restrict to a single project you can remove them from the default role and they will disappear from all projects from a permission perspective. Now add the appropriate permissions for this one individual in the one project.

[Darren Martz]

Okay, so no way to force "private" next generation projects then?

Mikael, I prefer the roles as well and use the next generation "Access" screen. It puts the power with the owner of the project then and less central command for needless things.

Jack, I do have default permissions to no access to any products.

It looks like what I was hoping for in the next generation was administrative control to force new projects to be private. If they want public, then come to the administrators for assistance. Unfortunate.

[John Funk]

Hi Darren - I would setup a base project the way you want it and then create all new projects based on that base project. Then you can deviate from there.

[Darren Martz]

Not sure what you mean John. Is there a way to create my own project templates for employees to use that I missed?

[John Funk]

You create a project and set it up with all of the schemes you need. Then when you create a new project, use that project as the one you base the new project on. It will not copy all of the People information over, but it should be bare bones and not have all of the normal default ones. 

[Trudy Claspill]

Hello @Darren Martz 

Are you working with Classic software projects, or Next Gen software projects, or both, or other types of projects?

Who is making the projects? Are Classic projects made using the same configuration that is used in existing project or does each project get a unique configuration?

Besides the permission to see the data (i.e. Browse Projects), do the projects have other custom permission settings?

When the private project should be shared with a "larger audience", is that larger audience going to be the same group (i.e. all authorized JIRA users) every time, or is each project going to need a custom "larger audience"?

[Darren Martz]

All but 1 project is next gen and there may be a need for another depending on the project requirements. 

Employees are open to create projects on demand which is ideal to remove friction, but it seems we could use administrative restrictions to force all projects to be private. Its looking like that does not exist and is not achievable.

Sharing a project with a larger audience would be with a selected group, not absolutely everyone (ex: contractors). How would that work then on roles?

[Trudy Claspill]

My expertise lies with the Classic projects rather than the Next Gen projects, so I'll have to defer to others to provide suggestions.