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

1 vote
Accepted answer

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.

0 votes

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
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,101 views 4 9
Read article

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