Hi everyone.
I would like preventing users from select a project (in which they have no permissions) in the project selection dropdown list at "Search for Issues" navigator.
Any help would be appreciated.
Best regards and thank you in advance.
Javier.
Hi everyone.
It seemed to be an strange internal problem.
I have restored a PROD backup into TEST environment (to have a fully functional TEST system) and now it works properly.
Thank you everyone for your help.
Best regards,
Javier.
Hi Javier,
From the described behavior, I believe that the 'restricted' users may have the Browse Projects permission in the permission schemes associated to those projects. Hence, can you kindly check the related permission scheme configuration, look for the Browse Projects permission and see if this the case? If this is true, then you may restrict the list of projects from the users in question by limiting the Browse Projects permisison.
I hope that this will help!
Cheers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Ahmad, for your fast answer.
I have checked that before and the user is not included in the groups that have permissions for "Browse Projects".
The user cannot create issues for the other projects, but he can select a different project in the dropdown list in "Search for Issues" section.
:(
Thank you, Ahmad.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What about roles or the other options?
I agree with Ahmad here, if you have a user who can see a project, then they have "browse" permission somehow.
The usual culprit is the Atlassian default - "jira users" is used to say "people in this group can log in", but then also used to provide access to projects, which you'll need to unravel. There are some other gotchas in this area too.
Anyway to diagnose this exact problem, could you post the whole "browse" line from the permissions for one of the projects that someone can see when they shouldn't.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok, good start, but there's more.
Your screenshots show pherro (I assume that's user who shouldn't be seeing stuff) and their groups. It shows that you are not using any groups pherro is in directly, and that you are mostly using roles to control acces
What we don't know is what roles pherro is in, and it leaves us with three more things to ask:
(You can answer the second and third question by clicking on the "roles" link next to pherro)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok, I am goint to do both actions.
I will send shortly some screenshots about it.
Thank you for your help.
Javier.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi everyone.
It seemed to be an strange internal problem.
I have restored a PROD backup into TEST environment (to have a fully functional TEST system) and now it works properly.
Thank you everyone for your help.
Best regards,
Javier.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.