Extending access rights for Jira issues

[Curtis Carmichael]

Initially, we wanted non-engineering people to have access to be able to raise new issues (Bugs and Enhancements only) in a “Global Issue Tracking” Jira project only. Thus they should have no other access rights to the other Jira projects.

However, because of the way we move issues around the projects to fix them, it means that non engineering people can’t search and see the status of the bugs they or others raised.

One way we may be able to fix this is to extend the minimum access rights to include the following:

• Be able to search and view issues (Bugs and Enhancements only) on all projects (not just “Global Issue Tracking).
• Be able to add comments on issues (bugs and Enhancements Only). They should not be able to delete or edit, just add comments.

I was curious how we might be able to go about doing this in Jira?

[Nic Brough -Adaptavist-]

Actually, no, moving Jira issues around is not "bad", it's simply one way to do it. Issue linking can be just as "bad" because you can end up having disparate data on separate issues. Many places use a mix of both.

However you approach this one though, you can't do "view/edit/comment" by issue type. That is done at a *project* level by the permission schemes, so when you say "person A can see issues in project X", then they get to see all of them. Similarly with edit, comment, and so-on, it won't look at the issue types.

There is a workaround for some of us - you can use "issue security" to hide issues. To do it automatically, you need a plugin to set the security automatically as the issue goes into a status where it should be hidden (which you can't do in OnDemand). For this trick, it's irrelevant whether you move issues or use linking.

Another trick would be to enable the "reporter browse" permission - that allows you to include the reporter as someone who can see an issue without giving them access to the other issues in the project. Atlassian themselves use it on their support Jira (when I raise issues in there, I can only see mine, and ones other people explicitly include me in). I think that would mostly solve your problem, combined with your current practice of moving issues, but I do not know if that is available in OnDemand.

[Curtis Carmichael]

Thanks Nic. Do you recall where the "reporter browse" permission can be set up in your version of Jira?

[Nic Brough -Adaptavist-]

Yup - https://confluence.atlassian.com/display/JIRA/Current+Reporter+Browse+Project+Permission

It's been there since at least 3.6, and probably earlier. Take heed of the warning box - the looping is not fun to break out of

[Curtis Carmichael]

Thanks. Is there another way I can do this without risking the infinite loop?

[Nic Brough -Adaptavist-]

No, you need to educate your administrators to be careful when they are creating/editing permission schemes

Most of the time, it won't loop though, just do nothing.

[Florin Manaila]

Moving issues around in JIRA from one project to another is bad. The overhead needed to do that can quickly become overwhelming for your instance and you'll notice that as your userbase grows. I would recommend leaving the issues in the "Global Issue Tracking" and use issue links to delegate to other projects. This will also fix the permission problem you have.

HTH

[Curtis Carmichael]

Thanks for your suggestion. Can you share how I can set up issue links and setting up the permissions I need with those issue links?

[Nic Brough -Adaptavist-]

With issue links, it's Admin -> Linking - you should be able to enable it there, and maintain your link types.