Deprecation Notice: toString representation of sprints in Get issue response

Hi Everyone,
Previously we announced that we’d be changing the response type for get issue responses, however there was some confusion around when this would occur.
From 1 September 2020, this change will take effect.
Jira REST API responses that include the Sprint custom field type will no longer return string representations of sprints in the body. This data will still be available in its proper JSON representation wherever a string was previously expected.
Please review full details of the change at https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-tostring-representation-of-sprints-in-get-issue-response/ and let us know if you have any questions or feedback.

Will you be providing some way for us to be able to get both formats at the same time?

Hi @MinhHo,
I’m not sure I understand: after September 1, 2020, no value will be returned at all for the Sprint field in “normal” Get Issue calls? Why not return the proper JSON data, like for all other custom fields?
This is both inconsistent and problematic, as it forces us to issue a second call to get the Sprint field, since it requires expand=versionedRepresentations which is incompatible with other operations (such as specifying which fields to return).
Please reconsider, and return the value of the Sprints field in normal Get calls.

Thanks,
David

@david2 made me re-read the posting. Can we get:

  1. How to verify the output from what we have today and what we are going to expect?
  2. A migration path of when we should start be able to verify things and when things will be able for us to switch to it.

From this posting - it sounds like Sept 1 a trigger will be pulled and that’s the first time things will show up.

It would be awesome if we could avoid the previous time that atlassian told us they were deprecating with one format and gave us vendors another.

Hi @david2,
The sprint field will be returned from the API, but the format will be in JSON format, exactly as what you recommended

Hi @danielwester.
Unfortunately, we can’t return both formats of the sprint field in the same response, can you please refer to the JSON format in the deprecation notice. If you have any question around the new format, we’ll try to answer here

@danielwester, what I can recommend you to do is start adjusting your code to adapt for both formats (one of our vendors has done that before). By doing that, when the new format is triggered on 1st Sept, it shouldn’t be a problem to your plugin, then you can wait for a couple of days before cleaning up the code which supports for the old format.
Hope that helps

@MinhHo that’s great news, but can you update the deprecation notice then? It currently reads:

After this date, you will only be able to get data for the Sprint custom field through its JSON representation. This is available via the get issue method with expanded versionedRepresentations, in the Jira Platform REST API and the Jira Software REST API.

Maybe it should read:

After this date, only the JSON representation will be returned for the Sprint custom field, in the same format that is currently returned via the get issue method with expanded versionedRepresentations, in the Jira Platform REST API and the Jira Software REST API.

But then, the rest of the notice shows:

New:

Get Issue call:
https://TESTINSTANCE.atlassian.net/rest/api/2/issue/DEMO-1?expand=versionedRepresentations

which is also misleading.

2 Likes

After reading the deprecation notice, I’m still not at all clear on what will happen to the response when using versioned representations. As @david2 mentioned, the example shows versionedRepresentations expanded, but the shape of the response shown does not align with the shape of a response in general when versionedRepresentations is expanded.

Here is what we get now:

{
  customfield_10021: {
    '1': [
  'com.atlassian.greenhopper.service.sprint.Sprint@1e31029[id=4,rapidViewId=3,state=ACTIVE,name=2019.02 Sprint 2,goal=,startDate=2019-02-17T18:47:25.689Z,endDate=2019-03-02T19:47:00.000Z,completeDate=<null>,sequence=3]'
    ],
    '2': [
      {
        id: 4,
        name: '2019.02 Sprint 2',
        state: 'active',
        boardId: 3,
        goal: '',
        startDate: '2019-02-17T18:47:25.689Z',
        endDate: '2019-03-02T19:47:00.000Z'
      }
    ]
  }
}

What will we get moving forward?

Cheers,
Mark

1 Like

Thanks for your recommendation @david2, I’ve updated the deprecation notice

Hi @ElementML, I’ve updated the deprecation notice to make it less confusing, the new response shape will be applied to the get issue details API and doesn’t have anything to do with the versionedRepresentations expand param.

Thanks @MinhHo!

I understand the scope of the changes without versionedRepresentations expanded (as described in the deprecation notice), but could you please confirm that the shape of the response with versionedRepresentations expanded? Am I safe to assume that it will remain unchanged? Or will the string representation also be removed from the versioned representations as well? Just trying to determine if this deprecation represents a breaking change for those of us that currently use versionedRepresentations to access Sprint data in JSON format.

Thanks in advance for your continued assistance.

Cheers,
Mark

Hi @ElementML,
The string representation will also be replaced with the new json format

Hi @MinhHo,
Starting today the old format is returned - string instead of JSON. Is this a temporary regression?

Edit: Please ignore the question - I have noticed that the new depreciation date is September 1, I thought this was already deprecated. Awaiting September 1.

1 Like

We also noticed that the order the keys in the serialised sprint object are now alphabetically ordered? It may well have been the internal JVM implementation of .toString changing with an update, however this has broken our app again. It’s just a sign that this needs to be fixed once and for all. :+1: Bring on September.

I think it would be lovely if Atlassian had a test for the old format.

1 Like

This unexpected change actually broke our app. @MinhHo was the change expected? Are you going to roll it back?

Thanks,
David

1 Like

We’re following up with the prod/eng team. Stay tuned.

Update: this change isn’t related to the deprecation notice. We’re still looking into this.