Can I restrict access to issues within a Scrum board?

I have a user group that has issues that affect several different areas of the business in their project. They would like to give business users access to their scrum board so they can follow the progress of issues relevant to them but do not want the business viewing issues that are outside their silo. Internally they use quick filters on labels and components to switch from one group's issues to another.

Is there any way to restrict user access to issues based on these existing labels and/or components? The only way I've found so far is the use Issue Level Security but I was hoping there was an easier way, like forcing users in a certain group into viewing the board with a specific filter applied.

2 answers

1 accepted

This widget could not be displayed.

Filter visibility controls who can see the board. Once a user can see the board, you will need to use issue security levels to hide specific issues on the board.

Thanks Jobin. I've managed to get Issue Security set up and working but I've run into an unexpected problem: some issues are in more than 1 silo. For example, there is an issue that belongs to both the Sales and Marketing groups. Assigning a single Issue Security Level (e.g. "Sales" OR "Marketing") would preclude one group from seeing the issue; this is why I originally hoped to use the Component field since there are multiple values there already populated.

The only way I could think of making this work with Issue Security would be to create hybrid Security Levels (e.g. "Sales/Marketing") but that could easily lead to hundreds of levels depending on how they classify the issues.

Any other ideas how I can make this work?

Unfortunately, you have to do it somewhere.

One option is to create different security levels for the hybrids, as you suggested. Another is to create groups for those possibilities (cross team access) and then use those groups in the existing security levels.

Latter might be better because you can then use those groups elsewhere as well, like permission schemes or workflows, if needed.

This widget could not be displayed.

As an alternative to using Issue Security Levels, you may create one scrum board for each of those groups of users.

Each board should:

  • be shared just with that group of users,
  • have a filter with the appropriate combination of labels an components to filter out the issues that are not of their interest.

Note that this approach allows filtering, but doesn't provide security, so all users with Browse Projects permission in that project could potentially see all issues in that project.

If users shouldn't be able to see issues from other departments for security reasons, then another alternative to security levels would be:

  • create one project for each of said groups/departments and grant Browse Projects permission just to the relevant users,
  • move the issues from the original project to the appropriate department project,
  • change the board's filter so that it includes issues from all those new projects.

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Wednesday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

286 views 5 0
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you