let me explain my requirement. I need to create issues in some projects, and add subtasks to it. But I need to restrict people able to see the subtasks (eg. some subtasks have to be processed by a team of my organisation, while others subtasks have to be treated by another team, and each team should not be able to view tasks assigned to others. Subtasks will contains quite sensitive data, and our internal policy tells us not to let people view informations they are not supposed to).
And to make it harder, I need to prevent the parent issue to be closed unless every subtasks are closed (for this, I may use the "Sub-Task Blocking Condition" feature).
Linking issues between projects is not a very good option (it doesn't reflect very well that something is a child of something else, and will prevent the use of the Sub-Task Blocking Condition...)
Is it possible, say, to create several subtasks type and grant access to them depending to a role? I searched for that a bit, but didn't found anything... this would be definitely one of the best solutions...
Have you any (good :-)) idea to make this work that way? I'm open to any suggestion...
Thanks in advance!
So you might want to look at this plugin if you are making heavy use of subtasks:
This will not solve your security concern though.
As you cannot set issue secutiry by issue type. The only way I can think of (without a plugin) to do issue security is by setting the issue security level when you create the subtask here:
If you want to try something a little hacky check this out:
Hope this helps a little.
thank you for your answer!
But won't the subtask inherit the security level of its parent issue? That is the whole problem... The parent task will be almost public, but its subtasks should have different security configuration. That is:
- Parent Task, public readonly
+-- SubTask1, viewable and editable ONLY by team A
+-- SubTask2, viewable and editable ONLY by team B
+-- SubTask3, viewable and editable ONLY by team C or D
You were talking about plugins? Do you know any that may help to implement this?
One option might be to base permissions on user groups fields in issues. This may require some workflow modifications as well as permissions/notifications.
For example, create a custom field called Active User Groups. In the workflow for parent task types, on creation, set this field to be equal to a user group that has the appropriate permissions based on your setup (normally the default JIRA group everyone is added to when their account is created).
For sub-task types, you can manually add other user groups to this field as needed.
Just make sure you configure your permissions and notification schemes so the 'Active User Groups' field has adequate permissions and notifications for your needs.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
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