When requesting an issue from Jira Server via REST we get the following toString() repesentation of the “Sprint” field:
"fields": {
"summary": "xxxxxxxxxxxxxx",
"customfield_10004": [
"com.atlassian.greenhopper.service.sprint.Sprint@5c0ac8bd[id=15279,rapidViewId=<null>,state=CLOSED,name=Sprint 1,startDate=2020-01-07T13:56:33.360+01:00,endDate=2020-01-20T14:56:00.000+01:00,completeDate=2020-01-20T13:24:14.668+01:00,activatedDate=2020-01-07T13:56:33.360+01:00,sequence=15279,goal=<null>,autoStartStop=false]",
"com.atlassian.greenhopper.service.sprint.Sprint@6c77b565[id=15281,rapidViewId=<null>,state=CLOSED,name=Sprint 3,startDate=2020-02-03T16:36:01.859+01:00,endDate=2020-02-17T17:36:00.000+01:00,completeDate=2020-02-17T14:37:31.198+01:00,activatedDate=2020-02-03T16:36:01.859+01:00,sequence=15281,goal=<null>,autoStartStop=false]"
]
}
For Jira Cloud this has been changed effectively since 1st September 2020: Deprecation notice - toString representation of sprints in Get issue response
Questions:
- When is this behaviour introduced to Jira Server (which version)?
- Currently we can use the additional parameter “&expand=versionedRepresentations” as workaround.
Jira REST API doc says:
“versionedRepresentations - REST representations of all fields. Some field may contain more recent versions. RESET representations are numbered. The greatest number always represents the most recent version. It is recommended that the most recent version is used. version for these fields which provide a more recent REST representation. After includingversionedRepresentations“fields” field become hidden.”
Source: JIRA 8.5.5
Our Jira Server returns such a REST representation using this parameter:
"versionedRepresentations": {
"summary": {
"1": "xxxxxxxxxxxxxxx"
},
"customfield_10004": {
"1": [
"com.atlassian.greenhopper.service.sprint.Sprint@f33338c[id=15279,rapidViewId=<null>,state=CLOSED,name=Sprint 1,startDate=2020-01-07T13:56:33.360+01:00,endDate=2020-01-20T14:56:00.000+01:00,completeDate=2020-01-20T13:24:14.668+01:00,activatedDate=2020-01-07T13:56:33.360+01:00,sequence=15279,goal=<null>,autoStartStop=false]",
"com.atlassian.greenhopper.service.sprint.Sprint@3721570d[id=15281,rapidViewId=<null>,state=CLOSED,name=Sprint 3,startDate=2020-02-03T16:36:01.859+01:00,endDate=2020-02-17T17:36:00.000+01:00,completeDate=2020-02-17T14:37:31.198+01:00,activatedDate=2020-02-03T16:36:01.859+01:00,sequence=15281,goal=<null>,autoStartStop=false]"
],
"2": [
{
"id": 15279,
"name": "Sprint 1",
"state": "closed"
},
{
"id": 15281,
"name": "Sprint 3",
"state": "closed"
}
]
}
}
So the correct repesentation is already supported/introduced AND marked as newer (“The greatest number always represents the most recent version.”).
Then why is the current default return of an issue (without using the parameter “versionedRepresentations”) still returning the old representation? I’d guess if you introduce a newer representation (whose very meaning is the enhancement regarding the representation itself) then it should be the return by default and the older representation should be returned only by using the parameter “versionedRepresentations” then.
Yes it might break old API clients, but you already did that during introduction for the CLOUD version as people got not informed correctly about the introduction of an change announced years ago.
So that isn’t the reason I guess.