In order to give our Marketplace partners a better experience in testing Change 6 (changelog items in webhooks) from this deprecation notice, we decided to change the rollout plan for it to returnboth OLD and NEW changelog items in the SAME webhook event. We shared this update on 7 Oct 2022. Originally we announced that we would only return either OLD or NEW changelog.
On 26 Oct 2022, we will roll out Change 6 (with both OLD and NEW changelog items returned in the same webhook) to the Early Adopters / Jira Ecosystem Beta group. On 1 Nov 2022, we will begin rolling this out to all production instances.
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.
Please let us know if any concerns about it.
Update 04/11/2022: this was rolled out to all production Jira instances on 2 Nov 2022.
another question on the parent link deprecation and issue edits via REST:
When I try to set a parent according to the Advanced Roadmaps hierarchy - as, before, was done using the parent link field - the value is only accepted if it “fits” the expected hierarchy level. If it doesn’t fit, the update operation, while seemingly successful, results in an empty parent field. There is no error indication whatsoever.
This is obviously problematic, as I can’t protect the user from invalid input without re-loading the issue after update, and manually “reverting” the change back to the previous value.
At the same time, I can’t restrict the input before the update, as there’s no REST endpoint that I am aware of that suggests valid parent values for a given issue.
Here’s my asks:
An update operation to an invalid parent must fail with a meaningful error message also for Advanced Roadmaps levels, just like it does for e.g. subtasks from a different project.
We urgently need a REST endpoint to query valid parent values for a given issue.
Perhaps I am under educated on this but I would like to know know more about the potential impact to customers that pull data including the Epic and parent links into database to build relationships and enrich data. How do you expect us to export this information going forward?
Such customers should pull parent instead of Epic Link and Parent Link, as described in the original notice. We’re unifying issue hierarchy in Jira, so logically all these fields represent the same concept - parent.
@KonstantinK ,
how can we efficiently retrieve the “children” of an issue, in a generic way? So far we can still use the issue’s subTasks field to access sub-tasks, and we can use Jira Software’s REST API to fetch the “stories” of an Epic, but there is no Advanced Roadmap REST API. Until now, we’ve been using a JQL search using "Parent Link" = <issuekey>" to fetch “child issues” in the hierarchy, should we continue doing this or is there another way?
At the moment, the JQL search "Parent Link" = <issuekey>" is still the recommended way of doing this. We’re working on unifying issue hierarchy in JQL, but this hasn’t been released yet. We will provide more details once ready.
Could you also give us a bit of information regarding the other question from @hannes-finesoftware. We also would appreciate an REST endpoint for this, we are still grabbing the info from “/rest/jpo/1.0/parent/suggest”, but this is only supported with OAuth1a & API tokens, which we both like to avoid going forward.
The endpoint to return suggestions for the parent field exists, but it has not yet been exposed externally. We have plans to expose it via GraphQL API. At the moment I don’t have the timeline for this.