I would like to make sure that the projectTypeKey is always returned in the project field when an issue response is received (either using JQL or issue endpoints). The test server that I use shows that I should be able to check fields -> project -> projectTypeKey for this property, however, this is not returned to me in another server.
Can someone tell me if there is a particular setting that is preventing this property from being returned and whether the setting is configurable?
Here is the JSON for the issue that I receive from my test server which contains the projectTypeKey value.
{ "expand": "operations,versionedRepresentations,editmeta,customfield_10500.properties,changelog,customfield_10600.requestTypePractice,customfield_10400.properties,renderedFields", "id": "40662", "self": "https://mydomain/rest/api/3/issue/40662", "key": "TP-200", "fields": {
...
"project": { "self": "https://mydomain/rest/api/3/project/10000", "id": "10000", "key": "TP", "name": "Test Project", "projectTypeKey": "software", "simplified": false, "projectCategory": { "self": "https://mydomain/rest/api/3/projectCategory/10000", "id": "10000", "description": "Sample Projects", "name": "Samples" } }
...
} }
Hi Anya,
I see that in your response, you appear to be calling a Jira Cloud site, and specifically calling the endpoint of GET /rest/api/3/issue/{IssuekeyOrId}. However if calling a different Jira site is not returning this, I suspect that perhaps you might be calling a Jira Server or Jira Data Center site. The REST API of these two are not identical, and I don't believe that Server/DC returns this value.
If this is a Jira Cloud site, then the site address will be either an atlassian.net domain or possibly a jira.com domain (only possible on a few legacy domains). If the domain of the site is any other domain, then that should be a pretty clear indication that the site you are calling is a Server/Data Center edition.
But even if this is not the case, I don't know of any configuration option to either include/exclude that specific field from the results of the JQL/Issue that is returned in json here. The Server/DC REST API does have some additional endpoints to determine which projects fall into which project types, such as explained in api/2/project/type.
Please let me know if this helps. If this is in fact a Jira Cloud site, please let me know the site URL here so that I can investigate that site in more detail here. If this is a Jira Server/DC site, then I hope this explanation above helps to suffice here.
Andy
Hello @Andy Heinzer
For 2 of our customers, who are running Jira server on-premise, versions 8.13.10 and 8.13.8, GET request sent to https://<jiraServer>/rest/api/2/issue/{issueKey} returns with fields.project.projectTypeKey, as shown below. The project object shown below is inside the fields object in the issue-by-key-response. You can see projectTypeKey = software in the response.
However, for another customer, who is running Jira server on-premise, version 7.6.4, the same request does not return the projectTypeKey.
For all three servers, the Jira REST API v2 is functional. So, how is it that the response from 7.6.4 is different than 8.13.x? Did the response change from Jira server 7.x to 8.x, even though the API version remained the same (v2)? Can you please confirm this?
Also, for what version of Jira did this switch happen?
Thanks
Manas
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Manas,
I have not found the exact version where this change first happened. But I have confirmed that Jira 8.0.x also displays this projecttypekey in the response of the GET issue endpoint. I suspect that this change was made as part of a major version upgrade to 8.
However so far, I have not found a specific feature or bug fix ticket that accurately documents this specific change. Minor changes like these are not uncommon to see within the Jira server REST API. Unfortunately, the documentation space that provides examples of json responses, has not been updated to reflect this change, and in turn it isn't clear exactly which version this change happened in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.