Just now discovered. Note: running Jira Server 6.2 (I know, old)
tl;dr Create task as regular, non-sub-task level, then do "convert to subtask". Epic Link will remain populated.
I have tasks/stories with subtasks and just noticed some of those subtasks do have the "Epic Link" field populated, and so show in filters for "Epic Link = ....", which is very nice.
Looking at their history it's because they were created as regular issues, then moved to be subtasks, or "convert to subtask".
So, not great, but a workaround to populate the "Epic Link" field for use in filters and the like.
Edit: unfortunately this doesn't work. Just did it but the Epic Link field did not remain populated. Other sub-tasks do still have it populated but I have no idea why. It may be the field is available on a bulk transition out of the initial creation state, in our case from "Submitted" -> "Assigned", and that transition opens basically an edit issue dialog. But this is only a guess and I have no good way to test right now. Sorry for false hope. :(
I had a similar issue for my filters where sub-tasks doesn't appear.
I had to workaround by linking manually the sub-task to the Epic by any link type like "is part of" or "relates to". Then adapt the filter to display the issues which are linked to Epic.
issue in linkedIssues( epicIssue )
Then we can see sub tasks
But I also prefer if Atlassian can automatically inherit the epic link for sub-task from its parent.
Thanks for the quick reply Thomas.
I looked through that thread, and what I understood from it is that Atlassian decided that it's not appropriate/important to include sub-tasks on my Kanban board (and therefore you can't assign epics to subtasks - and they don't even inherit the parent's epic). Is that correct?
I'm not sure I am applying what I read there correctly to my question, so if you could please confirm...
If that is the response, I have some trouble understanding why the tool would want to force me to work in a way that I don't find useful for my personal workflow.
That is correct - subtasks are useless in Scrum planning and just waste space and make noise.
A subtask always belongs to its parent, and that parent can have an Epic, which then implies that the sub-task is inside that Epic. But there's an oversight in that the subtasks don't actually inherit the information internally.
There are open issues which Atlassian have accepted to get this design flaw fixed.
Sadly an "if" in the Atlassian ecosystem is "as long as a piece of string". It took over a decade to get JRA-9 dealt with, and we still don't have "priority schemes", but other things that are just as useful have taken only a couple of weeks to get done. I can't speak for when or even if, on Atlassian's behalf, just say "they've not said 'no'".
OK thanks for the clarification and the quick response Nic.
In that case, any ideas for a quick work-around in the remaining 10 years until this is addressed?
Again, the situation is that I have a "Board" ("Rapidboard"?) that is defined by a specific query. One of the things that the query looks for is Issues that have 1 of 2 specific Epic Links. Since subtasks are not assigned an Epic Link, there are often subtasks that should be on my board but they are not. (And since the parent of such subtasks are not necessarily within the query due to having a different status or assignee than the subtask, I don't see them either - they are not meant to show up.)
So how do I keep these subtasks on my radar (include them on my board)?
I don't think you can, although there is a big problem with one of your assumptions - a subtask is part of its parent, so even if you could do "show epic and all its issues", then your subtasks should be on there only if their parent issue is. If their parent is not in the Epic, then neither are they.
Maybe I didn't explain myself well. I do want the subtask to inherit the epic from its parent.
What I am unable to do now is the following:
Let's say that parent issue 'A' has an epic called 'monetization'.
'A' has a subtask called 'A1'.
A is in status 'Open', and 'A1' is in status 'Resolved'.
On my Kanban board I am filtering for all issues in the Epic 'monetization' that have the status 'Resolved'. I would like 'A1' to show up on this board - how can I do that?
@yair: You can configure your kanban board at ease to list issues with subtasks. Clicking on configure at top right corner of your board's dropdown, you could find columns tab where you have a field called "column constraints", where you can select issue count with or without subtasks.
Note: You should be an board administrator to configure columns.
Hope it meets your requirement :)
Thank you Avanthu, however this is not going to fix the problem that I have. In my case (explained above) the parent issue does not match the filter for my board, so the parent issue is not going to show up on my board, so neither will the subtask. The only way that the subtask would appear on my board is if the subtask itself matches my query, and since subtasks cannot have Epics, it will not.
I have worked around this by fundamentally changing how I build my board queries. I have created a custom field called "Assigned Team" that is the flag for including issues in a scrum board. If you have purchased Atlassian Portfolio then you could just use the Team function.
Once that is set up, I have a "Copy value from other field" post-function on my Create transition for all sub-tasks that take the "Assigned Team" value from the parent and set it for the newly created subtask. This ensures that all subtasks created for a story in a team's backlog/sprint show up in the Active Sprint board.
One pain point for me, is that because subtasks cannot have Epic Links, when you "Convert Issue" of a subtask to be an independent issue, it doesn't inherit the Epic Link of it's parent and hence you might lose issues that would otherwise be able to the tracked to the Epic.
There is a workaround I've used on Server editions of JIRA, and I think you can get close to it on Cloud.
With the Script Runner add-on, create a scripted field, or populate a text field, that is a copy of the epic name that should be there on the sub-tasks. It will need to echo the name for parent-level issues and the epic itself, so it's horribly redundant, but at least you'll be able to do a sane search.
Hi All! We’re excited to share the launch of an announcement banner that lets Jira site administrators communicate directly to their users across Jira Cloud instance. 📢 Get y...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events