Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
Level
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How do you prevent people accessing specific projects? Edited

Hi, 

Previously all users in our Jira software were working on the same project. Now I am about to set up a second project within the Jira software with a different group of people working on it to the first project. I have been asked to set up the permission settings so that only people working on each project can access the board for their project but I struggling to work out which type of permission settings can do this. Is it Groups, User roles or Permission Schemes? Can any provide guidance to setting up the restricted access? 

Thanks.

1 answer

1 accepted

2 votes
Answer accepted

It's all of those things, potentially.

You can't restrict people in Jira, the permissions are totally permissive.  To hide a project from someone, you have to remove their access to it.

Start with the permission scheme for the project and look at the "browse" permissions - those define who can see a project,  You may find lines in there saying "group = X", "role = Y" or even "any logged in user" - kill off the rule that is letting your users in (obviously, making sure the project users are still included)

Hi Nic,

Thanks for your quick reply. I've found that both projects are using 'Default software scheme'. Does that mean that they need to have different schemes first before I can make their permissions different?

 

Screenshot 2021-03-30 165611.png

Yes, you're absolutely right.  If you want different permissions for different projects, you'll need a new scheme to associate with the protected project(s)

You can do them from scratch, but I prefer copying an existing one and then tweaking it.  

Like Matt Fazakerley likes this

Great, I've now copied the scheme and allocated the new scheme to my project. 

In the Browse Projects section, does the 'Application Access -Any logged in user' part make the Project role section useless in this case? Or are the both needed?

Screenshot 2021-03-30 170806.png

My thought is to remove the 'Any logged in user' part and create a Group with the people in that will need access? Is that the best way?

Again, spot on, almost. 

If you'd said "remove 'any logged in user' and let the desired users in some other way", it would be 100%. 

The "almost" is not because "add a group" is wrong, it's absolutely correct, but there is another option you might consider.

I default to using project roles instead of groups.  With a group, your administrators (either application or your directory admins) have to add and remove people from the groups.  If you use project roles, there's a bit more power than groups because you can get the project administrators to maintain the users - they can edit the users (and groups) in the various roles in the project.  You can also reuse the scheme for other projects that want to use different people.

Imagine you've got three sets of people, A, B and C, and several projects that they might be using.

If you do "Browse = group" in a permission scheme, then for each set of projects, you're going to need a different scheme, such that "Browse = group A", "Browse.= group B" and "Browse = group C", and on top of that, your system admins are going to have to maintain the groups.

If however, you have one scheme with "Browse = role: developer", then you can use the same one for all the projects, and your project admins can put groups A, B and C into the role for themselves, and/or name individuals.

Roles might well not be the right model for you, groups might be fine, but I wanted to show you that you have a bit more flexibility!

Thanks Nic for the detailed explanation, this really useful to know.

I think this is my final question now and then I'm sorted. Do the Roles spread across the projects or by creating 'user' does it create multiple roles with the same name, one for each individual project?  E.g. If I set 'Browse = role: user' in the permissions scheme that is used for Project A, B and C, can Group A get added to the role: user for Project A separately to the user role in Projects B and C, or is it the case that if I add Group A to the user role, then they would have access to all three projects?

Project roles exist universally across every project, but then contain only project-local users and groups

If you created a role of "Penguin wranglers" then you would see it in all your projects, but you could set up the projects like:

  • Project ABC - Penguin wranglers: Alice, Bob, Chuck and group zookeepers
  • Project DEF - Penguin wranglers: none
  • Project GHI - Penguin wranglers: Bob and the group zookeepers

All the project memberships are independent, belonging to each individual project.

Like Matt Fazakerley likes this

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Confluence

⚡️NEW Group for Confluence Cloud Admins

Calling all Confluence Cloud Admins!  We created a new Community Group to support your unique needs as Confluence admins. This is a group where you can ask questions, access resou...

93 views 2 8
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you