How to get parent issue fields in JQL search results on Cloud

[Emre Toptancı [OBSS]]

While searching for issues using the /rest/api/3/search endpoint, we can use the fields parameter to select which issue fields to include in the results.

For subtasks, the parent field can be used here and the parent field is actually a complex JSON object that includes the id, key, summary, status, priority, and issuetype of the parent. 

How can I include more fields in the parent field JSON? I am particularly interested in seeing the Epic Link field value of the parent issue.

The alternative would be to collect the parent keys and make another REST request for the parent issues, which is something I'd rather not do.

[Sunny Ape]

Hello @Emre Toptancı [OBSS] 

Basically speaking, you can't do what you want in a single JQL statement. There is no way for a JQL query to get data that is nested within an object that is at a 'higher' or 'lower' level, JQL just doesn't work like that; it's not a fully recursive query language.

Your JQL request asked to include the content of the parent object in the results, and you got back exactly what you asked for... the content of that parent object, which contains some information like the id, key, summary, status, priority, and issuetype etc of the parent issue. The parent object does not contain everything about the parent issue, so there is no more data that could be extracted from it.

The reverse is true if you query that parent issue; you will get back the subtasks object that contains some information about the sub-tasks issues and some of sub-tasks fields, but not everything or every field of those subtasks.

In summary, if you want to get the contents of other fields that are in that parent issue, you will have to do a totally separate search for that parent issue and specify in the JQL what fields you want returned in that separate search.

[Aron Gombas _Midori_]

If you figure out it is impossible (which is rather likely IMO) but you still want to save the second REST API call, here is a workaround idea.

The /search end-point accepts a JQL. You could eventually rephrase that JQL to return both the sub-tasks plus their parents! It's one REST API call and then you can just iterate over the result, if the current item is a sub-task, then it's parent will be available in the response with its details.

[Emre Toptancı [OBSS]]

While this is technically possible, I'm afraid in most cases it won't help. Because getting the Epic name of the parent is only a part of my total work with the issues. If I rephrase the query to include the parent issues, I won't be able to tell if any parent issue was in the resultset of the original query or it was included because of the rephrasing.