How to restrict users to view only the issues assigned to them

Hiren Trivedi August 17, 2015

We are using JIRA Agile. There are user stories/projects getting created and assigned to Backlogs. We want to restrict the backlog from visible to all the users.  Only when we prioritize the story/project and get assigned to user/group, then they should be able to view the story/project assigned to the user/group. The user/group should not be able to view the story/project assigned to other users or group. 

I tried to set the security level. But not clear how to achieve the requirement. The backlog is visible to all the users belong to "jira-users" group.  If I remove the user from "Jira-User" group, then they don't have access to the AGILE project. 

2 answers

5 votes
Pilar
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 17, 2015

What you can do is

  1. create a issue security scheme with level which gives access to assignee and reporter and another group which decides on the the backlog say Change control board.

2. Now you set this as the default security level and you may as well hide this level from the screen.

3. Make the security level field mandatory (to avoid users bypassing it using None)

4. Apply the security level to your project

5. Migrate all existing issues to this level.

This should resolve your problem. With this security level only the assignee, reporter and the CCB group gets access to your issue. Moment the CCB decides to assign it to an individual he automatically gets access to the issue.

For how to set up Issue security scheme here is the link

https://confluence.atlassian.com/display/JIRA/Configuring+Issue-level+Security

Pilar

setempler February 15, 2018

Works as expected, thanks!

I used

* level Managers (group:managers)

* level Assignee (group:managers + role:assignee)

2 votes
William Crighton _CCC_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 17, 2015

@Hiren Trivedi -

So - jira-users is an overloaded group and you'd do best not using it all-together (imsho). What I mean by that is it's a default group that's in your global permissions JIRA Users setting, which means that every user you add to your system is automatically added to this group because they have to be a member to be able to login to the system. However, it's also in the default roles for every project - which means that not only have you granted this new user access to your JIRA system, you've (by default) granted them access to every project in your JIRA system. That's what I mean by it's an 'overloaded' group and you'd do best by not using it. I like using a group like 'jira-access' which is the only group in the Global Permissions JIRA Users setting and I make sure that 'jira-access' is never referenced by any role or project. It adds a tiny bit of extra work on your admins when they create a new user but it makes up for it in added/simplified security (users are not - by default - granted access to any projects when you create them. You have to explicitly add a user to different groups (jira-users works here, just not if you leave it in the Global Permission JIRA Users setting) in order for them to see projects.

ok...because I'm sure somebody else is going to say 'huh?' when they read your question I have to join in the chant with how much I don't understand why you'd want to do what you state you want to do - 'hide the unscheduled backlog' - it doesn't make sense to me - but I don't know your use case, and you might have a perfectly reasonable reason to desire your goal and just because I haven't run into such a reason yet doesn't mean it's not reasonable given your situation.

The main problem I see with what you're trying to achieve is that it'll involve a lot of extra maintenance work on top of what I can only fear is a overly-stressed scrum management group (which might have led to the whole 'lets hide it then!' as a solution). Setting the security level IS the way to achieve your goal, but honestly it's a pain and is not something you'll have much luck delegating away. One main reason for this is in order to set a security level on an issue the user setting the security level must be able to view issues with that security level. So, this means that if you create a security level called ... say ... 'hide the backlog' then in order to set (or clear) that value on any issue the user has to have the privilege to view the hidden backlog.

but, ok, past that...all you want to do is create a new group called something like 'view hidden backlog', a security level called 'backlog visibility control' with at least 2 levels in it - a level that indicates the issue has been prioritized/scheduled ('1 - visible to users/developers') and another that indicates the issue is hidden ('2 - invisible to busybodies'). I like numbering the security levels so they show up in the order that makes sense. You'd want to add jira-users, jira-developers and jira-administrators to the first level and then jira-administrators and your new group 'view hidden backlog' to the second level.

After that you'd need to add folks to the new group 'view hidden backlog' so someone can see the thing and get the issues prioritized as well as set the issue security level thing on the project - you should set the default level to 2, and know that after you set the security level on the project NOBODY (except admins and the members of your new group) will be able to see any issues in the project, and after you prioritize each issue you'll need to go in an modify the security level to allow the users/developers to see it (until you realize you have to automate such a beast to keep from driving yourself silly with all the pointing and clicking, opening up issues and setting issue security level.

 

Note: you could do this with a single security level and then just clear it when you've set the priority on the issue - which might be a bit easier to automate - but I like the extra named security level because it adds clarity into what you're trying to do...sorta.

 

Hope that helps some

-wc

Suggest an answer

Log in or Sign up to answer