Permissions

[Joe St_ Louis]

First off, I'm extremely new to Jira, so please be kind.  The permissions seem a little convoluted coming from other ecosystems so bare with me and my foolish questions. :D  Our goals are as follows:

• I'd like to setup a couple of PMO people with full permissions to all projects and to create and delete new ones by default.
• I'd like Project Managers who only have access to manage projects that they're assigned to by the PMO people.
• I'd like Normal Team members who can work on the projects they're assigned to by the PMOs or the PMs.
• I'd like Guest users to be able to view projects they're assigned to by the PMO's and the PMs.

What is the best way to accomplish this?

[Robert DaSilva · Accepted solution]

Hey @Joe St_ Louis , welcome to the community!

Jira permissions can get a bit confusing, let me try and break this down. The short answer to your question, however, is this should be possible without too much heartache.

---

Firstly, I want to make sure I explain the different types of Jira projects. Fundamentally, you can have either "Company Managed" or "Team Managed". Generally, best practice is to go with Company Managed as this allows the administrators to impose standardized processes among teams. Team Managed projects are nice as they let individual teams configure them to their hearts content, but this can become a bit messy if you need to move data around at any time in the future.

Jira permissions operate on a few different levels. At the top level, you have Product Administrator permissions or privileges. This level gives users, among other things, the ability to create "Company Managed" projects.

The next level down would be Project Permissions, where you can control specifics about individual (or many) Jira Projects.

Finally, below that is Issue specific permissions, where certain issues can be restricted.

---

For your use case, it sounds like you'll need your PMO folks to be considered "Jira Administrators" if you want them creating projects on the fly. This is not something I would normally recommend, as it's really easy to have the overall configuration of the instance spiral out of control pretty quickly. I would recommend keeping the number of Jira Administrators on a short list, and try and enforce limited changes to avoid a huge number of configuration items.

Once you have your projects set up, we'll want to configure a Permission Scheme for the project. Permission schemes can be applied to one or more Company Managed projects, to ensure they all share similar permission structures. You can assign individual people permissions inside the scheme, but I would recommend creating something called a "Project Role", and assigning that specific permissions instead.

---

So, what would that look like.

You'll want the following Project Roles:

• Project Manager
• Team Member

Well, the ability to even see if a project exists is controlled by the "Browse Project" permission. You'll likely want _everyone_ to have this permission, so they can see work items in Jira.

You can then assign the "Project Manager" project role to the "Administer Project" permission, so they can manage the Jira projects themselves.

There are a variety of permissions you'll want to give the "Team Member" project role, but most importantly would be "Edit Issue" and others in this range.

Once you have the permission scheme set up, you can assign it as the default, or ensure it's assigned to new projects.

Finally, within each project, you'll want to invite the users and grant them the specific Project Roles assigned to their specific duties.

---

I would recommend giving a read through the existing Project Permission Schemes, and doing some review of what the individual permission accomplish.

You can also look through some of the documentation Atlassian has, which is pretty good:

• https://support.atlassian.com/jira-cloud-administration/docs/manage-project-permissions/
• https://support.atlassian.com/jira-cloud-administration/docs/permissions-for-company-managed-projects/

Phew, that was a lot. Hopefully that helps you! Happy to discuss further if you need more assistance.

[Joe St_ Louis]

Is there a preferred or best practice then for the PMO people in this case?  I'm an IT admin, and while I want to properly manage permissions, I don't want to create or micromanage projects beyond that.

[Joe St_ Louis]

Would adding the PMO people to the projects-admins group be adequate?

[Robert DaSilva]

@Joe St_ Louis There is nothing inherently wrong with giving your PMO team Jira Administrator privileges, this is what would be required to get them access to create new projects.

I would encourage you to ask them to be cautious with adding new configurations beyond Projects. This would include Custom Fields, Workflows, Statuses, etc. The best practice in this area is to re-use existing configuration items unless there is a compelling reason to create new configuration items.

The groups you're seeing within the Admin Hub are more targeted around the organizational tasks. To grant the PMO team Jira Product Administration privileges, you'll want to ensure they are added to the jira-product-administrator-<site-name> group.

You can also grant Product Administration features on individual users by visiting their profile from the Admin Hub > Directory, and granting the Product Administrator role.

[Robert DaSilva]

@Joe St_ Louis Regarding that project admins group, before I can say definitively if that would grant jira administration privileges, you'll want to check the group configuration. 

When viewing the group, at the bottom should be a list of product roles granted to members. As long as it says "Product Admin" in the dropdown, you should be golden.

Otherwise, you'll want to give PMO users who need Jira Administrative functions access to a group that _does_ grant the Product admin role.

[Joe St_ Louis]

@Robert DaSilva Would you also want to create a role specifically for guests for projects as well?

[Robert DaSilva]

@Joe St_ Louis That would depend on how you expect guests to interact with projects.

The default recommendation for Jira is that any user who is able to log into the tool should be able to see any project that exists. That would mean granting the "Browse Projects" permission on every project to the "Logged In User" ... group/entity.

If instead you want to restrict the visibility of projects, then yes, adding a Guest product role would allow you to only have specific people invited to the project be able to see the project at all.

Restrictions like this only really make sense or are recommended for security sensitive projects, like HR or Legal projects. Otherwise, it makes it more challenging to have your separate teams track work together.

What's nice is you can prevent "guests" or "any logged in user" from making changes to projects by leaving that role or entity off the various permissions in the Permission Scheme. This would allow anyone to "See" things, but not "Change" things. The only exception I would make is the permission to Link Issues, as this allows teams to link dependancies between projects, if they exist.

[Joe St_ Louis]

@Robert DaSilva We're a consulting firm and the idea is we want to be able to share client specific projects with them.  Kind of like a view only user.

[Robert DaSilva]

@Joe St_ Louis In that case, yes. I would recommend adding two additional Project Roles. One for your internal teams, say "Internal <Consulting Company Name Here>", and then a second that is extremely explicit as being "External Guest". 

Then, you'd add specific individuals to specific projects with that Guest role, and whatever permissions you want them to have. Browse Projects would be the minimum, and you can expand from there.

I would strongly encourage you to test this configuration on a sandbox instance without client data to ensure you've got the configuration correct before opening the instance up to external parties.

I feel obligated to also mention that, as far as I recall, all of these external users are going to be counted towards your license count, so you may want to consider other options for displaying data to other parties if cost is a major concern. Being a consulting firm, I suspect you can bill the client for this cost though, so it might not be a huge concern.

With external parties being part of projects, using Company managed projects makes a LOT more sense. I would also strongly encourage the use of only one permission scheme that you have tested, to avoid the chance for data leaks.

If you want even more data security, you can also impose "Issue Security Schemes" to lock down specific issues even more, but that's getting really advanced, and I'm not certain is required.

[Mathew Lederman]

@Joe St_ Louis happy to answer your questions, but I do want to clarify one piece about permissions that confuses a lot of people. Atlassian has product-level permissions (Jira permissions, Confluence permissions, etc), project-level permissions (administer project, browse (read-only), edit, delete, create, etc.) and project-level roles (administrator, user, developer, etc.)

Product permissions are found at admin.atlassian.com

Project permissions are found in each Jira project > Project Settings > Permissions

Project roles are found in each Jira project > Project Settings > Roles

You can create new roles within the Jira administration section, but that's too deep in the weeds for now.

My best suggestion: Pick a project. Look at the Permissions. You'll see which permission gives what functionality and what roles are tied to that permission. Then look at the roles. From here you can assign users to Roles, and those Roles inherit the Permissions.

• Your PMO with full permissions to all projects and to create/delete should probably have the product permission of Jira Admin. By default, you can add users to the jira-admin in the group org admin portal (admin.atlassian.com) and which will give them this permission.
• Your Project Managers, should probably have the project Administrator role. This is found within in project. By default the project Administrator role has permissions to administer the project. But you'll want to confirm that within the Project Settings > Permissions unless you're using a new default instance.
• For the next two, it sounds like you'll want to change the default permissions which allow any logged in user to browse, create, transition, assign, assignable user, etc. You can change this globally if everybody is using a shared permission scheme, or within each project
  • Normal Team Members can be to a role like Users, if the Users role has the appropriate permissions such as assignable user, transition issues, etc.
  • For Guests, you may need to create a new role called 'Read Only' and in permissions, give this role the Browse permission. Then only users added to each projects' Read Only role will be able to view those tickets.

[Mikael Sandberg]

Hi @Joe St_ Louis,

Welcome to Atlassian Community!

In order for your PMOs to be able to create a delete company-managed projects you have to make them Jira admins. If you are only using team-managed projects you can set the global permission that allows you to create tmps to the PMO group.

And for the other users, it all depends on what type of project you are using. In company-managed projects your PMOs can assign the project lead and then the project lead can add/remove users based on roles. You would also need a new permission scheme since the default one gives everyone access to projects.

If you are using team-managed projects you can set the access to private and then it is up to the project admin whou get access to the project. Check out this KB for more information.