How do I add a user and allow them access to only one project?

[Morgan_Thompson]

I just want this user to be able to login and see the one project. However, the new group I created has no ability to login so I have to add him to the default jira-user group but then that lets him see all projects which is not what I want.

As this user is the only user in this new group, how do I grant this group login permissions so I can then add that group as a user in the one project?

[Ivan Tovbin · Accepted solution]

Hi Morgan,

The best way to do this, is to add this user (or group) to a project role. After that grant that project role proper permissions within your project. Also please note that by default Jira already has some project roles configured and all new projects come with a default permission scheme which grants different permissions to these roles. So you might wanna check the existing project roles and their permissions for a given project first.

[Morgan_Thompson]

Thank you I finally got it to work. What I wound up doing was:

1. Create new user.
2. Create new group.
3. Grant new group login permissions.
4. Add the new user to the new group.
5. Remove the new user from the default jira-user group.
6. Add new group to User roll within the desired project.

[John Stephens]

I tried these exact steps.  It makes no difference.  The user see all projects.

[Sergey Podaru]

@Nic Brough -Adaptavist- Hello. I also have this problem. And i think it's problem with Jira Settings. Maybe u can show me pictures how see your settings? Because i'm in stumped

[Nic Brough -Adaptavist-]

Pictures would take too long, and would vary by version.  So:

• Check in "manage applications" to see what groups have "access" to Core/Software/Service Desk
• For each permission scheme you have, remove any mention of those groups for the "browse" permission, replacing it with other roles or groups as required to let existing people in.
• For each permission scheme you have, remove any mention of "anyone" for the "browse" permission, replacing it with other roles or groups as required to let existing people in.
• For each permission scheme you have, remove any mention "any logged in user" for the "browse" permission, replacing it with other roles or groups as required to let existing people in.
• For each project you have, check all the roles, removing any mention of those groups, replacing it with other groups as required to let existing people in.
• Now add your new user into the group that gives them access, then add them into the right role(s) in the project you want them to have singular access to.

[Joe Pitt]

JIRA works by GRANTING access. You can't restrict access. By default (BAD idea) it grants access to the group used to logon (used to be jira-users but may be different on your version).  This is probably where you're getting the access from.

 The FIRST thing you need to do to get control is to remove any groups with logon privileges from the permission scheme unless you absolutely want everyone to have that permission.  Then I suggest you setup user roles for the various functions like, tester, QA, Browse Only, etc. Then you can create one permission scheme to cover almost all projects. The project admin controls which users are put in the roles.  This may be a big effort, but it will payoff down the road by making it easy to control access.

[John Stephens]

That's the thing, we didn't grant anything.  The user just automatically has global access.  This has to be a bug.

We're expecting a similar experience to every other permission system, create user, give specific permission.  Done.

[Joe Pitt]

As I said, it is the default

[John Stephens]

So yes, I agree that jira-users having global access is an alarmingly bad decision, but we removed the user from that group as specified in the above steps, but...

The user still has access to all other projects.  This is the bug. 

[Nic Brough -Adaptavist-]

It's probably not a bug (as in "works as intended").  Pick one of the projects the user has access to.  Look at the permission scheme.   What does it say for "browse project" and how is that particular user getting it?

[John Stephens]

Ok, took a while to find this...

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?  

[Nic Brough -Adaptavist-]

Ah, good, it is what I expected.  I'm afraid it is "right" - you've got the defaults that Atlassian distribute.  In my opinion, the default is utterly hopelessly wrong and totally misguided because it bites almost every admin who needs any form of access control.

It does indeed make groups and roles pointless, as it's just "can log in". 

However, you can fix it - just remove the "any logged in user" (after checking that the groups and roles you do want have access).  Unfortunately, you're going to have to fix every permission scheme.

I would also go to Admin -> Project roles and check the defaults, removing anything that might let unwanted users into a project.

[John Stephens]

O...M...G...someone said that in another thread and I dismissed it as 'nah, can't be right'.

Thank you for confirming though.  Unfortunately, this means Jira is unusable.

1. The fix is way too complicated and the requirement to backtrack to existing projects means the risk of gaps and leaks is a liability I can't accept.  The scenario involves external, unrelated users.

2. If security is such a dodgy implementation, I shutter to think of what else is lurking out there.  Global access by default is a showstopper in itself :().

Again, thanks @Nic Brough -Adaptavist- for settling this.  Good Fortunes!

[Joe Pitt]

As @Nic Brough -Adaptavist- said, it is the default so it isn't a bug, it is just a horrible way to implement the default. It would be nice if there was a 'best practice' or 'beginner tips' site for us to warn people about this. 

[Joe Pitt]

@John Stephens I disagree the fix is complicated. If you use project roles you can have one permission scheme for all projects. Yes, the conversion may take some time, but I think it would be far less than starting all over with another tool.

[John Stephens]

Yes @Joe Pitt, but it's so bad it's dangerous as we're involving external entities.

It's totally fine.  We'll just let the internal projects run their course and use...[something else]...for everything else.

Thanks again!

[John Stephens]

@Joe PittIt's complicated in that we even have to do it.  And changing from unrestricted-to-restricted is risky because what if we miss something?  That's the problem.  With the alternative, this isn't even a thing so that closes the deal right there.