nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Joe Murray

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.

Accepted answers

Joe Murray

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.

All comments

unknown

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.

Nic Brough -Adaptavist-

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.

Joe Murray

Jake Yemtsov

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.

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.

Nic Brough -Adaptavist-

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.

Jake Yemtsov

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

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.

Maxime_m4kafa

You have to put the "Browse All Projects" permission on lockdown with a Project Role and then assign user groups to that project role on a per-project basis.

I wrote a blog post about it

https://projectbroadway.atlassian.net/wiki/spaces/MW/pages/1854308485/Discovering+Jira+user+management

Chris_Hamilton_jjq3tz

Yeah, for a company trying to "scale down", it seems like a clusterf*ck, even when adding Confluence pages, it opens in a browser window.

For a business owner, your clients do not want to be part of a process that is complex and confusing. It is intimidating for clients when all you need is "approved."

Clients don't want to sign up for more crap they have to learn how to use.

As a business owner, all I really need is simple: ability to create a process, ability to create tasks/subtasks, ability to have visibility of progress of projects/tasks, and most important...ability for the client to "approve" that task or asset...without having to sign up for a jira account.

That's nice they add the permissions and modify roles, but it does not solve the biggest issue: how to make it a seamless, easy process for your clients.

They really need to expand Jira into a Jira that also has trello/confluence visible on the same page without having to switch.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

jira

permission

community