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; } } }

Browse Projects permissions

fiorellasantopietro

Hi,

I have a particular issue regarding the Browse Projects Permissions: even if I grant permissions just to a restricted group of users, the ones that couldn't see the project can see the project inside the all project list. Ok. He can't see all issues inside the project

Ok, he is not able to see all issues inside the project, but even the fact that the project appears inside the list bother me a bit.

Do you have any idea of how to manage this issue?

Thanks in advance!

Accepted answers

All comments

Nic Brough -Adaptavist-

You've given this person the right to view the project. So he can see the project. I don't see any problem here.

fiorellasantopietro

Hi Nic,

thanks for your answer. Unfortunately, even if inside the Browse Projects there isn't the group of the A user, he can see the project on the list of "all project types - all categories".

I'd like to hide the project even inside this list. Is there any chance to do this?

Nic Brough -Adaptavist-

Browse projects will only list the projects the user can see.

If you want to hide a project, you need to remove the user's browse access to it. Check the permission scheme for the project and look at who has "browse". You need to make the user *not* match any of the rules in there.

fiorellasantopietro

Hi Nic,

I did it. I set in this way the "browse project permissions", and my user A is not in any of this case.

I tried to re-index all the project but notthing happened.

Do you have any idea?

Thanks in advance,

Fiorella

Anabell Jorge

I have the same issue. I have 100 projects under a Permission Scheme, all of the items have only groups for permission. However, the user (that is not assigned to any group yet) can see the list of projects. I don't want this to happen. Users should only see the projects they have access to. Any thoughts?

Almut Hack

I have the same issue and in my case the reason was this bug:

https://jira.atlassian.com/browse/JRASERVER-37117

David Kott

I just found this problem as well. Thanks for the link to the bug.

erik.norman

The problem might be that you have some remaining default permissions, and since it is enough that ANY OF the permission requirements is met, the user will see that list/resource/issue.

Sadly, there is no built-in step-by-step wizard to set up the permission schemes according to your needs, therefore most Jira enthusiasts start with the default settings, create loads of projects and start worrying about security later.

I don't know what you have done so far, but unless you completely clean up all the permission system, you will never really be in control of "who sees what".

Depending on how many users/groups/projects you have, this "tabula rasa" might take some time once, but save you a lot of headache afterwards. In the end, your users will only see issues/resources/projects, because you explicitly allowed them to.

You will need to do this when nobody is working, since Jira will be partially unusable until you finished the configuration. Do a backup first!

Use two browsers (e.g. I used Chrome as Jira admin, and Firefox as user) to test the permissions while doing this. I use a dummy user whom I temporarily assign to the relevant groups.

Step by step instructions

Remove all users from jira-software-users
Go the default permission scheme and remove all access rights.
Go to System -> Global permissions and remove any non-admin group. Only jira-administrators should be listed for each permission.
Test if your user can login. Expected: he cannot login due to missing access rights. Good! Now we can start building the whole permission system from scratch.
Create users and admin group for a team. E.g. if your team is called bongo: bongo-users, bongo-admins
Add all "bongo team members" to either bongo-users or bongo-admins
Go to Settings -> Applications -> Application access and add bongo-users and bongo-admins
Test if your user can login. Expected: he can login, but he cannot see or create any issues.
Copy the default permission scheme and rename that, e.g. bongo permission scheme
Configure the bongo permission scheme and assign permissions to the bongo-admins and/or bongo-users.
PRO TIP: Rather than adding any "team leaders" to both admin and user multiple groups, assign any "normal" permission to both bongo-users and bongo-admins, and "admin permissions" only to bongo-admins. Typically, the permission scheme is configured only once, but you will have to manage add/remove admins more often.
For all "bongo projects", go to the project details (Settings -> Projects -> click on project -> Permission -> Actions: use another scheme), and assign the bongo permission scheme.
Test if your user can create and view issues within any "bongo project". Expected: yes.
Repeat this for any other team you have, and test if the users can access (only!) their own projects.

Please note:

You will see some error messages and strange behavior, especially in the beginning (e.g. project category undefined in the project details), but that is to be expected. You might want to add your own Jira admin user to those admin and/or user groups to avoid such error messages.
This is by no means a complete guide on user/group access control, it is merely one of several possible solutions. It was made under the assumption, that you want to have two completely separated teams, who don't know of each other. Furthermore, this example was made only with two roles: admins and users. If you want to have further roles and/or cross-team visibility, you will need to add further groups and edit the relevant permission schemes, so that people belonging to these groups have enough access rights to see/edit the data. You can also add more flexibility by assigning permissions to project roles, rather than groups directly.

Welcome!

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

Quick Links

Find more posts tagged with

jira

project

permission