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.
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.
As an alternative to using Issue Security Levels, you may create one scrum board for each of those groups of users.
Each board should:
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:
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 ...
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!
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