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

Jira Development Jira Cloud Announcements
, , , ,
42

How does this affect Server customers currently using these links that will be migrating to Cloud?

43

Hi @KonstantinK ,

Epic Link custom field allows to create a link to Epic in other company-managed project.
But when I follow Change 2 and try to create an issue with:

"fields": {
...
"parent": {"id": <epic issue id in other project>}
...
}

Jira responds:

'project': Sub-tasks must be created in the same project as the parent.

Is this expected?

Thanks,
Mario

2 Likes
44

Hi @SierraSky,

Yes, this is correct. At this stage, nothing changes for the website and user interface. One can still use these fields in UI.

Thanks,
Konstantin

45

Hi @forbes,

This change does not affect Server to Cloud migration. No data will be lost. Once migrated to Cloud, the Jira instance will work as described in this notice.

Thanks,
Konstantin

46

Hi @mario, thanks for bringing this to our attention.

Having discussed this internally, we decided that we will add support for such a use case and allow to set parents from another company-managed project, as you’ve described in your example.

My estimation is that this change will be released by the end of March 2022. We will reply to this message once it’s in production.

Thanks,
Konstantin

47

Hi @david2,

  1. Yes, this is expected. Some fields in Jira don’t have schema, and these include the parent field.
  2. At this stage, the subtasks system field will remain available.
  3. We are not planning to add the children system field into the public REST API at this stage. We’ve considered this, but haven’t planned any work due to our team’s priorities.
  4. Yes, it is writable as described in Change 2 from this deprecation notice.

Please let us know if you have any further questions.

Thanks,
Konstantin

48

Hi @KonstantinK ,
thanks for your reply.
Regarding 1., it’s a pity because it forces us to add special cases for these fields, instead of being able to rely on the schema for things like data conversion, automatic inline help, etc.
Regarding 4., is it also writable for sub-tasks? As far as I know, the parent field wasn’t writable until now, was it? If so, will it fail when you specify a parent issue from another project (since that constraint only exists for the parent/sub-task relationship and nowhere else in the hierarchy)?

Another question: will the Jira Expressions language be updated as well to expose the parent field for the whole hierarchy? As of now, it only works for sub-tasks and returns null for every other issues (instead of returning the epic of the issue, for example).

Thanks,
David

49

Hey @KonstantinK

Will this change be done for createmeta API(rest/api/2/issue/createmeta) also?
createmeta API returns the issue type and fields under an issue type. Currently, it returns “Epic link” under a few issue types as below:

{
  "name": "Story",
  "fields": {
    "customfield_10014": {
      "name": "Epic Link",
      "key": "customfield_10014"
      .......
    }
    .......
  }
  .......
}

I don’t see the “parent” field. Will the “parent” field be added in the future after the above-announced changes?

Reference to createmeta API

50

@KonstantinK same thing for the editmeta API. Right now it doesn’t return the parent field at all, even though you said it is editable.

Can this and editmeta be fixed soon?

Thanks,
David

51

Hi again @KonstantinK ,

actually, I tried setting the parent field of a sub-task using the Edit Issue endpoint, and while the call succeeded, the parent of the sub-task didn’t change. Based on your previous answer, that’s a bug.

Best,
David

1 Like
52

I have been using parent field to create subtasks for a long time. Did you try following payload:

{ fields: {
    parent: {
        key: parentIssueKey 
    },
    summary: ... etc.
}

On the other hand, you said that it doesn’t work for edit, right?

53

Hi @maciej.dudziak ,
correct, we’ve been using it forever to create new sub-tasks. But it doesn’t work to change an existing sub-task’s parent issue, even though @KonstantinK said it should.
David

54

Hi @david2,

Apologies, my previous answer missed that. For the CMP subtasks, editing the parent field via these APIs is not permitted. This was an existing behavior in Jira before our changes.

Of course, the parent field can still be used for creating subtasks.

For CMP issues above subtasks (e.g. Stories, and so on), the parent field is editable.

For now, there are no changes to Jira Expressions planned with regard to this notice.

Thanks,
Konstantin

1 Like
55

Hi @rajesh, thanks for sharing this.

This field is not present in the {{baseUrl}}/rest/api/3/issue/createmeta and /rest/api/3/issue/:issueIdOrKey/editmeta endpoints’ responses for CMP issue types above subtask. We will add the parent field to these endpoints before the deprecated fields removal date. We will reply to this message once it’s done.

cc @david2

Thanks,
Konstantin

56

@KonstantinK regarding the Jira Expressions API, we currently use this API to access the Epic Link field (I’m not sure if we use the Parent Link/Parent fields) in order to fetch 10x the data from Jira that the Search API returns. This is for performance reasons, driven entirely by demand from customers with several hundred thousand issues.

I notice you’ve not mentioned the Fields API /rest/api/3/field.

After 31st May are we still going to be able to fetch the Epic Link field name from the Fields API, and then use it in the Expressions API to obtain the value of the Epic of an issue?

1 Like
57

Is it possible to get this thread summarized (and subsequently updated as more info is discovered) on dac or somewhere?

It’s pretty long at this point.

@bentley @dmorrow

3 Likes
58

Hi @jbevan,
We’ll keep this field in the /rest/api/3/field endpoint after 31 May 2022, and there are currently no plans to remove it from Jira Expressions. So the use case you’ve described will still work after 31 May 2022.
Thanks,
Konstantin

59

Hi @KonstantinK , I read carefully this longer list of comments, sorry if I missed this point:
I understood, that “Epic Names” will not disappear from the UI. So, will “Epic Names” still be shown in backlog views? Or will this change towards displaying the Epic summary (as it is for team managed projects already)?

60

Hi @piotrowski,

Epic Name is out of the scope of this notice, so it’s not mentioned in the original post.

This field will continue to exist, but we will no longer use it in UI. We will use Issue Summary, the same as we do for TMP projects.

We will be releasing a blog well ahead of release with the full details of this change.

Thanks,
Konstantin

61

@KonstantinK If I have an issue with the new parent link, how do I tell if that parent is for an Epic Link, sub-task parent or Parent Link. The parents issue type would be Epic but that only applies to Jira instances that are using English. I could check the issue types subtask field for subtasks but that still leaves Epic and Parent links. Is there going to be a parent type field?

Regards
Paul

1 Like