Client can see all other projects of the company

[Kseniya Zhukova]

Good day. We have a next-gen project in Jira, and client at this project can see all our other projects.

How can we restrict his access? 

[Tessa Tuteleers]

Hi @Kseniya Zhukova , 

Welcome to the community! 

Can they see the list of projects in the overview, but not the project itself? In any case, this will be linked to the browse project permission of the shown projects, assuming you're not on a free plan where there are no project permissions to speak of. 

If they can only see the list of projects (or certain projects), it could be that you have project permissions with browse project rights based on a custom field. 

To explain, if you add a user custom field to the browse project permission, all users that can possibly be entered in that custom field, get that project in their project overview, because it is possible they can see issues in that project. 

If they can see the project and everything in it, there will possibly be a group in the browse project permission that should not be there. 

You can find the information about this here.

Please provide more information about your permission schemes if this answer did not help. 

- Tessa

[Kseniya Zhukova]

Most of our projects are classic and on default permission scheme (all logged in users can browse)
But the client is on next-gen project with jira software access. 

And he can see the list of all projects in search, because he is a logged in person

What can we change in terms of the client or the project

[Walter Buggenhout]

Hi @Kseniya Zhukova,

You put your finger right on the sore spot there. All logged in users can browse is the cause that anyone who logs into your Jira instance has access to the projects using the default permission scheme. Including your client, regardless of the fact that you want him/her to use the next-gen project.

There is no other way than to get rid of the all logged in users can browse in your default permission scheme and replace it with - ideally - project roles.

Be careful though, as this change may have a big impact on your internal projects. Have a good look first at how your internal users are assigned permissions in those projects, so you can make sure they will still be able to access their projects after the change.

May I recommend you first create a copy of the default permission scheme, remove the all logged in users everywhere in the copy of the scheme and replace it with project roles (users, developers, administrators - the ones you use internally). When you are done, associate your new permission scheme with one of the projects currently using the default scheme and have your users test their permissions. If that goes well, replace the permission scheme on all the other projects as well (or update the default permission scheme in the same way as you did in the copy - depends a bit how many projects you need to update).

All technical steps are described in the article Tessa linked before.