Deprecation of the Epic Link, Parent Link and other related fields in REST APIs and webhooks

Is it possible to get this thread summarized (and subsequently updated as more info is discovered) on dac or somewhere?

It’s pretty long at this point.

@bentley @dmorrow

3 Likes

Hi @jbevan,
We’ll keep this field in the /rest/api/3/field endpoint after 31 May 2022, and there are currently no plans to remove it from Jira Expressions. So the use case you’ve described will still work after 31 May 2022.
Thanks,
Konstantin

Hi @KonstantinK , I read carefully this longer list of comments, sorry if I missed this point:
I understood, that “Epic Names” will not disappear from the UI. So, will “Epic Names” still be shown in backlog views? Or will this change towards displaying the Epic summary (as it is for team managed projects already)?

Hi @piotrowski,

Epic Name is out of the scope of this notice, so it’s not mentioned in the original post.

This field will continue to exist, but we will no longer use it in UI. We will use Issue Summary, the same as we do for TMP projects.

We will be releasing a blog well ahead of release with the full details of this change.

Thanks,
Konstantin

@KonstantinK If I have an issue with the new parent link, how do I tell if that parent is for an Epic Link, sub-task parent or Parent Link. The parents issue type would be Epic but that only applies to Jira instances that are using English. I could check the issue types subtask field for subtasks but that still leaves Epic and Parent links. Is there going to be a parent type field?

Regards
Paul

1 Like

Hi @paul,

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 hierarchyLevel 0. We’re currently working on enabling these hierarchies, and once it’s done, we’ll announce it separately.

Thanks,
Konstantin

@KonstantinK thanks for that, just what I need

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}”)

@KonstantinK

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?

Is this a bug or have I misunderstood?

Thanks
Paul

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

Hi @KonstantinK

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

Thanks
Paul

Hi @Maks, yes, this is correct.

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.

Thanks,
Konstantin

1 Like

Hi @paul,

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.

Thanks,
Konstantin

@KonstantinK

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

Thanks
Paul

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.

Thanks,
Konstantin

@KonstantinK
But how to get epic color if for next-gen projects this endpoint is useless /rest/agile/1.0/epic/{epicIdOrKey}

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?

Hi @Maks,

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.

Thanks,
Konstantin

1 Like

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.

Thanks,
Konstantin

@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! :heart:

5 Likes