nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

Justin Alex Paramanandan

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:

Remove him from all the roles (we'll come back to this later).
Delete the permission scheme you just created recently.
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)?
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.
Create a new group, and set this group to the JIRA Users global permission. This would allow him to login and logout.
Create a new permission scheme, and set this new group to the Browse Projects permission.
Ammend other permissions in this new scheme (such as adding developers and other users; do this via groups).
Associate this new permission scheme to the said project.
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.

All comments

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

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.

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.

Justin Alex Paramanandan

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:

Remove him from all the roles (we'll come back to this later).
Delete the permission scheme you just created recently.
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)?
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.
Create a new group, and set this group to the JIRA Users global permission. This would allow him to login and logout.
Create a new permission scheme, and set this new group to the Browse Projects permission.
Ammend other permissions in this new scheme (such as adding developers and other users; do this via groups).
Associate this new permission scheme to the said project.
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.

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.

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.

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

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

David Triebwass

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.

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.

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.

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.

Thomas Talinski

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

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.

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:

Create a user(s) for your client
Create a new group for them (no permissions to start)
Assign the user(s) to the new group
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:

Under "Roles" add the group to the Clients and Users roles (you can hone that later)
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

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

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

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

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

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.

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?

MikeS_45qqk6

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.

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.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud