How do I configure users so they can only see 1 project?

I want to allow users to login to JIRA OnDemand (Atlassian JIRA v6.1-OD-03) but only be able to see JIRA issues and Confluence space for a single project. By default, excluding them from JIRA access lets them see but not edit other projects. I want client users to only see their own stuff, not the stuff of other clients. My problem is that I am unable to figure out how to allow a user to login without giving the view access to all issues.

4 answers

1 accepted

This widget could not be displayed.
Thanks for the useful pointers, Andy and Nic. Here's a full run-down of what I have done as it took me a bit of time to figure out even with the guidance. I had about a dozen projects and four staff and wanted to add a new project to which I would grant 4 client staff access. In the future I expect to open up some of the other projects and new projects to staff of the clients for those projects. 1. Set up application access for the client staff so they can access JIRA and Confluence. 2. Under Administration > User Management, I set up 3 Project Roles that are global across all projects: Admins, Developers, Client Users. I created default assignments of existing Admin group to the Admin project role, and of the existing developers group (containing my staff) to the developers project role. 3. Under Administration > Issues, Permission Schemes, I clicked the Permissions link for the Default Permission Scheme and removed the User group from all places where it appeared, and changed all of the Admin and Developer groups to the matching project roles. 4. In the same place, I copied the Default Permission Scheme and named the new permission scheme after the project that will have clients viewing, creating, editing and commenting on issues. I then added the Client User Project Role as appropriate to the Permissions. 5. Under Administer > User Management I created a group named after the client project whose staff needed to use the system and added those users to the group. This wasn't strictly necessary, as the next step indicates. 6. I navigated to the project that was to have client staff accessing the system, clicked on Administer link, then on the Roles link. Beside the Client Users role I added the group created in 5 above. I could have added the users individually to this role here instead.
This widget could not be displayed.

In JIRA you need to move away from using 'users' in your project permission schemes, and refer to roles, then you can define a per-project access group in the roles required.

In Confluence you need to remove 'users' as a default access group, and require the same per-space group membership for access.

This widget could not be displayed.

The default in Atlassian products is to use a group (jira users for example) to say "can log in". That's fine, but their default permission scheme then says "let jira users see this project". That means the default is anyone with a login can see everything.

You need to remove that - only use Jira-users for "can log in" and anything you truly want to be global.

Once you've unpicked that, then you need to put people back into the projects (as removing jira-users will remove their visibility). I'd heavily recommend the use of Roles here, as Andy says.

This widget could not be displayed.

Hi @Joe Murray

I faced the same issue as most of you did. 

To all the Atlassian Community Managers - please stop denying that it is complex.

The fact that there at least 3 threads (!) that are miles long where people have been asking the same "How Can I Add Client to ONE project ONLY" questionfrom 2013 until today (!) with ZERO people reporting issue resolution after receiving your instructions is on it's own.. ridiculous.

The only good step-by-step instruction that can actually help is this video from Atlassian: https://youtu.be/wvdVNpgG34M (I actually downloaded the video file since I'm afraid it will be deleted at any point). After spending hours reading through the threads and multiple failed attempts to follow text-based instructions - this was the only one that helped me to resolve the issue. Mind you, it is 4:30 long and includes over 12 high-level steps (and please do not go into counting actual 'actions' or 'clicks') to get this working. 

If you are aware of any other threads other then the ones mentioned below - please spread this message across to help other users:

  1. https://community.atlassian.com/t5/Jira-questions/How-do-I-add-a-user-and-allow-them-access-to-only-one-project/qaq-p/641554
  2. https://community.atlassian.com/t5/Jira-questions/How-do-I-configure-users-so-they-can-only-see-1-project/qaq-p/332248
  3. https://community.atlassian.com/t5/Jira-questions/How-do-I-add-a-test-user-external-client-to-Confluence-JIRA/qaq-p/657251

I really hope this helps all of you. 

Thank you,

P.S. After you have the issue solved (hopefully) - please check comments on this video. It's a good laugh. + Atlassian Community Managers - you should also check those comments if you're going to attempt to reply to this with a "we have the video, it's awesome and easy" ..  IT IS NOT and the fact that you even came up with a VIDEO instruction kinda says it all.

I have never claimed that it is simple to implement.

The principle is incredibly simple: do not give access to people who should not have it, give access to those who do.

implementing it is daunting for an admin who has not yet fully grasped how permissions work, and very dull and long-winded for those who have got it.

Annoyingly, the defaults make it complex to implement if you don't change them when you first set up a Jira.

Sorry, @Nic Brough [Adaptavist], there are some other threads (from which my comment was deleted?) where community managers claim this to be simple. really hope that the video would help everyone.

 

thank you

Joe Pitt Community Champion Jan 11, 2018

I think it seems complex because Atlassian gives everyone who can logon access by default and people don't realize what is happening until they need to 'restrict' access and the solution seems daunting. 

Every security class I've ever attended uses the model @Nic Brough [Adaptavist] is talking about; giving access, not restricting access. The complexity and pain comes from updating the current permissions and model. 

@Jake Yemtsov- no problem, I just didn't want people to think that Champions like me always agree with Atlassian.  It's the right model of access, the principle is simple, but I despise Atlassian's default and it is either complex or tedious to fix it after a system has been growing for a while.

As for your cross-posts, please, don't do that.  We don't need to see the same things hundreds of times.  And the spam filters pick it up as suspicious activity.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Tuesday in Jira

What modern development practices are at the heart of how your team delivers software?

Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...

278 views 1 4
Join discussion

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you