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

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.

11 answers

1 accepted

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.

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.


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.


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.

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

how can you even add a group to a global permission 

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.

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 or maybe something else. 

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.

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.

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

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.

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.  

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


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

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.

Mike you are so on the money. I have billable work to do vs learn specifics of the Jira permission system to add one external client to one of my projects. It's an email address field and an 'invite to this project only button' ... why am I doing Jira's work? Jira Fail, partner-champion-ignore-great-feedback fail. Any advice on other simple products that got this right? Or it's back to google docs.

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.

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

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.

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?" 

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

Nic: Your title and your comment "we're not ignoring feedback" made me assume you were an employee of Atlassian.  Frankly it would be nice to have an employee here; that is one thing I notice that Atlassian is bad about it staffing their forums with official people who can interact with their customers.

And your follow up comments make exactly the points I've been trying to make:

There are complexities (took me a while to get my head around roles), and the defaults are poor

Yes the amateur chef is happy to go to Whole Foods and spend a significant amount of time (learning how to) prepare a descent meal, but most people are happier to just go to a restaurant or by a pre-packed meal kit so they can focus on other things beside mastering the skill of preparing a great meal.

Same here. Most people don't have the time or the patience to spend significant time learning a complex tool to help them do what it is they actually want to do.

get more simple without losing the flexibility a lot of Jira clients need.

Absolutely untrue. There is no reason an additional simplified interface would require the change or elimination of the current "power user" interfaces.

but I'd struggle to make it more simple that what is already there.  

Ironically, I would not. I could easily design an easier interface than currently exists (as a web developer that is what I already do.)

Listen I respect that you have expertise here, and that expertise is valuable to you and whoever you work with. But please also respect that many other people have real legitimate struggles with JIRA's interfaces and no amount of exclamations from you that "it is not complex" will eliminate that complexity for most of us.

Thank you Mike [Client Champion] Schinkel for stepping out of 2016 retirement to command the tank of great user experience over the barbed wire of technical intransigence.

Nic, if you're not an employee, you might want to defect on this specific hill. Even if we don't win there's sweet solace in being blissfully correct.

Shame as the solution really is so easy, just a one page wizard. But the big brass, sipping tea and brushing cake crumbs off their jackets far behind enemy lines, presumably have better things to do than worry about us boys out here.

Thank you Mike [Client Champion] Schinkel for stepping out of 2016 retirement to command the tank of great user experience over the barbed wire of technical intransigence.

Nic, if you're not an employee, you might want to defect on this specific hill. Even if we don't win there's sweet solace in being blissfully correct.

Shame as the solution really is so easy, just a one page wizard. But the big brass, sipping tea and brushing cake crumbs off their jackets far behind enemy lines, presumably have better things to do than worry about us boys out here.

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. :(


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

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.

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

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!


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.

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

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

0 votes

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.

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.


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.

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.

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"?

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!

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?

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

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.

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?

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.

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.

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.

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 :(

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.

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? :)

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

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.

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. :(

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.

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 :(

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.

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:

  1. Removing users group from projects is needed to hide projects from clients.
  2. 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.

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

@jim 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.

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?

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


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.

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.

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

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 Community Champion Sep 19, 2017

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. 

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 Community Champion Sep 19, 2017

Glad it worked

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,026 views 12 18
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot