How to Control Access to a Jira Project | Atlassian Jira

What is the point of creating roles if I can create groups, assign people to those groups and then in permission scheme grant permissions to certain activities e.g., Manage Sprints Grant to GroupA.

Your proposal justt makes the whole process complicated. You suggest: creating groups-> assigning users to groups-> assigning roles to groups-> granting permissions to roles, while skipping 'assinging roles to groups' step makes it easier: create groups->assign users to groups->grant permissions to groups

I literally just want to add my external team to see only one board in our company and it’s so complicated 😢 why jira whyyyyy

Hi. I really appreciate your videos. I think you are a very good teacher. I do have a problem. When I copy the Default Software scheme, and then remove "all logged in user" on browse projects, and then add administrator, I stop seeing the project. I don't know why that is. Can you please help?

Hi there! Thanks for the series. I got an overview.
But has the UI got changed recently? Because I can't find 'Permissions' tab in the 'Project Settings' section.

Do you have any videos on how to lock down Jira so that external customers can only see their one project that they are assigned to as opposed to seeing every project when they browse for a project?

Thank you so much for your explicit content. Please guide me on how to perform these actions on Free software as "Add People" is not visible and I am getting this notification:
"On a free plan, you can only add people using your site's administration settings. Upgrade your plan to better control who can access this project."

Thank you for sharing this, Alex. This is really helpful. After following your tutorials I did manage to assign the permissions and create the roles which I need. However, would it be possible to add a group of admins who have access to system admin for their own projects only? That's to say I am wondering if I can have project admins who can edit the screens, custom fields and etc for their project only?

I find it VERY interesting that you recommend groups for managing project roles. It seems to me to go completely against what project roles are actually designed to do. For one thing, project roles can be are controlled by the project admin. Therefore, you give the project admin some power, so to speak, to control access to their project. At the same time you save administrative effort, because you can delegate the exact management of project permissions to the project admin.
However, group membership can only be controlled by the org/site admin.

On the other hand you can use ONE permission scheme to control project permissions for many projects via project roles.

I.e. in the specific case you describe, you would ruin the advantages of managing project permissions that the project admin controls via project roles. Because now the project admin would have to contact the org/site admin every time someone leaves the project, for example. The org/site admin would then have to remove that person from the group. So it would be MORE administrative effort in total (2 people involved). Actually, in this case you would not need project roles at all, because you could enter the groups directly in the permission scheme.

As I said, I find your approach interesting and would like to discuss it. No offense and thanks for the contribution :)