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; } } }

JUN 2018: How to restrict a user to one project.

John Stephens

First, the steps here do not work: How do I add a user and allow them access to only one project?

The user still sees all projects.

This KB Article seems close: How to restrict project access to different isolated user groups

but there are Cogs everywhere so it's like playing Whack-a-Mole and never hitting the right one.

I'm asking for the simplest access scenario conceivable: one user <-> one project.

I have to ask for very precise steps for the current UI, JUN 2018. Every older article deadends around step 3. Updates get lost in a sea of crosstalk.

I'm quite flummoxed that this is so difficult. This is literally one dialog, one check box in other systems. Am I missing something embarrassingly obvious?

Accepted answers

John Stephens

[The forum is nagging me for an Answer. Here is our Answer.]

Based on research and various forum posts, Jira's out of the box experience defaults global access for all users, including new users, by design or intent. This does not meet our requirements.

It is possible to change this behavior to provide project level security through a manual procedure, essentially changing all system defaults. However, this procedure is not specifically documented, meaning no one has referred to an official or supported procedure for this beyond the general help pages. See above and other threads.

Various unofficial procedures, such as the one linked in the Question, have no effect. Without a documented and verifiable way to switch to a restrictive model, we're simply not confident in the outcome.

Our solution is simply use an alternative product which does not present this issue.

All comments

Alexey Matveev

Hello,

The Browse Issues permission in the project configuration scheme lets users see projects. Mostly you add project roles to this permission and you include users or groups to the roles.

If a user can see a project, which the user is not supposed to see, it means that the user is included to the Browse Users permission either directly or via a group or a role. You need to find out how the user is granted the Browse Users permission and remove the user from this permission. You can read more about project permissions here:

https://confluence.atlassian.com/adminjiracloud/managing-project-permissions-776636362.html

John Stephens

Thank you, but this article doesn't explain what we're seeing.

It's a brand new Group with only "Access". No other modifications.

The user is also brand new. It's only membership is in the new Group.

The Group is added to the one project only as Tempo Project Manager.

Yet the user still has access to all projects. This has to be a bug or a system-wide setting mistake.

We're expecting the user to have access to this one project only as the Group member ship implies.

John Stephens

In another thread, I was pointed to Project/Permissions...

Oh boy, nearly all the permissions say "Any logged in user". I'm sorry, but this can't be right. Another project is the same.

Does this means any Groups and memberships are meaningless?

Now the question becomes, can this even be fixed? It what I'm asking even possible?

Alexey Matveev

If you have Any Logged in user in the permission scheme, it means that any user, who is logged in, can see your projects. You should remove this option from the permission scheme, if you do not want this behaviour.

John Stephens

[The forum is nagging me for an Answer. Here is our Answer.]

Based on research and various forum posts, Jira's out of the box experience defaults global access for all users, including new users, by design or intent. This does not meet our requirements.

Our solution is simply use an alternative product which does not present this issue.

Nic Brough -Adaptavist-

Wrong.

I think what you mean is that it does support it out of the box. But you have to configure it away from the defaults, and understand the permissions properly in order to do so.

I'm with you on the lack of warning that it's "open by default" and lack of Atlassian docs on the subject, and my opinion on the default settings are the same as yours - they're a terrible way to start out.

John Stephens

I don't mean to belabor the issue but "But you have to configure it to do so" is not out of the box.

The alternative required no such configuration or intervention. It just worked as expected.

If there's a "Click here so implement project specific security" button somewhere, please provide a link for future readers.

Nic Brough -Adaptavist-

Please don't mark incorrect answers as correct, it doesn't help anyone.

unknown

Hi John,

I wrote a very detailed how-to here:

https://community.atlassian.com/t5/Jira-questions/JIRA-Software-project-permission-restrict-user-access-to-one/qaq-p/779572#M265522

John Stephens

@[deleted]Thanks for the follow up. Hopefully it will help someone else. Unfortunately, in the time it took to debate this, our internal and external users were already setup in the alternative.

For clarity, while manual process was a huge decision factor, the showstopper was that we didn't trust ourselves to do it all, correctly. Meaning, the risk was we'd make a mistake allowing users to see outside their scope.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud