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.
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).
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.
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 returnboth 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.
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.