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?

[John Stephens · Accepted solution]

[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.  

[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.

[John Stephens]

I'm sorry, what is incorrect about the Answer?

If the procedure is documented, please provide the link.  That's all I'm saying.

The default OOB experience does not support this without manual configuration.  If this is not correct, I would appreciate the explanation.  It may have changed the decision.

[Nic Brough -Adaptavist-]

>Jira does not support this out of the box

That is totally inaccurate.  It supports "add one user, only allow access to one project".

An accurate answer would be "The defaults you get out of the box need to be changed".   Documentation links for that were given by Alexey.

[Claudiu Lionte]

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]

@Claudiu LionteThanks 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.

[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]

@Alexey MatveevThanks for your reply.  Unfortunately, it seems the procedure to implement this is quite complicated and too risky security wise to be useful.

This means our solution is to not use Jira.

[Alexey Matveev]

It is not risky. Jira is very flexible and you can set it up according to your requirements. 

[Nic Brough -Adaptavist-]

As I know of several government agencies (including at least two that don't exist, if you know what I mean) using Jira for different groups, it definitely is not about "security".  It's just the dreadful defaults.  Once unpicked, it's quite intuitive and easy to get right.