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.
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.
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:
I really hope this helps all of 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.
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.
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot