can i limit visibility of jira projects to certain groups ?

Adrien Bret January 14, 2015

Hi 

I have 3 projects on JIRA. I want some of the users being able to see only some of the projects. I'm pretty new to JIRA and i can't find a way to do that. Is that possible ?

regards,

Adrien

3 answers

1 accepted

2 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 14, 2015

First, look at the permission scheme for the project.  The line that says "Browse project" gives you a rule for allowing people to see the project.

That rule is likely to be something like "everyone in the role of users"

So the second step is to change who matches the rue.  For the example I've just given, you go into the project roles and remove all the users and groups who should not see the project.

It's likely that the group "JIRA users" is in that role by default - you'll need to remove that, and then add back in any users or groups who should see the project.

This is rather a poor default from Atlassian I'm afraid - they default JIRA users into every project and it's a bit of a pain when you start wanting to do hidden projects.  My standard recommendation is to bin the jira-user group - never use it in permissions or roles, it should only be used to say "can log in".

SIZWE_MKHIZE March 26, 2016

Good evening.

Greetings from South Africa. Thank you indeed. I think Atlassian will need to work on this because I have been looking for  way to do this for much of the day. Im a PM in a small team that is working with fairly large organisations. And I want our projects to be managed effectively using Jira. But I also want the client team to see the project and what is happening on it. that means I need to create rights for them on certain projects but not on the the other projects which we will be working with other organisations or projects which are purely internal.

 

This means that for each new project I would have to fiddle with permissions each time to prevent them from seeing other projects as soon as I create them as users on the system. Its not the most effective way of doing things. The product should cater for an easier way to do this.

 

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 26, 2016

I think there are two things here.

  1.  JIRA actually has a moderately simple permission setup.  There's nothing for Atlassian "to work on" because they've already set up a simple and intuitive way to do it - it really does boil down to "if you want to let someone to do X, then give them the permission to do X".  There is a lot of complexity in what X might be, and who you might grant it to, but that's the cost of the massive flexibility that you get from it.
  2. The defaults are poor for anyone who wants to hide stuff

    To fix both of them, have a read of the original answer.  It covers it all.
Damien Hughes September 25, 2017

Hi @A can you please guide me through this solution for the new Jira.

thanks

Damien

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 26, 2017

The access model has not changed since Jira 3.6, although some of the default groups did change with Jira 7.0.

The principle is:

  • Grant people the ability to log in
  • Grant people the ability to use the projects they need
  • For "limited" users, do NOT grant them the ability to use the projects they should not be using

The problem is usually with the default settings.  Atlassian use the concept of a "group of users that can log in and use an application", which is a nice simple approach which itself has no problems.  They then go on to adding that group in the role of "user" in every project by default.  Which means "can use application" becomes "can log in and see everything"

So, you need to unpick that. 

  • Go to "manage applications" and check what the login group is
  • Look at all active permission schemes and check how they allow "browse" access to projects, ensuring they say something simple like "Role: user"
  • Go through all your projects and remove the "can use application" group from the role of user (and others if the permission scheme says so).  Replace it with the groups and users who should have access to the project.
  • Go to Admin -> Roles and change the default role memberships to be empty for users, developers and so-on.  This prevents new projects accidentally granting access to limited users
Tech ProjectMgr January 29, 2018

Any chance you can translate this for the new UI? I'm not finding "manage applications" to follow what you are describing. What you are describing is for JIRA Cloud? We got caught in the middle of their transition from old to new and the Administration UI only displays the new UI, which is not as intuitive as the old UI.

0 votes
Collin Ng March 5, 2018

Hi, is there an update on how to do this today? I don't see the "browse issue" permission now, would I be able to do the same with "browse project"? How do you guys test it btw?

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 5, 2018

It's the same, but there's a typo in my answer - I said "issue" instead of "project".  It's always been "browse project"

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 5, 2018

Oh, and also, they don't use jira-users by default any more, there's the jira-application-user groups instead.  Same principle though.

Collin Ng March 6, 2018

Got it, thanks!

0 votes
Adrien Bret January 15, 2015

thank you Nic !

Suggest an answer

Log in or Sign up to answer