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

How to limit issue visibility by issue type

unknown

We have a JIRA project containing issues of types Bug, NFS and Task. We want to make only the bug issues (from all reporters) visible to our client (non-developer) users. It looks as if Issue Security might help here, but how?

We also have the Greenhopper plugin installed. How do we remove visibility of the Kanban/Scrum boards from our client users while still allowing them to browse all bug issues ?

Thanks in anticipation

Accepted answers

Dave C

Hey Richard,

I'd suggest Configuring Issue-Level Security for that project and set a default so that only developers can view those issues. This means all issues created by default will not be able to viewed by anyone except developers. Then what you can do is add a post-function using a Groovy Script (Script Runner can execute this) to set a different issue security level for bugs. Onresolve have some further information on this on one of their blog posts, setting issue security level by issue type - please take a look through it for further info.

In order to restrict access to the GreenHopper boards, you could edit the default permissions on the filters that board uses, so that only developers could view them. By default GreenHopper will create a filter and provide permissions to the projects that use it, to fix this remove those projects and apply the Group: jira-developers permission.This will prevent all users without that permission from viewing the board. Provided that no one modifies the permissions on that filter, your users will be able to view bugs however not view your GreenHopper boards.

All comments

Jobin Kuruvilla [Adaptavist]

Yes, issue security schemes can help. Create security levels where the clients are not part of and then assign it to the issues of other types.

Maybe you can set it by default in the workflow post function of the other types, just to make sure the field is nt left empty!

unknown

Jobin

Thanks for that. How do I "set it (the security level) in the workflow post function" ? (We are new to JIRA and I don't know how to set up a post function).

Thanks

Jobin Kuruvilla [Adaptavist]

https://confluence.atlassian.com/display/JIRA/Configuring+Workflow#ConfiguringWorkflow-Usingapostfunctiontosetafield

But seems security level is not in the list. You might want to write a new plugin. JMWE plugin has a built in post function that sets security level based on project role. Might help!

unknown

OK, I looked at the source for SetIssueSecurityFromRoleFunction and unless someone has a better idea as to how I can address our root issue (i.e. hide Improvements and Tasks from non-developers) then it seems that I'll have to get a developer to create a plugin which has a SetIssueSecurityFromIssueType function.

Help, anyone ?

Dave C

Hey Richard,

unknown

David

Thanks, but it's not clear to me what steps are required to " to fix this remove those projects and apply the Group: jira-developers permission" .... can you please expand on this ?

Thanks ... Richard

Dave C

Hey, you can edit the filter permissions with:

Issues > Manage Filters > Search > Click on the name of the filter > Rename or Share > Trash the current shares > Add new shares for the appropriate group

This will then restrict that filter's visibility to users of that group. This is a workaround and is using GreenHopper and the JIRA filters in a way they weren't originally designed for, however it will work.

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-software