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

Hi @KonstantinK,

thanks for your answer and clarification.

Perhaps I have not explained well.
We execute jqls through the API with the identifiers of these fields.
Will obtaining the configuration of those fields also be removed from the services? e.g. of the expand attribute.

Thanks,
David.

Hi @dortiz,

Thanks for the details!

When it comes to using the POST /rest/api/3/search endpoint with a payload like:

{
    "jql": "issuetype = Story",
    "maxResults": 45,
    "startAt": 0,
    "fields": ["parent"]
}

in the "fields" property, the parent field replaces Epic Link, Parent Link, etc which will be removed on May, 31.

But I think in your message you meant another use case? Could you give me a detailed example of the use case you were talking about, including the endpoint and sample payload, so I can confirm it for you?

Thanks,
Konstantin

Hi @KonstantinK,

thanks for the reply.

  1. Regarding the services referred to in this announcement, we have doubts as to whether all the information on the fields will be eliminated. For example, names and schema values of the expand attribute.

  1. As for services not included in this announcement, we understand that the information of the fields will be kept after May 31 (for example, /rest/api/3/field), but do you plan to eliminate them in the near future?

Thanks,
David.

Hi @dortiz,

Thanks again for your patience.

For use case 1: I need to discuss it internally and will be back to you. Do you need this functionality even when the parent field will be returned instead?

For use case 2: we’re not planning to remove these fields from /rest/api/3/field at this stage.

Thanks,
Konstantin

Hi @KonstantinK,

thanks for the reply.

We need to obtain the ids of the “Parent Link” and “Epic Link” fields because our jql queries in the /rest/api/3/search service are performed by ids and not by field names.

“jql”: “customfield_10017 in (LHCO-4, LHCO-5, LHCO-19)”

with “customfield_10017” = “Epic Link”

As we mentioned in the first topic, at the moment the “parent” field will not return the issues of an epic or the issues of the roadmap hierarchy, so the jql’s must continue to be done with the “Parent Link” and “Epic Link” fields.

The two commented use cases are the ones we use to obtain the ids of both fields. If the field settings will be removed from the services, we will need another way to get their ids.

Thanks,
David.

1 Like

Hi @dortiz,

Thanks for the details!

I confirm we’ll keep this field in the /rest/api/3/field endpoint after 31 May 2022, because we’re not removing this field from UI, so it should still exist within Jira. Would using this endpoint only be sufficient for your purposes?

In terms of using the expand property in the POST /rest/api/3/search endpoint, based on our current field removal plans, we can’t guarantee that your current approach will still work after 31 May. If you think that using only /rest/api/3/field is insufficient for your purposes, let us know and we’ll see what alternative approach we can offer.

Thanks,
Konstantin

Hi @KonstantinK,

thanks for the reply.

As after 31 May 2022 the jqls of the /rest/api/3/search service must continue to be performed with the “Epic Link” and “Parent Link” fields (because the “parent” field will not return the issues of an epic or the issues of the roadmap hierarchy), the service /rest/api/3/field is sufficient. Thanks a lot.

Will you post another ad when the “Epic Link” and “Parent Link” fields are replaced by the “parent” field in the jqls of the /rest/api/3/search service?

Thanks,
David.

1 Like

Hi @dortiz,

Yes, the changes to the JQL parent will be announced separately. While Epic Link and Parent Link will continue to work in JQL, using parent will become the recommended solution for the use cases where these fields were used.

Thanks,
Konstantin

Hi @KonstantinK,

Thank you very much for all the information.
David.

Hey @KonstantinK, can you confirm if the new API have been rolled out to all Jira instances?

Hi @MichaNykiel, I confirm that these changes have been fully rolled out to all instances by now. We’ll keep monitoring them over the next week in case of any problems. We’ll post here if anything goes wrong.

Thanks,
Konstantin