There's no way to change the timestamps format. As for “Assignee”, it's just a custom field like any other, so you can rely on the general CustomField schema.
Thanks. Is it possible to have the custom field returned as part of the basic issue query, or do I have to call “api/issues/{issue id}/customFields/{custom field id}?fields=id,etc.”?
I see our Assignee field has an id of either 23-4 or 23-11, but when I call “api/issues/1-234/customFields/23-11?fields=id,value(id,name,login,fullName),projectCustomField(id,field(id,name))” I get a 404, “Entity with id 23-11 not found”, and the same for 23-4.
It looks like the “Assignee” field has a different ID in the issue project. You can query /api/issues/1-234/customFields?fields=name,id to find the ID of the “Assignee” field, and then obtain it via /api/issues/1-234/customFields/{fieldID}?fields=name,value(login).
It is also possible to request custom fields in the basic issue query like this: /api/issues/1-234?fields=customFields(name,value(login)).
Thanks, Julia, I'm able to do that successfully in a basic curl call.
In another application in which I'm trying to use this API, a problem becomes evident in that issues/customFields/value comes in a variety of configurations: a string, an object, an array, or null.
However, it appears to me that the value in IssueCustomField can only be an object.
If that's true, why does value come as those other things? Here's an example of the customFields for a single issue.
Julia, thanks for your continued correspondence. OpenAPI is still rather new to me, so I want to make sure I understand. The particular software I'm using is very specific about the validity of the response, where other software doesn't necessarily care or validate the response.
In your OpenAPI 3.0.x-based spec itself (available via /api/openapi.json in our YouTrack 2024.3.44799 instance), IssueCustomField defines “value” property to be an object, and only an object.
To my knowledge, OpenAPI 3.0.x doesn't permit multiple types for a property (though OpenAPI 3.1 apparently does). Thus I guess my question to you is how can the value property represented as a string, or array, or null, be valid against your own specification?
As I can see, IssueCustomField is then extended by schemas like SimpleIssueCustomField, but the value property seems to be defined as object there as well. Before we look into the validity of the specification, can you please let me know how you use it and how the value definition causes issues?
Hi, Julia. Essentially, I'm using an ETL application which offers OpenAPI support. It lets me access parts of the response and manipulate them as necessary for further processing. It's quite powerful, but it expects (requires, really) the response to be completely valid against its' specification.
I can work around the issue as long as your specification remains based on OpenAPI 3.0 by removing the "type":"object" property from the value definition. Presuming I'm right in my understanding (I do certainly leave open the possibility that I'm wrong!), then I imagine if/when you update to OpenAPI 3.1 your specification will specifically define these value variants of other types.
G. K., thanks for the reply! I imagine the application shows some kind of error when it encounters an invalid response violating the specification - would it be possible for you to share some screenshots of that? This will help our developers analyze the issue further.
In the meantime, if you can make the necessary changes to the OpenAPI specification locally, we'd encourage you to do so as it seems to be the most straightforward way to unblock working with the tool.
Hi, Julia, please pardon the delayed response. Here's a screenshot showing the validation errors shown by the application I'm using. As you can see the complaint is about value being an array or null (string is also a problem as well, though it's not shown in this particular screenshot).
Do you have another tool you use for response validation? If so, what is it? Is there one which says such a variety of value property types is valid against YouTrack's OpenAPI 3.0-bsaed specification?
We don't usually recommend any specific tools as we cannot guarantee reliable functionality of any third-party products. Regarding the errors from the screenshot, would it be possible for you to also share the name of the tool and the exact request that results in validation errors? In case that's sensitive info, feel free to submit a ticket to share it privately: https://jb.gg/ytsup.
Hi Jay,
you can find it here: https://www.jetbrains.com/help/youtrack/incloud/api-json-schema.html
Let us know if we can help you with anything else.
That URL is no longer accessible. Also, the example I found in Archive.org doesn't look like it led to an actual, downloadable JSON schema file.
The “JSON Scheme” available in the Hub API docs also doesn't lead to such a file. Is one available?
Hello, the Hub JSON schema can be found here. As for YouTrack, will the OpenAPI specification work for you?
> Hello, the Hub JSON schema can be found here.
Thanks, but I was actually looking for a formal JSON schema, which I can't find on that page.
> As for YouTrack, will the OpenAPI specification work for you?
Yes, in fact, I can work with that. One question: is there a way to get Unix epoch fields (e.g., issue/created) returned in ISO 8601 format instead?
Also, where can I find the “assignee” field? It's not clear.
Hi G. K.,
There's no way to change the timestamps format. As for “Assignee”, it's just a custom field like any other, so you can rely on the general CustomField schema.
Thanks. Is it possible to have the custom field returned as part of the basic issue query, or do I have to call “api/issues/{issue id}/customFields/{custom field id}?fields=id,etc.”?
I see our Assignee field has an id of either 23-4 or 23-11, but when I call “api/issues/1-234/customFields/23-11?fields=id,value(id,name,login,fullName),projectCustomField(id,field(id,name))” I get a 404, “Entity with id 23-11 not found”, and the same for 23-4.
It looks like the “Assignee” field has a different ID in the issue project. You can query
/api/issues/1-234/customFields?fields=name,id
to find the ID of the “Assignee” field, and then obtain it via/api/issues/1-234/customFields/{fieldID}?fields=name,value(login)
.It is also possible to request custom fields in the basic issue query like this:
/api/issues/1-234?fields=customFields(name,value(login))
.For more information on querying custom fields and the REST API in general, feel free to refer to the documentation: Get Value for an Issue Custom Field, Issue attributes.
Thanks, Julia, I'm able to do that successfully in a basic curl call.
In another application in which I'm trying to use this API, a problem becomes evident in that issues/customFields/value comes in a variety of configurations: a string, an object, an array, or null.
However, it appears to me that the value in IssueCustomField can only be an object.
If that's true, why does value come as those other things? Here's an example of the customFields for a single issue.
{
"value": {
"$type": "OwnedBundleElement"
},
"name": "Subsystem",
"$type": "SingleOwnedIssueCustomField"
},
{
"value": [
],
"name": "Affected versions",
"$type": "MultiVersionIssueCustomField"
},
{
"value": null,
"name": "Fixed in build",
"$type": "SingleBuildIssueCustomField"
},
Since the fields themselves are of different types, their values differ as well, so you might indeed see different structures in the API response.
Julia, thanks for your continued correspondence. OpenAPI is still rather new to me, so I want to make sure I understand. The particular software I'm using is very specific about the validity of the response, where other software doesn't necessarily care or validate the response.
In your OpenAPI 3.0.x-based spec itself (available via /api/openapi.json in our YouTrack 2024.3.44799 instance), IssueCustomField defines “value” property to be an object, and only an object.
"IssueCustomField" : {
"type" : "object",
"properties" : {
"id" : {
"type" : "string",
"readOnly" : true
},
"name" : {
"type" : "string",
"readOnly" : true
},
"projectCustomField" : {
"$ref" : "#/components/schemas/ProjectCustomField",
"readOnly" : true
},
"value" : {
"type" : "object",
"readOnly" : true
},
"$type" : {
"type" : "string",
"readOnly" : true
}
},
To my knowledge, OpenAPI 3.0.x doesn't permit multiple types for a property (though OpenAPI 3.1 apparently does). Thus I guess my question to you is how can the value property represented as a string, or array, or null, be valid against your own specification?
Hi G. K.,
As I can see,
IssueCustomField
is then extended by schemas likeSimpleIssueCustomField
, but thevalue
property seems to be defined asobject
there as well. Before we look into the validity of the specification, can you please let me know how you use it and how thevalue
definition causes issues?Hi, Julia. Essentially, I'm using an ETL application which offers OpenAPI support. It lets me access parts of the response and manipulate them as necessary for further processing. It's quite powerful, but it expects (requires, really) the response to be completely valid against its' specification.
I can work around the issue as long as your specification remains based on OpenAPI 3.0 by removing the "type":"object" property from the value definition. Presuming I'm right in my understanding (I do certainly leave open the possibility that I'm wrong!), then I imagine if/when you update to OpenAPI 3.1 your specification will specifically define these value variants of other types.
G. K., thanks for the reply! I imagine the application shows some kind of error when it encounters an invalid response violating the specification - would it be possible for you to share some screenshots of that? This will help our developers analyze the issue further.
In the meantime, if you can make the necessary changes to the OpenAPI specification locally, we'd encourage you to do so as it seems to be the most straightforward way to unblock working with the tool.
Hi, Julia, please pardon the delayed response. Here's a screenshot showing the validation errors shown by the application I'm using. As you can see the complaint is about value being an array or null (string is also a problem as well, though it's not shown in this particular screenshot).
Do you have another tool you use for response validation? If so, what is it? Is there one which says such a variety of value property types is valid against YouTrack's OpenAPI 3.0-bsaed specification?
We don't usually recommend any specific tools as we cannot guarantee reliable functionality of any third-party products. Regarding the errors from the screenshot, would it be possible for you to also share the name of the tool and the exact request that results in validation errors? In case that's sensitive info, feel free to submit a ticket to share it privately: https://jb.gg/ytsup.
Julia, I have opened a ticket to share my answers privately.