Users seeing all projects when creating issues

When my users create an issue, the Project drop down menu on the Create Issue page shows all projects instead of just the projects they are assigned to. I want to change this behavior so that the only option they have is/are their project(s).

I have created group roles using the following template:


AgencyName-ProjectName-Developers, etc., etc.

I have added the users to the appropriate groups and assigned the groups to the appropriate group roles. I then created a custom Permissions Scheme and added the groups to the scheme in the appropriate places. 

The groups have been added to global permissions.

I am unsure of what else to do. When doing a search I found one answer to this question from 2012 but the directions in the answer didn't match my screens so I assume that things have changed a lot since 2012.

2 answers

1 vote

Look closely at the "create" permission in the scheme for the projects.  The users are getting the projects in the drop down for all projects that they could create issues in.

Generally, you want to avoid using groups in schemes, your description seems to be that you're granting permissions twice and that's a bit of overkill.  Let's say you have roles of Users, Developers and Admins.  Grant all  those roles "Create", but don't put the groups in the permission scheme.  Just add the group to the project role when you need that group to create issues in that project.

Thank you for your help. Sorry for the delay in answering. I work for a state and JIRA is used by different agencies in the the state, each with their own JIRA admin under a centralized JIRA System admin group. The way they want us to handle roles and permissions is to create groups, add users to the groups (both via AD), and add those groups to the various roles. Then in the permission scheme, add both the project roles and the group roles. I agree that it seems like duplicating work but that's what they want.

Are you saying that if the JIRA admins in these other agencies do not lock down their projects then my users are going to see their projects and there's nothing I can do about it or am I misunderstanding?

Yes, that's correct, if your admins are demanding to do things that way, they're wrong, and you can't do what you need to.

Frankly, they need to stop being silly and stop using groups in permission schemes.  It's not the only solution to your problem, but it is the best, and none of the others are going to work until they stop it either.

So, just to make sure I understand (I'm going to address the issue), the proper way would be to create the groups and users in AD as we have been doing, add the users to the groups we want them to be in, then add those groups in the roles we want them in. In the Permission screen we just need to use the project roles and NOT the custom groups because we are just duplicating the process.

Also, as a test, yesterday I removed all of the custom groups from the permission scheme (kept them in the roles) but it didn't make a difference. User can still see everyone's projects. The groups I have them in are unique and are not used by any other project. It seems illogical to be affected like this by the actions of JIRA admins in other agencies.

Once you've got the groups removed from the permission schemes, you should find it is a bit easier.

Have a look at the permission scheme line that says "browse".  Hopefully, it should now say something simple like "Role developer + Role User".  Now go to the project roles and look for any group (and user) in either of those roles.  Remove the ones who should not have access to the project.

I went into project roles and ensured that the only groups assigned were the ones created for the project. There are no individuals in roles at all. In the browse category I have nothing but the project roles: Project Role(Administrators), Project Role(Developers), etc.

The users still see a complete list of projects. I removed all Project Roles from Browse permission just to see what would happen but all that did was remove the dashboard for the project. 


So, let me get this straight.  If you remove ALL the groups from a role that allows "browse", then your users can still see the project?

If that's true, you've got a hacked JIRA - someone has removed the permission setups.

No, they cannot see their project anymore in the Projects drop down menu on the nav bar and if they click all projects their project is not there. However, when they click Create, their project and all the others are still there. We're making progress though. Now all I have to do is get it flipped around smile

Ah, ok, that's good, no hacks.  The next thing is to work through the groups with the "create" permission then. 

I removed all groups from the Create Issues permission. That removed their project as an option but all the rest of the projects are still there.

I verified that the permission scheme is only assigned to one project

Yes, you'll need to go through all the projects and revise their schemes and roles to ensure the right people can do the right things.  One of the reasons for sticking to groups going into roles is that you can re-use a standard permission scheme for most or all projects.

The problem is that all of projects that can be seen belong to agencies across the state and I have no way of revising their schemes and roles. Looks like I'll have to get the SysAdmins involved since I have no idea who their JIRA admins are or how to get in touch with them,  

What I don't understand is that I've verified that none of my users or groups are in projects outside of our agency. Since some of them are in multiple projects inside the agency it makes sense that they could see other in-agency projects that they are assigned to. What doesn't make sense to me though is that our projects can be so negatively affected by issues outside of my control.

Thank you for your help in troubleshooting this problem.

I'd say that the users with unwanted access are simply in groups that have been unnecessarily added to permission schemes and/or roles that they should not be in. 

But user management would show that wouldn't it? If I type in a users name and leave groups as ANY it lists all of the groups he's in as well as the roles he has in all the projects he's in. I've already been through all of the users and no one is in a group or project outside of our agency.

Something I did notice and I don't know if it's right or wrong. If I go to User management/Groups, it lists all of the groups throughout the State in JIRA. If I click on one of my groups all of the schemes its associated with. Mine all say there are no Permission Schemes associated with this group.

Since I added the groups to the Roles instead of the Permissions scheme, I assume it's supposed to be this way?

It will, yes, but there's one other thing - if someone has used "anyone" in the permission scheme, then that opens it up to, well, anyone.  Can you check the permission schemes for that?

I'll do my best. Thanks

I have the same problem. I have 3 projects that have a specific permission scheme applied.

Any newly created user, in a newly created group can list these 3 projects, but only list them. When users click the project name, no issues will be listed and the Permission helper can confirm that users has no access to the issues under these 3 projects.

However the project names are still listed.

Let's assume that JIRA has bugs and locked-in states, like deleted user groups that cannot be deleted from project roles.

There is a permission - Any logged in user - that allows everyone to access a certain permission, because everyone is logged in and we have used this permission once in this permission scheme, but later deleted it. Isn't is possible that a permission scheme has old, although deleted elements that are still active?

The Permission helper is not able to check for project listing permission, it needs an issue name to check for permission.

See the permission scheme for the other projects the clients are able to see.

In that for creating an issue- remove any logged in user option and change into jira_user group and make sure that the clients are not in that group.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Oct 09, 2018 in Jira Core

How to manage many similar workflows?

I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...

369 views 6 0
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