Deprecation Notice: toString representation of sprints in Get issue response

And another question: “/rest/api/{Version}/issue/createmeta” returns list of ProjectDTOs which contain FieldDTOs containing SchemaDTO. The values SchemaDTO.Type is now “string”. Will the value SchemaDTO.Type be “sprint” in case the field is “Sprint”? If no, it is difficult to understand that the field contains JSON for some Sprint.

And one more idea: will this change be available on the vendors-first instances before 1 Sep?

Hi @MinhHo @nmansilla what is the schema for the new sprint field format? right now as @ivan.babikov says it is type:array and items:string:

{

    "id": "customfield_10007",
    "key": "customfield_10007",
    "name": "Sprint",
    "untranslatedName": "Sprint",
    "custom": true,
    "orderable": true,
    "navigable": true,
    "searchable": true,
    "clauseNames": [
        "cf[10007]",
        "Sprint"
    ],
    "schema": {
        "type": "array",
        "items": "string",
        "custom": "com.pyxis.greenhopper.jira:gh-sprint",
        "customId": 10007
    }

},

It is important to know the new schema returned by the rest API because any code processing custom fields relies on the schema.

Hi @nmansilla , Can you confirm the schema for the field will remain as it is today? otherwise, can you provide the new schema?

{
  "schema": {
    "customfield_10020": {
      "type": "array",
      "items": "string",
      "custom": "com.pyxis.greenhopper.jira:gh-sprint",
      "customId": 10020
    }
  }
}
``

Hi @dtorres, this change is not related to the sprint schema, so it will remain unchanged, only the sprint field value returned from the issue details endpoint is now in JSON format rather than String

Hi @ivan.babikov This change is not related to the sprint schema, so it will remain unchanged, only the sprint field value returned from the issue details endpoint is now in JSON format rather than String

@nmansilla @MinhHo Today is Sept 1 and so far the returned value hasn’t changed. Any idea when the change will be deployed?

@david2 It’s being rolled out, could be that you haven’t got the change yet. Expected to fully rollout by tomorrow

1 Like

Was this rolled out to the EAPs first? We’re getting bug reports from customers (and it looks like it’s out code that isn’t able to match things) but aren’t able to recreate it…

Same here, I’m not seeing the change on my dev instance, even though it’s registered for the early release cohort program, so it should have received the changes first…

@david2 @danielwester - You’re right, we did not have things set up properly re: the dev-first release instances on this change. That’s been addressed. As of 2020-09-02 4:20 PM PST, the change was rolled out to all enrolled dev-first release instances.

Thanks @nmansilla. That means that my request to add certain of our instances to the dev-first list was not processed, because I don’t see the changes on any of them yet.
Is there a way to know if an instance is on the dev-first cohort?

@david2 I’ll check on that for you. Send me a DM or Slack with your instance ID.

The array items was changed to “json” in the schema.

image

Can you confirm this is the final schema? We are concern since you mentioned that the schema was not going to change.

@dtorres yes, that’s the final schema

Sorry @MinhHo but that change was not communicated before, and of course it broke our app since we couldn’t anticipate the schema change.
Between that unannounced change and the fact that the changes were not first deployed to the dev-first cohort, there was no way we could avoid disrupting our customers’ workflows.

@nmansilla @SunnyManaktala @AnnaBarry this is a good example of how not to implement a breaking change, and I believe this deserves a post-mortem on Atlassian’s part to make sure it happens more smoothly next time.

Just my two cents…
David

2 Likes

@MinhHo Our integration with Jira broke because of this change. Is there any way we could have prevented this?

Why do you introduce breaking changes to the versioned API that should be stable?

They probably introduced this one breaking change since the old situation was even more unreliable with the serialization format changing in an unrealiable way. Still I think that once a format is published it should not be changed, unless the version of the endpoint is bumped.

Is there any news regarding the introduction of this change to Jira SERVER as well?
I was not able to find anything about it. I thought Cloud and Server products are kept consistent maybe…