I have an integration with both Jira Cloud and Data Center. I use Jira’s REST APIs to search a list of issues, and I am successfully requesting issuelinks and subtasks fields for all the issues. But I don’t see a way to request the child issues of the epic issues in my search results. My users could trigger a 2nd query with a JQL search for all children of any epics that came back in the 1st search, but I’d really prefer to not make them jump through such hoops. Is there a way the API will let me request any epics’ child issues to be included inline in my search response?
Hello @PatrickBarry
“Is there a way the API will let me request any epics’ child issues to be included inline in my search response?”
Nope. JQL cannot perform recursive searches or determine the children from the parent issue.
I don’t need a recursive search, per se, let me try to be clearer…
If I search for issues and request the subtasks field, then I get a response like:
[
{ key: FOO, subtasks: [ { key: A, key: B} ] },
{ key: BAR, subtasks: [ { key: C} ] },
]
A recursive search (as I think of it) would include A, B, and C at the top level, but I don’t need that. I just want FOO and BAR to have an “epicChildren” field alongside their “subtasks” field if they’re epics.
The answer is still the same.
The first JQL search will return a set of Epic type Issues (the FOOs in your example), but there is no information returned in any sort of ‘epicChildren’ field that lists all the child Issues (the A, B, Cs in your example) of that Epic. This is because the hierarchical relationship information is stored in the child Issue, not the parent Issue, in the parent field. All hierarchical relationships need to queried from the ‘bottom up’ as per the image in this article.
You need to do a separate JQL search for all Issues who have a parent of each Epic. That’s just how it is.
If you Google ‘jira jql epic child issue’ you will see dozens, possibly hundreds of times the topic has been discussed. If you want the functionality you seek with JQL, you need a third party addon like ScriptRunner.
Also, view feature requests such as JRACLOUD-18839, and the ones connected to it, that record similar requests for what you are looking for.
Thanks so much for the detailed response!
I was only being stubborn because All hierarchical relationships need to queried from the ‘bottom up’ is observably not true for subtasks and issue links, and it’s not at all clear to me as a relative newcomer to Jira why an epic and its children would be a different kind of hierarchy.
“is observably not true for subtasks and issue links”
Issue links are not a parent / child hierarchical relationship, they are a one-to-one, bi-directional relationship (a correlation) that’s why any issue type can link to any other issue type at any level. You could create an issue link with one direction called ‘Is the parent of’ and the reciprocal link called ‘Is the child of’ to create a pseudo hierarchical relationship, but that would obviously be a silly thing to do given there are no constraints to prevent linking in the wrong direction or wrong level.
Subtask issue types are children of Stories, exactly the same as Stories are children of Epics, so you cannot retrieve information about that relationship from the parent issue, so I’m not sure what you mean by ‘observably not true for subtasks’ in the context of using the REST API.
Anyhow, if my original answer was correct, please mark it as such and let’s conclude this topic
Certainly! When integrating with Jira Cloud and Data Center using Jira’s REST APIs, you can indeed request issuelinks and subtasks fields for all the issues, but requesting child issues of epic issues in the same search response is not directly supported by the API.
However, there is a solution that could help streamline this process for your users. You can consider using a local integration with Exalate. This means that when your users perform the initial search using the REST API and retrieve the epic issues, Exalate can automatically fetch and include the child issues inline in the search response without the need for a separate query or manual actions
@sunnyape I marked your reply as a solution, but just so you know what I’m talking about, here is an example request and response where the subtasks are returned as a field:
@MathieuLepoutreExala Good to know! I need my integration to work with various customers’ jira instances, so I can’t require everyone to install jira extensions, but perhaps some clients will care enough that they’d be willing to try this, I appreciate it!
1 Like
OK, fair enough, I concede you’re correct that if you’re using Jira Cloud and you lookup the fields of a Story issue type which has Subtasks, the basic information about those Subtask issue types will be returned in the subtasks field.
This works only for the Story / Subtask combination. It doesn’t work for the Epic / Subtask or Epic / Story combination as the subtask field always returns an empty array.
I currently don’t have access to a Jira DC instance, so have no idea if this does / doesn’t work on that Jira type. As for Jira Server… well, nobody really cares about that any more 