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

Jira Development Jira Cloud Announcements
, , , ,
22

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.

23

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

24

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.

expand_names_schema
expand_names_schema758×769 32.6 KB

  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?

fields
fields705×1221 39.6 KB

Thanks,
David.

25

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

26

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
27

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

28

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
29

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

30

Hi @KonstantinK,

Thank you very much for all the information.
David.

31

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

32

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

33

Hi @KonstantinK,

Any updated timeline on implementation of this for UI/JQL? When these changes are rolled out to the UI and JQL will that also support more flexible hierarchies (e.g. putting feature between epic and story like all the SAFe people have been wanting to do)? Would it support skipping layers in the hierarchy if not needed (e.g. parenting a story directly to initiative if there is no parent epic)?

Will childIssuesOf also be usable in this context?

Thanks, Carl

34

Hi @CarlWeller, welcome to the Developer Community!

We’re currently working on this, and one of the goals we want to achieve is to enable SAFe-practicing customers to create and use flexible hierarchies.

I expect these changes to be released gradually in 2022, and it’s likely that the JQL change will come first. We will announce this (along with all the details) separately.

Thanks,
Konstantin

1 Like
35

Thanks for this information it will have a huge impact on our side.

1 Like
36

Hi,

You’ve said the APIs will be show both the legacy and the new fields. How can we test against only the updated responses so after the legacy fields are removed from the response we can be sure our apps still work?

Chris

1 Like
37

Hi There,
I can’t make out if this only applies to the API or if it will apply to the backend database as well.

Thanks
L

38

Hi @ChrisWise1,

At the moment we don’t have the capability to switch off the old behavior for certain Jira instances. But we will have it closer to the fields removal date.

My understanding is that we will have such a capability in late April - early May 2022. Once this happens, we will be able to remove (and then restore if needed) the old fields for certain instances (on the admin/partner request). This will only affect the requested Jira instance, so all other instances will not be affected.

I’ve created a reminder for myself to post here once such a capability is available. After that, one can request us to switch the old fields on/off for their testing instance by sending me a direct message here at Developer Community.

Thanks,
Konstantin

39

Hi @LwandileRorwana, welcome to the Developer Community!

These changes only apply to the public API and webhooks in Jira Cloud. These changes are not applicable to our Server products.

Could you provide more details on what was meant by the backend database?

Thanks,
Konstantin

40

Hi All,

Could anyone water this down a little bit ? As in, does this mean come that date the mentioned fields will no longer be seen , in software management projects ?

“These changes do not apply to these fields in the Jira UI and JQL.” So, this would imply nothing changes for someone who wants to keep using those fields on website , user interface ?

41

HI @KonstantinK ,
a couple of questions:

  1. the /rest/api/2/field REST endpoint doesn’t return a schema for the Parent field, is that normal?
  2. what will happen to the subtasks system field? Will it remain available?
  3. will there be a children system field to access the children of an issue in the hierarchy, similar to the subtasks field? It’s currently expensive to get the “child issues” of an Epic, since we need to run a JQL search, while it’s super easy to get the sub-tasks of an issue. Shouldn’t it be unified as well?
  4. is the new Parent field writable, like the Parent Link and the Epic Link fields currently are? If so, is it writable for sub-tasks as well (it wasn’t so far)?

Thanks,
David

1 Like