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

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

Due to the age of this post, I’m going to go ahead and lock it to prevent further questions from keeping it alive.

After chatting with @KonstantinK, and after the addition of the FAQ, we believe it warrants an end of conversation on this thread.

Have a question about this change? Please post a new topic in Jira Cloud - The Atlassian Developer Community and include a link to this topic.

2 Likes

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.

We will post here once this is fixed.

We have rolled out the fix for JSWCLOUD-22914 to all production customers.

This bug should be no longer reproducible starting from Jun 9, 2022.

This means that the parent field can now be used when creating an issue at the Epic level (level 1) if the parent belongs to the hierarchy level above (configured via Advanced Roadmaps).

Please note that the other bug [JRACLOUD-78657] Inconsistent rest api behaviour when setting parent issue when epic link is not on update screen - Create and track feature requests for Atlassian products. hasn’t yet been fixed. We will update the public bug ticket once it’s been resolved.

Thanks!

UPDATE 04/10/2022. We’re working on unblocking the Marketplace partners to be able to test Change 6. We will update you all soon with the results of it. We will make sure that there is enough time for everyone to test their changes.

Update (7 October 2022).

In order to give our Marketplace partners a better experience in testing Change 6 (changelog items in webhooks), we decided to change the rollout plan for it to return both OLD and NEW changelog items in the SAME webhook event. Originally we announced that we would only return either OLD or NEW changelog.

We plan to rollout Change 6 to Early Adopters / Jira Ecosystem Beta group, and later to all other instances, within a month from now. We understand that this may not allow enough time for you to test your changes. We will monitor the usage of the old fields, and we will switch them off at any point after 30 Nov, when our monitoring indicates that it is safe to do so. If you think you won’t be able to make the required changes to your app before 30 Nov, please let us know.

The bug [JRACLOUD-78657] Inconsistent rest api behaviour when setting parent issue when epic link is not on update screen - Create and track feature requests for Atlassian products. will also be fixed before 30 Nov.

1 Like

Just a heads-up that the bug JRACLOUD-80531 caused the endpoint /rest/api/2/issue/{issueIdOrKey}/changelog return a duplicate IssueParentAssociation item for all Epic Link / Parent Link changelogs. This bug was introduced 3-4 months ago.

The fix for it will be rolling out to production starting now. It will stop these duplicates from being generated for new changelogs. More details, especially on how it affects Parent Link, can be found here.

Only the endpoint /rest/api/2/issue/{issueIdOrKey}/changelog is affected.

The bug did NOT affect webhooks. The fix will NOT affect webhooks. They will continue working as described in Change 6 of this notice.