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

Can I restrict access to issues within a Scrum board?

Tim Saunders

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.

Accepted answers

Jobin Kuruvilla [Adaptavist]

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.

All comments

Jobin Kuruvilla [Adaptavist]

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.

Ignacio Pulgar

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.

Tim Saunders

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?

Jobin Kuruvilla [Adaptavist]

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.

Welcome!

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

Quick Links

Find more posts tagged with

jira

board