Can you restrict a group of users to only access their sub tasks?

Emma Kershaw January 6, 2020

Hello, 

We have a slightly complicated workflow requirement for Jira service desk where if a ticket is escalated to a stage 2, it will automatically create a sub-task and the group of people we want to assign the sub-tasks to, we don't want to have access to the main ticket ideally or at the very least the wider service desk.

Is this possible?  Maybe by putting their group in a service desk role and setting something in the permission scheme for that group?  I can see options like "edit own comments" and "delete own attachments" we could assign them to as well as not putting them in "browse projects" but can't see an option like "view/edit own issues"  Maybe something with "set security level" would be useful?

Or maybe we could add them as collaborators so they can upload attachments and add internal comments and add their collaborator group to the Transition Issues permission on the permission scheme?

All ideas gratefully received.

Thanks

Emma

1 answer

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 6, 2020

No, the visibility of a sub-task is determined by the visibility of its parent issue.  You can't hide a sub-task without hiding its parents (and all its siblings).

With some trickery in the workflow, you can make the parent task totally unchangable while allowing full access to its sub-tasks (or vice-versa).

(Actually, there are two fiddles that let you do this, but they break all sorts of things in some very painful ways, and it's not worth the effort, as you can't fix the problems it causes)

Emma Kershaw January 6, 2020

Ok thanks Nic.  

Accept we might not be able to restrict separating the sub task from the parent but can't we at least stop them viewing other parent tickets not related to theirs?

Seems like maybe with something like the security permission - https://confluence.atlassian.com/adminjiracloud/configuring-issue-level-security-776636711.html ?

Am I also correct to suggest we could also manage their access to other tickets by making them collaborators on their tickets?

Cheers

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 6, 2020

No, the "issue level security" is the thing that is done at parent level.

You will have to handle visibility of the issues with it on that level, not the sub-tasks.  But you can set issue security such that "group A can see issues in level 1, group B can see level 2, group C can see both, and group D, none"

Issue security does allow you to use user fields in it, so you can make it variable too (for example, group B, the assignee and the person named in custom field X can see this)

Emma Kershaw January 8, 2020

Ok thanks Nic, so sounds like we can restrict their access to the wider service desk at least by setting the security at parent level.  The examples are helpful but I don't quite follow what you mean by level?

Also in your 2nd example if we said group B as an asignee could only see the 2nd level (if this is a sub task), wouldn't that achieve it?

Cheers

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 9, 2020

Sorry.  "Level" is one of the phrases used in the Jira code to describe the "Security level" field. 

Issue security works by setting a field called "Security Level", sometimes seen as just "Level", on a parent issue (it will not appear on sub-tasks).  It's a single select list, and each option on that list can have a different set of restrictions on it.  So you can do stuff like

  • Top Secret - only group A can see this
  • Secret - group A and role B can see this
  • Private - group A, role B and people named in custom field C can see this

If you leave the level blank, anyone with "browse project" permission for the project can see them.

As I said before, sub-tasks inherit the security level of their parent.  So no, absolutely not.  A person can see an issue and all of its sub-tasks, or they can see none of it at all.

Jeff Gordon June 28, 2023

Perhaps this has changed since this post but you can definitely restrict visibility to Sub-tasks independent of their parent.  If the configuration of the Security Level includes a user field, a particular user who cannot see the parent issue otherwise would be able to see it if their user id is in that user field.  But they would not be able to see a Sub-task unless their user id was also in that field on the Sub-task since the Sub-tasks inherits, and honors, the configuration of the Security Level on its parent.

But it is still the case that if you don't have access to the parent, you cannot access any of the Sub-tasks.  

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 28, 2023

It does not work that way, you can put what fields you like on the sub-task and include them in the security level, but Jira still looks at the security of the parent issue to see if someone can see the issue.

Jeff Gordon June 29, 2023

Ordinarily Nic you are the last person I would challenge regarding Jira functionality.  However, I tested this in our 8.20 Data Center instance and that's how it works.

The person may be able to see the parent because their id is in a user field that is part of the security level definition.  But they will only see the sub-task(s) where their id is also in the field on those as well.

Suggest an answer

Log in or Sign up to answer