In the API response, the parent field contains issuetype, which has the hierarchyLevel property. It supports the following values: -1 for subtasks, 0 for base levels issues (Stories, Tasks etc), and 1 for epics.
So you can use parent.issuetype.hierarchyLevel to determine the type of parent.
Note that currently hierarchy levels above epic (which were previously used in Parent Link) are not yet supported by the property hierarchyLevel, so an epic’s parent will have hierarchyLevel0. We’re currently working on enabling these hierarchies, and once it’s done, we’ll announce it separately.
Hi @KonstantinK
I use “/rest/agile/1.0/sprint/{sprintId}/issue?jql=some_query” to receive color of epic.
Is it correct that this endpoint is going not to return field “epic” and will be no way for me to get this color from response of the endpoint?
As I understand, I’m needed additional request to get epic color?(For example: “/rest/agile/1.0/epic/{epicIdOrKey}”)
There seems to be a problem with the hiearchyLevel. I created an Epic that has an Epic issue as well as a sub-task. When I get the issue details for the Epic issue the parents hierarchyLevel is set to 1 as you described but for the sub task it is also set to 1. Shouldn’t this be -1?
Hi @paul,
The hierarchy described in your example is not supported. Epic’s children should belong to the level 0 issue types: Task, Story, etc. These, in turn, can only have children in level -1 (Subtask). To summarise, the issue’s parent cannot have the same issue type. It must be an issue type with a higher hierarchy level.
Thanks,
Konstantin
So back to my original problem, how do I tell if a parent of an issue is connected because it is a sub-task, Epic issue or parent link. From what you have said the hierarchyLevel is no use
The epic property will be removed from all endpoints, as described in the original post. But the endpoint /rest/agile/1.0/epic/{epicIdOrKey} will continue working.
As one of my previous posts describe, as long as your issue hierarchy is valid (e.g. not having a parent of the same type or level), the hierarchyLevel property will indicate the type of it.
I think you don’t quite understand what I’m wanting. I’m wanting to know what the type of link to the parent is. Is the link a sub-task link or an Epic link or a parent link. How do I tell the type of link there is to the parent. At the moment I just know there is a parent but have no idea what it is
I’m posting the results of the discussion we’ve had with @paul.
Use case: TEST-1 is an Epic. TEST-2 is a sub-task that has TEST-1 as its parent. TEST-3 is a story and it is an Epic issue of TEST-1. How do I tell from the TEST-2 and TEST-3 issues what the link type is?
Solution: we need to also look at the hierarchy level of the child issue:
Issue itself (TEST-3) has hierarchyLevel = 0
Its parent (TEST-1) has hierarchyLevel = 1
From these two you can conclude you’re dealing with the story-epic parent “type”.
This seems to be less convenient than it originally was when we had Epic Link, Subtask Link, and so on.
This is because we’re deliberately moving away from this, to unify hierarchy and no longer differentiate “parent link types”. Soon this will happen to Jira itself.
and /rest/agile/1.0/epic/search doesn’t return epics for next-gen projects too
Is it possible to add epic color in parent if it is epic? This will be useful in some cases
P.S. Only way to get epic color for next-gen project I’ve found is to use /rest/agile/1.0/board/{boardId}/epic, but when I change epic color in UI, response shows still old color(‘color_1’)
Is it a right behavior for next-gen projects?
For TMP (next-gen) projects, we use Issue Color, not Epic Color. It’s a different custom field. You can obtain its value by its field ID from the response of any API endpoint that returns an issue with all fields.
Eventually, we want to unify CMP and TMP in that sense, so both only use Issue Color, but this is out of the scope of this notice.
We have officially added the changes to the createmeta and updatemeta endpoints to this deprecation notice as Change 7. This is our response to the feedback we’ve received from our partners here at Community.
Also, we’ve added the FAQ that summarises the discussions we’ve had here in this thread.
@KonstantinK - a big shoutout to your open, honest and timely communication. You give me as a marketplace partner the feeling that you actually care for our needs.
That’s how I love the interaction in the dev community!
We’ve extended the grace period for the old behavior, so both old and new behavior will be supported until 30 Nov 2022 (previously was 31 May 2022). Please review the updated notice for details
The “Create issue” and “Bulk create issue” APIs (Change 2 in this announcement) currently return an error if the parent field is provided for an Epic issue. This is the known bug JSWCLOUD-22914, and we’re working on fixing it.
As a workaround, please use the old behavior (Parent Link), or the “Update Issue” API.
