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

[Robert Meador]

I have a client I want to be able to view and comment on issues on their project only (all other developers should be able to access this project, as with all other projects). I have created a user, created a group for just this project-user, created a permissions scheme with one entry, allowing the user to Browse Projects, and in Project Roles have this user enabled with the Developers and Users checkboxes (and not the Administrators checkbox).

But when I log in as this user, I get a mostly empty dashboard and at the top right it says "Log In". I click that and the page just reloads the same - can't seem to "log out" (if I am logged in) without closing the page and clearing cache, nor to "log in" since when I do so it seems I am not logged in.

Previously I tried adding the user to the Users group, but that let them see all projects.

What else do I need to do? Is there a step-by-step for this - it's very confusing.

[Justin Alex Paramanandan · Accepted solution]

Hi Robert,

First things first, I will list down what you have done:

• Created a new user
• Set this user to the developers and users roles.
• Created a permission scheme for this project.

Your requirement is just to allow this one user to access this project, but not other projects; whereas other users can access all projects, including this one.

So, based on this, maybe you can start off by applying this steps:

1. Remove him from all the roles (we'll come back to this later).
2. Delete the permission scheme you just created recently.
3. Now, check all your other permission schemes. Do they have the following set:
   • the groups users (the generic group for all users)?
   • any roles (Developers, Users)?
4. If there are users groups in most of the permission schemes, you would need to add a new group, as this would remove him from other permission schemes that doesn't have this new group; hence, eleiminating the possibility of him viewing other projects.
5. Create a new group, and set this group to the JIRA Users global permission. This would allow him to login and logout.
6. Create a new permission scheme, and set this new group to the Browse Projects permission.
7. Ammend other permissions in this new scheme (such as adding developers and other users; do this via groups).
8. Associate this new permission scheme to the said project.
9. Add this user to this new group, and remove him from the users group.

Remember to perform the above as a JIRA administrator, as step 5 requires it, and steps 6-9 is easier to be done when you are the main administrator.

[DavidT]

Thanks, your explanation helped me solve this issue. Basically you need to do the following:

1. create a new role. This role will be a template for the type of user and the types of permissions they will have in a specific project

2. copy the default permission scheme in the Issues management section. Add new permissions for this new role to the copy. Rename it.

3. Associate this new permission scheme to a specific project

4. now go create a new group. you can't use jira if you aren't associated with a group and most default groups have global access across your projects.

5. Give that new Group Jira User access. so it can login and out.

6. Assign your new user to that role and group. they should now have the role permissions to the specific project you want and should be able to login and out.

[Simon Riedel]

@David,

your explanation seems the only one I understand, I hope you wont mind if I repoen this old thread.

5. says: "Give that new Group Jira User access. so it can login and out.

how and where exactly can this be done, and are you talking about "Users" Role or "jira-user" Group ?

Have followed your advice but can not login the One-Project-User I have created

... I hope that by copying your HowTo I will finally understand what I am doing and being able to reproduce in other cases in future on my own.

Thanks.

[Nic Brough -Adaptavist-]

Jira access is, as we've covered here, a global permission, under the admin section

To log into Jira, your account MUST be in at least one group that says "you can log in". The groups that can log in are the groups named in the global permission scheme (default is simply "jira users" group, but a lot of people change that, often when they realise they can't lock down their Jira if they're letting "can log in" grant "access to all projects" too)

Roles are irrelevant here, roles are for projects only, not Jira in general.

Also, David's guide is unneccessarily complex and doesn't give you the flexibility you probably want.

[Brendan Flynn]

Thanks, this helped me today. I did not realize I had to add group to global permission.

[Ryan Supeene]

how can you even add a group to a global permission 

[Nic Brough -Adaptavist-]

I don't think I can answer that comment without sounding horrendously condescending.  So I'll be technical and short:

Log into JIRA as an admin.  Go to Admin -> Global permissions.  Click on "add" next to any of the global permissions.  You will be offered the list of available groups.  Select one and hit "ok".  You have now added a group to a global permission.

[MikeS]

We've had a JIRA account for a long time, but recently I needed to take over the administration of it. User permissions for projects are about 10x more complicated from a UX perspective than they need to be. The UI is tied too closely to the underlying implementation rather than providing a UI on top of the implementation so it is easy and mostly foolproof to do correctly.

Reading Justin Alex checklist of what is required to configure JIRA was the last straw.  We are going to move to something else, maybe JIXEE, maybe Sprint.ly or maybe something else. 

[Faust Jonson]

Thanks  

[Keith Weiss]

I hate this permission set up. It is way too complicated. This is a very simple use case, keeping people not on a project from seeing that project, and probably one of the most common ones and there are 9 steps some of which include updating every exisiting project to make this happen.

And the consequence of doing this wrong is that clients can see each others issues which is a total disaster.

Total fail.

[Nic Brough -Adaptavist-]

It's only the "open by default" that gets inherited that is the problem here. The permissions are really not that complicated, and it's really easy to set it up for partial restrictions, especially if you dump the default setup as soon as you possibly can.

[MikeS]

Sorry, but yes they are "that" complicated, at least for someone who is not a full time JIRA administrator.

[Nic Brough -Adaptavist-]

What is complicated about "Define a rule to say who can do something based on an attribute.  Give the user that attribute."?  Other systems do exactly the same.  Often with a lot less flexibility.

It really is not complicated.  What is complicated is unpicking the default "let everyone in" setup off-the-shelf.

[MikeS]

What is complicated about it is that you have to visit numerous different screens to affect a desired outcome,  there are few links from any one screen to another and it is not possible looking at any one of the screens to learn where else a user has to go to affect the designed change.

And if you don't get it right then people have the wrong access – often without you knowing it – then people get access to things they should not.

JIRA needs to implement a single screen that allows someone to configure permissions for a project.  A user should not have to follow a 9 step process as outlined above.  As a web+database developer, I know it can be done.  JIRA software was designed with the developers of JIRA and those who spend full time administering an instance of JIRA, not for the other 99.999% of the world.  

[Nic Brough -Adaptavist-]

"numerous different screens" - well, three - one to work through a permission scheme, one to associate with a project and one (only needed if you use roles) to put users in roles.

Your suggested "single screen" would be a massive downgrade - you'd be throwing away a lot of the power of shared schemes and the flexibility to use different roles and projects.

[MikeS]

> well, three 

See?  Two too many.

> Your suggested "single screen" would be a massive downgrade - you'd be throwing away a lot of the power of shared schemes and the flexibility to use different roles and projects.

Absolutely not true.  

Atlassian currently uses as UI architecture of generic components that allow them to mix-and-match powerful functionality.  But what they generally do not offer is UIs with use-case specific workflows.

What I am saying is that they absolutely could offer use-case specific UIs that would not eliminate any functionality, but they would much easier for people who have not invested half a decade pr more in learning JIRA, like you have.  

And nothing about use-case specific UIs would need to eliminate existing UIs; just make some of them easier to use.

[Robert Meador]

Interesting to see where this is going. In our case (original poster here) we are coming to the conclusion that JIRA is just too messy and complicated for what we need it for. We're a web development firm and need to track a variety of projects for a variety of clients (JIRA doesn't give us a client/project hierarchy); we use the same permission scheme and workflow for pretty much every project (JIRA creates a new workflow for every project); we use the same default category for every project ("active" - JIRA won't let us set a default category); and every time we create a new project we waste time trying to remember where we set all the things we need to set (category, workflow, permission scheme). Oh, and it used to be possible to jump between JIRA tasks and Confluence (where we keep more in-depth spec content) for a given project by clicking on the project icon at upper left, but that no longer works. Thanks Atlassian!

Don't really like Basecamp but I'm sure there is something out there that is a better fit for us than this, which is just too unintuitive and complex for our needs. We are actively looking for a replacement.

It's our own fault for choosing JIRA in the first place - I don't hold it against Atlassian. I'm sure it's the right fit for some teams, just not for us.

[Nic Brough -Adaptavist-]

We're not ignoring feedback, the problem is people not understanding that it is not that complex, and the defaults are to be open and collaborative.

[Javier Távara]

I hate this too. It's really complicated. It seems I need to take a course to learn to do simple things on Jira.

[Nic Brough -Adaptavist-]

It's not that complex.

• Check the rules for project access - hopefully, you've stayed with the default ones that say "browse project = role: user"
• Add your user to the "can use application" group so they can log in.
• Add them to the role of user in the project you want them to see.

The bit people do struggle with is that the default setup is to allow everyone into every project, and you should change that the instant you want to start hiding projects from people.

[MikeS]

Nic: You are coming across as defensive, an apologist and a scold rather that actively listening to your customers and former customers. Rather than accepting that JIRA has a poor UX for managing permissions and is indeed far too complex for anyone but a full time JIRA administrator you are talking down to those of us who are trying to explain our legitimate issues.  As a "Partner Champion" I find that unprofessional and very distasteful.

JIRA has the fundamental functionality required to fine tune permissions but requires complex steps to configure correctly. What JIRA needs is an ADDITIONAL interface layer on top of the existing layer that provides simple one-step functionality for the most common use-cases.

JIRA also needs a better auditing tool so that you don't accidentally expose all your projects to your partners who are only working on one.  We know this because we had a partner tell us they could access everything, and we could not figure out how to fix it. That is the primary reason we abandoned JIRA.

It is also the reason we proactively argue against JIRA, especially to our clients, whenever the topic of project management solutions comes up.  And the irony is, ignoring the permissions issue, JIRA is otherwise the best solution available.  

But as we say in the USA "Besides that Mrs Lincoln, how was the play?" 

[Nic Brough -Adaptavist-]

<sigh> I am a customer, not an Atlassian.  I'm definitely being grumpy about it, but that's because others here are not grasping that it really is simple.

There are complexities (took me a while to get my head around roles), and the defaults are poor, but "add user to project" could not get more simple without losing the flexibility a lot of Jira clients need.

I've tried to explain it, I can't explain it in more ways, I just can't work out a way to explain something this simple in a way that some people here might grasp.

I'd agree an interface for a "one step functionality" would be useful, but I'd struggle to make it more simple that what is already there.  Later versions have the "permission helper" too, although it's limited in where it's usable, and you'd have to use it one project at a time.

[Dean Grande]

I hate this too.  Too complicated.

[Jay Ingold]

It may not actually be complicated once you understand it. The issue, I think, is that it's not intuitive. As someone who has gotten my team to start using the tool, I am the admin, and am figuring things out on the fly. No tool I can remember using in the past required this sort of configuration to achieve a similar result. Maybe this way is ultimately better, I don't know, but it's certainly not familiar. There's definitely a reason that when I search the web for an answer, I get multiple pages of results. It can't be because every one of those OPs is incompetent. 

[Nic Brough -Adaptavist-]

I agree that it's not intuitive, but it's not about people being incompetent, just that they're struggling with what is simple in theory, but almost always appears complex because it's generally set up in a counter-intuitive way (and that includes a new off-the-shelf system - the defaults themselves are a pain).

I have every sympathy when a new admin looks at an existing Jira and thinks "how the hell does access work here?".  I don't like the interface for it, and I despise the default settings - I'd rather be explaining to people "when you create a new user, you also need to add them to roles that give them access" than "you have to unpick a load of defaults that don't work for you".

What I don't get is how "to give a user access, grant it to them" and "if you don't want them to have access, don't give it to them" is so complex.  Surely that, at least, is intuitive?

[Jay Ingold]

I've gotten it figured out now by following your method somewhere further down this page, so thank. The hang up is the defaults, like you said. Your solution below about creating a "General Access" group works well, and based on the little experience I have, I feel like that's how it should be handled out of the box. Either I have to add users to the group or they are automatically added on creation. Either way would be more clear than the current out of the box functionality.

In regards to your last question, that concept is intuitive and not complex. I think the confusion comes in when you don't want a user to have access, didn't explicitly give it to them, yet they still have it.; the system gave them the access by default. "Application access - Any logged in user" is just less clear than "Group - General Access."

Those are my thoughts having recently gone through it. Surely once I'm more familiar, these things will be more obvious and sensible. They're just difficult for someone new to it, I think.

[John Stephens]

This is like one dialog in TFS.  Yes, JIRA is overcomplicated to the point of being non-functional.

Global access by default?  Is it still 1998 somewhere?

[Ronan TREILLET]

"the problem is people not understanding that it is not that complex"

This phrase is so wrong at so many level...

If people doesn't get the product, they are not the problem !
Yes we all get that jira is really flexible and stuff, but we don't want end up spending 5 hours in order to achieve a simple task that most tools handle quite easilly (like confluence does !!) !

[Nic Brough -Adaptavist-]

Have a proper read of the discussion above - there's two topics really.

1.   "to give a user access, grant it to them" and "if you don't want them to have access, don't give it to them" - this is not complex at all.

2.  The default permissions are wide open and have to be unpicked if you want to lock anything down.  This is where it is complex, but once fixed, 1 kicks in in full.

[Thomas Talinski]

I'm rather new to Jira and don't want to be too critical too early.

But I'm having the same impression so far about several things in Jira. :(

Nic:

thx again for your help. At least I can understand you. :)

But generally it feels really weird that you seem to have to use different terms than the original named ones, cos those originals are too confusing. That confuses me even more not to find the default names of terms in your (very appreciated!!) posts.

Args...I'm really asking myself if I'm using the tool I really want....

[Nic Brough -Adaptavist-]

I tend to rename the very top level one because if I don't, I can guarantee you that someone will get mixed up between "Jira administrator" and "Jira system administrator". It's happened on mroe than half of the "my admin can't do X" questions I've had a go at answering, and I really do wish Atlassian would give the two totally different names.

[Thomas Talinski]

Nic, that sounds like a real good plan... :)

[mcc24mm1]

I’m trying to add two external users to our JIRA instance and only allow them to see one project in there. We’ve been reading through documentation and unable to figure this out so far. Our solutions that we’ve tried keep doing the opposite of what we’re trying to do; when we login with a new external user’s credentials, the project this person should see is hidden and they see all other JIRA projects that they shouldn’t see. We formerly had all projects automatically associated with the group, “JIRA- Users,” which was everyone in our JIRA. We created a new group for all internal users, associated that group with each project, and then disassociated the JIRA-Users group from each project. We then changed the groups that should be able to see the one project that we want the two external users to have access to and we got the result listed above; the users cannot see the one project we want them to be able to see and they can see all the other projects we don’t want them to see.

[Nic Brough -Adaptavist-]

You need to analyse what is giving them access.

In most case, you'll find that the problem is the Atlassian default - the group "jira users" is used to say "these people can log in", which is fine in itself, but then permission schemes say "can do things in this project" and someone adds "jira users" to that line.

The point here is that I suspect you have NOT put the user in the "can log in" group. And when you do, you'll find they end up with access all over the place, which you might not want.

If that is the case, then what you need to do is painful, but once done, easy to maintain. Create a new group called something like "general access", put *Everyone* except your new user into it. Then go through your permission schemes and add it in wherever you find "jira users". Then remove "jira users" from all the permission schemes.

Then, if you need more restricted users, just don't put them in the "general access" group.

[Robert Meador]

OK - whew. I thought I had it all sorted but it doesn't seem to be working. I removed "users" from all permission schemes. I edited my client so he belongs to no groups except "users". And I set up custom permissions for his project to allow him to view issues, create, edit, etc.

But, when I log in as him I see nothing - no way to get to his project. Just a generic dashboard with no menu or links or anything that will let me get to his project.

Also, when I switch to Confluence via the far-left icon in the header, I can see ALL projects and access them in Confluence. I didn't set that up - I think.

Confused...

[Robert Meador]

OK wait - I see I created a permission scheme for this project and this guy, but the permission scheme does not list the project. When I edit the project I see only one permission scheme (our General one) and no obvious way to add another. Can I only have one permission scheme per project?

I want this project to be available to all our staff as with any project, and also to this client with selected permissions.

[Robert Meador]

Actually here is what I did:

• Created a new user
• Added him to the users group (so he can log into Jira)
• Removed the users group from all existing permissions schemes (so users can log in by default but nothing more)

So far so good, right? That's what I read in the previous response above - have to be a user to log in, but don't let users do anything by default.

Now, I'm confused about groups vs Project Roles. We have both in our system. Roles = Administrators, Developers and Users. So when I am working in permission schemes should I be assigning groups to be able to do tasks, or roles?

Another thing I'm confused about - in the Users list there is a link for each user for Project Roles, which has its own red and green indicators for each of the project roles for each project in our system.

Back to your questions: First, why the F isn't there a link in the left side nav for Permission Schemes. Everything else is there but not this, so every time I need to get to it I have to hunt around until I find a link....anyway...

Item 3: No "users" in any permission schemes

Item 4: No "users" groups in any permission schemes, so not sure the rest of this applies.

Item 5: New group, but there is no "Jira Users" global permission. We do have our Default Permission Scheme but that grants members access to every project, so we don't want that applied to our new user, right?

So - not sure the rest of these steps apply.

This system is just so damn confusing and complicated, it makes me feel stupid and angry. Seriously considering finding something else, or just building something.

I think I need to screenshare with support or something - have them walk me through all this.

[Nic Brough -Adaptavist-]

Groups and roles are best thought of separately.

Groups do what you'd expect instinctively - they let you group users together. That's pretty much it. You can use groups in permission schemes directly, and it's simple - if you want to give permission X to a group of people, you put them in the group and then put the group in the permission scheme.

It's important, at this point, to understand what a scheme does - it allows permissions to be granted to people who match conditions. You tell Jira "for project A, use permission scheme 1, for project B, use 2... and so on". You can see that there's an immediate implied problem here - if you only use groups, and you want different groups or users per project, then you have to have one permission scheme per project. Which is a maintenance nightmare (even before you start on the fact that only system admins can maintain groups or permission schemes)

So, enter roles. Roles allow the project admins to say "this person belongs to this role in this project". They also allow them to say "this group belongs to this role in this project". So, you now have the flexibility to allow the permission scheme to say "grant permission X to this role".

In your case, you sound like you've started well, but stumbled at item 5, so you're close, but not quite there. Could you explain what your "default permission scheme" says, exactly, for "browse"?

[Robert Meador]

OK - making some headway!

I created a new permission scheme for this project, and assigned Admin and Developer project roles to the various things I needed them assigned to. I also assigned my single user the appropriate permissions. I set this permission scheme to work for this project and presto - I can log in as him and see only this project now - in Jira.

However in Confluence I was still seeing all Spaces, so I went into our default Confluence permission settings and removed "user" project role from everything. We don't want just anyone to see everything.

Then I attempted to add my guy as a single user to this Space - but - when I switch to Confluence when logged in as him, I get a "Not Permitted" - no Spaces at all.

So I must have missed something. For his individual user I did check all the "Add" options for this project. What else do I need to do to allow him to access this project?

And thanks for all the help/attention!

[Nic Brough -Adaptavist-]

I'm assuming your Confluence is using Jira-users?

Confluence has a similar access scheme but, as it's got a different purpose, it's not identical.

First, check global permissions. In there, you MUST grant all your users the "can use" permissions somehow. As with Jira, the default for confluence is a big group called "confluence users" which lets them log in.

My usual advice in Confluence is similar to Jira - have a big group with everyone in it for "can log in" and then do NOT use it in any space permissions, ever.

I think you've done mostly the right thing, but because you've removed the global side of things, your user no longer has any right to log in, so he's not getting as far as the spaces at all! Can you check that you've got a nice big "can log in" group that does not get used for anything else? And that he's in it?

[Robert Meador]

I mean "in our Confluence" - same thing in our case

[Robert Meador]

Apparently I don't need the User group to allow switching via the icon. Maybe they fixed this? Anyway I seem to have it all dialed now - thanks everyone for all the help. Going to make some good notes for myself for the future.

It would be nice if this was easier, but I understand the desire to make it flexible as well.

[Thomas Talinski]

quoting Nic Brough:

"If that is the case, then what you need to do is painful, but once done, easy to maintain. Create a new group called something like "general access", put *Everyone* except your new user into it. Then go through your permission schemes and add it in wherever you find "jira users". Then remove "jira users" from all the permission schemes."

Wouldn't it be enough to just at that "general access" project role to the permission "browse projects" and to delete project role "users" accordingly?

I'd believe the other permissions can stay as before as nobody without the permission to browse a project could change anything cos he simply cannot see it?

or do I miss anything?

[Nic Brough -Adaptavist-]

No, because you still aren't dealing with "can log in", which is the problem - it's the same as "can use projects" by default, and that's what you're trying to unravel.

[Jobin Kuruvilla [Adaptavist]]

Actually, you can give the "JIRA Users" global permission to the "general access" group and that will solve the login issue. Make sure the new user is not in jira-users group after you do this.

[Jobin Kuruvilla [Adaptavist]]

There is no "Can log in" permission. Nic is talking about the "JIRA Users" global permission. You can find it under Administration > User Management > Global permissions.

[Thomas Talinski]

Am I too blind or why don't i find this "can log in" permission in the default permission scheme at all?

I'm still not sure whether I'm on the wrong train entirely maybe :(

[Nic Brough -Adaptavist-]

Yes, my apologies for the confusion.

I say "can log in" because "Jira users" is inherently confusing and doesn't say what it really means, and it's got different names in Confluence and Jira. Confluence is better in that it says "can use", but that's still quite clunky and vague.

[Thomas Talinski]

Nic & Jobin: at first I want to thank you for you efforts to help me out!

Allthough I'm not yet finished, I'm afraid

First of all I'm wondering why I'm only allowed to write one post per day and not even allowed to edit this one post as I tried yesterday.

!?!?

Realising, that there are these global (user) permissions which I haven't had discovered so far, I'm getting more and more confused. For my taste jira has little to many options hidden in different places to be having a kind of "safe feeling" to have thought of everything you should have.

But I seem to have reached my aim now anyway but I'm not really trusting this feeling as you both offer more ideas to solve it. :)

So I list shortly what I did and achieved so far and hope that you guys maybe try to follow my thoughts.

My aim was to have a new project with members, who shall not have access or even knowledge of other projects but this new one.

What I did is:

- I added a new project role named "Browse projects" where I put every user into except the users who shall only see "their" project and not all projects

- in the default permission scheme (I so far only use this) I added this new project role "Browse projects" to the permission with the same name and removed the project role "Users" from it

- I created two users for the new project and who only should see this one:

a simple user with the project roles Users (cannot avoid that one, can I?), Developers and my new one Browse Projects (of course only for the new project)

an administrator for this single project with the same project roles + Administrators (of course only for the new project)

- I did nothing else (not edited the jira-users group nor the global Jira Users permission) and when I log in with those two users I can only see that one new project and none of the other existing projects.

And in the dashboard I see only the issues belonging to that single project.

Seems like that did the trick or do you both see any weakness in my plan? :)

[Nic Brough -Adaptavist-]

No, that's simply a variation on what we said in the first place, so it works fine.

[Thomas Talinski]

Thank you, Nic!!

Looks like I got it solved now. I sincerely hope so

But I guess it won't be long until I got a new topic.... :)

And it looks like I'm now allowed to post more often than once in 24 hours which will help a lot in the future.

[Thomas Talinski]

Hm... the problem has extended itself a bit. :)

What if I want a poject-specific administrator FOR ONLY ONE PROJECT and no others who can:

- edit workflow/permission scheme etc. only for that project

- edit project roles just for that project

How do I achieve that? Do I need a special user group or something like that? Does anybody know that and would be so nice to help me?

To be honest all that stuff of user groups and project roles and permissions here and there is turning around in my head. :(

[Nic Brough -Adaptavist-]

You can't do the first, only the second

There are four basic levels in Jira - Root (can admin system), Jira admin (can do all the stuff about workflows, permissions, users, fields etc, but isn't quite Root), Project admin (can edit versions, components and role members) and User.

That's it. A project admin can only administrate the projects they have admin rights on, and that admin rights is entirely limited to components, versions and users in roles.

If you have the Agile plugin, then project admins can set up the Agile functions and that includes a "simplified workflow", but still not fields or the rest.

[Thomas Talinski]

hm four levels of what?

groups? roles?

I never saw something like "root" somewhere inside Jira.

Only jira-administrators as the so far highest institution I noticed, but root sounds even more powerfull?

Sometimes I ask myself if I'm too dumb for the system or if the system in itself IS maybe just as confusing as it right now apears to me :(

[Nic Brough -Adaptavist-]

Four levels of permission. I've called the highest level "root" because the terms "Jira administrator" and "Jira system administrator" are very often confused.

IF you are using OnDemand, you will not see (or get) Root/Jira System Administrator, as it is reserved for the hosts.

Roles are done at a Project level *only* - you cannot get any form of system or Jira administrator rights by being in a role. They only affect projects. So you can use them to say "people in this role can admin the project", and hence give them power over other users in the project, versions, components and Agile config.

[Marlon Aguiar]

Hi Robert,

Could you please check if your user have Application Access? That can be found on System > User management and on the left side menu Application Access.

Hope it helps!

Regards,
Marlon

[rfrenkel]

I just did this for one of our clients, and one of the points of confusion is that there is a jira-user group and also a JIRA Users global permission and it's easy to get those confused. 

Here's what I did:

On the "Users" admin tab:

1. Create a user(s) for your client
2. Create a new group for them (no permissions to start)
3. Assign the user(s) to the new group
4. Add the group to the global permission "JIRA Users" which lets them log in (and nothing more). See screen prints below
   
   

On the "Projects" admin tab:

1. Under "Roles" add the group to the Clients and Users roles (you can hone that later)
2. Use a "suitable" permission scheme for the project. That is one that allows the "user" and/or "client"  role to "browse projects and issues" and also "create issues" and possibly "close issues" etc. Note that the Permission Scheme, while global, is being applied to THIS project. Giving the user "browse on projects" will only apply to projects on which they have been assigned a role (see 1 above). So they can only in fact browse this specific project. Note that you can directly assign permissions to groups as well as roles. 

You can test this now by logging in as one of the client users on a fresh browser. 

Here are some screen shots:

1) After creating user(s) and group, go to Global Permissions and give group JIRA User global permission:

image2015-8-20 8:26:7.png

image2015-8-20 8:26:55.png

On Project Menu, Assign Group to Role

image2015-8-20 8:29:39.png

And Role to Permissions through Project Permissions (note that this is specific to roles on this project, so no role, no permissions:

image2015-8-20 8:31:24.png

[Ariella Cheskis-Gold]

I'm stuck on this step: . Add the group to the global permission "JIRA Users" which lets them log in (and nothing more). See screen prints below My Admin panel doesn't look like this.

[Nic Brough -Adaptavist-]

The screen shots here are from a rather old version of JIRA. There's also a couple of problems in what Richard has posted - he's assumed that you know you have to remove jira-users from all roles, schemes and other places that it is used, and he has forgot to mention that when you add your new group to "can log in" global permission, then any new users will be added to it automatically from then on. To solve your current problem, the text is the same - go to Admin -> Global permissions and find the "can log in" line, and add the group. The screen is the same, it's just a different layout.

[mcc24mm1]

Hi Nic, Still trying to figure this out. Is there comprehensive documentation that lists this step by step?

[Nic Brough -Adaptavist-]

It's not that complicated. You have a group which allows "can log in". By default, Atlassian have used that group in projects to say "can use the project" as well, which is a pain in the neck. You need to undo that. The best way to do it is go through your projects and remove jira-users from all roles, replacing it with everyone who should be in the project (as individuals or via other groups). Then you can simply *not* put your single user in the project you don't want them to see. An alternative is to create a new group called something like "jira login". Put everyone currently in jira-users into that group. Go to global admin and ADD the new group to "can use jira", then REMOVE jira-users from it. Finally, remove your single user from jira-users - they won't be able to see any projects at all.

[Joe Pitt]

As Nic said, Atlassian, by default, adds the 'everyone who can logon' list to the default permission scheme. That violates every security class I've ever taken, which is only give out access as needed. As Nic said, if you delete the logon groups and start over with who really needs access I believe it is easier. People end up fighting the default. I personally like using project roles because the project lead can manage them instead of the JIRA admin. And, just because someone is a 'tester' it doesn't mean they should have access to every software project that needs testing. 

[Javier Távara]

Finally! I had to erase the 'everyone who can logon' from the default permission scheme. Not it works like I want! Thank you.

[Joe Pitt]

Glad it worked

[Jim Hodgen]

Hi Joe,

 Is this thread the latest word on how to make this thin facade over a relational database act like an application?   I have to admit that I have been looking to do what should be a simple, essentially default on an enterprise class system and find that I have to undo everything in the default and fight to restrict.   That is a recipe for a nice little friendly system AND  a recipe for a lawsuit when there are separate clients or project sponsors.   

Would it help whoever is insisting that the current system is OK and that the problem is stupid and uneducated users to see it better if they understood that Jira is presenting as a growth-capable system but is guaranteed to fail every audit it meets in the current default?

 I am hoping that this has been dealt with in the intervening time period since the 2013 beginning.   Is that true or are we still having to fight the system architecture and factory -config to make it secure enough to support separate IP's?

[Nic Brough -Adaptavist-]

I'm afraid we still have to fight.  It's always worth it though - once you've got rid of the painful default, the user permissions are simple and intuitive.

[Eugene Yasiuchenko]

Hello Nic,

I've done as you had suggested in many of your answers (comments) to the similar topics people keep creating - I've deleted default access for all users with the jira-sw license in all permission schemes we have. And it worked well - now when I'm adding a new user - he/she does not see everyhing righ away. All projects are closed by default.

BUT... does it mean that for giving access for a specific user to a specific project I would have to create new permission scheme for each different project each time? 

e.g. We have separate Jira project for each client....

UserA is from ClientProject1

UserB from ClientProject2

So projects1 and projects 2 would have to have different permission schemes?

[Joe Pitt]

If you build your project roles to cover all logical functions you should only need 1 permission scheme. The project lead then puts the user in the appropriate role. For instance I use a role of 'User' and give them permission to do all the functions in the project. I have a role of 'Browse Only' and give that role to people that only need to browse the project. Some other roles like QA, Tester, and others I use for conditions on transitions. 

[Eugene Yasiuchenko]

I've misunderstood the idea initially. everything is OK now. Thank you. 

[jsarkar@shieldwatch.com]

@Eugene YasiuchenkoWhen a discussion thread started from 2103 and still going on - it must be complex. I have similar need of running multiple projects in Jira and giving clients access to their specific projects so that my dev team can communicate with them. I don't want to reinvent the wheel. As you have figure out the solution can you pls guide me thru this setup process? Thanks in advance.

[Waffle Dog]

Agreed, this is way too complicated and is putting us off from buying the service. I've been through this entire thread and still can't figure out how to give access to a client for one project only. Whilst there needs to be flexibility, the lack of a simple way to add a user to a specific project is crazy. A real weakness in the system...

[Joe Pitt]

If you follow Best Practices of security there isn't a problem.  

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

1. 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.
2. Then I suggest you setup Project Roles for the various functions like, tester, QA, Browse Only, etc.
3. One permission scheme will cover all projects unless you actually want everyone to have access to the project. If so create a new permission scheme and give the logon group access as desired. The project admin controls project role membership so the JIRA admin doesn't have to add/delete users from groups

This may be a big effort, but it will payoff down the road by making it easy to control access.

[Robert Meador]

OK - that's done it!

Now - is there some way to bulk update the 53 projects in our Jira to remove access for "users"?

Perhaps I have to ask support to do it for me?

[Jim Lynch]

Here is what I have in our system:

<th colspan="1"> </th><th>Confluence/JIRA Rights</th><th>Permissions Required</th><th colspan="1">Where Permission is Configured</th>

1	JIRA Login - no project access, no Confluence access	Membership in users group. (This is granted during account creation.) NOTE: users group is assigned to projects on project creation. We then remove the users group from each project after project creation. We need to do this for 2 reasons: Removing users group from projects is needed to hide projects from clients. The users group has to be assigned to projects on creation to enable the Confluence-JIRA link in the logo.	JIRA Admin | Groups or Global Users
2	JIRA Single Project Read Only Access	Add the user to the individual Users role on the project - gives Vote and Watch rights.	JIRA Project Admin | Roles
3	JIRA Single Project Read Write Access	Add the user to the individual Developers role on the project - gives all non-admin rights.	JIRA Project Admin | Roles
4	Confluence Single Project Read Only Access	Add the user to the Confluence individual users with "can use" rights.	Confluence Admin | Global Admin
5	Confluence Single Project Read Write Access	Add the user to the Confluence individual users with "can use" rights. In Project Permissions check Add Page, Blog, Comment, and Attachment. (Or other rights as desired.)	Confluence Admin | Global Admin Space Admin | Permissions
6	Confluence/JIRA Read Only Access	Combo of Number 2 and 4 above.
7	Confluence/JIRA Read Write Access	Combo of Number 3 and 5 above.

[Jim Lynch]

One warning - do you have the ability to switch between JIRA and Confluence by clicking the icon for the project? (The icon will get a little "i" in the upper left when you hover over it.) I folowed a similar path to what you are doing and broke that feature. It seems to rely on the Developer and User groups to exist and have their default function.

I got help from atlassian to fix what I broke (JST-64487), and now after new project creation I just remove the Users group from the Role of User in the Groups area (so that people that are supposed to be limited to a single project don't see the newly created one).

[Robert Meador]

@[deleted] Lynch - did you manage to restore the ability to switch between JIRA and Confluence by clicking the icon? Does it still work with the newly launched version? I would love to get this back - it was so convenient.

I cannot fathom why Atlassian would intentionally remove this very useful feature - the ability to switch between linked JIRA and Confluence spaces without having to set anything up. Useful, simple, unobtrusive - why spend developer hours removing that feature? Hmm - maybe they thought JIRA was starting to get too easy to use... nah, that couldn't be it.

[Tin Le]

I'm having the same issue if you set their project to only 1 project they have access to all project.

[Tin Le]

I'm having the same issue if you set their project to only 1 project they have access to all project.