New REST API: getting custom field values

You can get the custom field names using the query {base url}/api/admin/projects?fields=id,name,fields(id,bundle(id,name))

where the name is stored in the bundle.

I've got the same problem. I'm using the following syntax

?fields=fields(id,projectCustomField(field(state),value(state)))

and my response looks like

{"projectCustomField":
{"field":{"$type":"jetbrains.charisma.customfields.rest.CustomField"},"$type":"jetbrains.charisma.customfields.complex.enumeration.EnumProjectCustomField"},
"id":"62-50","$type":"jetbrains.charisma.customfields.complex.enumeration.SingleEnumIssueCustomField"}

"state" is the name/id of the custom field. What am I doing wrong?

Thanks for your help,

Andreas

@Andreas, You need to enter in the following query (exactly as-is, don't replace "name"):

?fields=fields(projectCustomField(field(name)),value(name))

Unfortunately, it looks like this will always return a list of all custom fields and their values.

@Liubov, Is there a way to just get one or two custom fields and preferably without all the type information? Because we have a lot of custom fields in our project, I'm getting a 10KB response when I just need the value of one custom field. >.<

@libov

You mentioned:

>inside `value(...)` you need to specify those values that you need, for example, `value(name,login)`

What if the field is of "jetbrains.youtrack.timetracking.periodField.PeriodIssueCustomField" type? How do I extract the integer value of it? Sorry, can't find field values part in the documentation.

Figured it out just by trying different words...

value(minutes) worked for Period field type

for text fields, it's value(text) after some trial and error

Hello all,

I'm very sorry for the long delay.

@Fool Running: no, unfortunately, you can only get all custom fields. Type information is always present in the response.

@Michael: we've published more documentation for the new REST API, so you can find the supported fields for all entities there: https://www.jetbrains.com/help/youtrack/incloud/api-entities.html

However, please note that this documentation is not in its final state yet, it is constantly being improved and polished.

Let us know if you have any further questions, here or via a support request: https://youtrack-support.jetbrains.com/hc/en-us/requests/new?ticket_form_id=66282

I am sorry to resurrect the old thread, but can you please confirm that it is still (in 2019.2) not possible to get just a subset of custom fields value? I have tried to understand the documentation, but it's not simple. From what I gather here:

https://www.jetbrains.com/help/youtrack/standalone/api-howto-get-value-for-specific-cf.html

I can get a value of single custom field from a single issue.

Alternatively, I can get all custom fields from a list of issues following the guidelines in the thread above. However, I believe the most common use case is to get a list of issues with only some field values - in the old REST API it was done via the "with=" parameter. It is difficult to understand why the new API does not support it.

Hello Martin,

sorry for the delayed response.

Unfortunately, it's not possible to get a list of issues with a subset of custom fields with the new API as well.

There are the following possibilities:

- you can get a list of issues with all custom fields: https://www.jetbrains.com/help/youtrack/standalone/resource-api-issues.html#get_all-Issue-method

- you can get a single issue with all custom fields: https://www.jetbrains.com/help/youtrack/standalone/resource-api-issues-issueID-customFields.html#get_all-IssueCustomField-method

- you can get a single issue with a value of a specific custom field: https://www.jetbrains.com/help/youtrack/standalone/operations-api-issues-issueID-customFields.html#get-IssueCustomField-method

Hello Liubov,

Thank you for your reply. We can live with returning all custom fields, but even worse problem is the structure we receive. It is:

"projectCustomField": [{"name": <field name>, "value": {"name": <field value>}}, ....]

That is, the custom fields are returned as array (or list) and the only way how to find the value of the custom field I am interested in, is to iterate over all elements of the list and inspecting the name property. Is there a plan to make this behaviour more consumer friendly in the future? What is the rationale behind this behaviour?

Thank you.

Hello Martin,

could you please elaborate a bit here, why do you consider it unfriendly? As far as I understand you, it's OK for you to get a response with all custom fields, but it's not OK when you need to iterate over all the elements to get a particular field value?

This behavior is based on a hierarchy of custom fields that we have in our REST API as well as on the whole entity schema. You can learn more about general approach to custom fields in our REST here: https://www.jetbrains.com/help/youtrack/incloud/api-concept-custom-fields.html

Hello Liubov,

The hierarchy you describe is good when I want to retrieve the information about the custom fields in general, i.e. when I want to find out what custom fields there are in a project, and what are they properties. I am not sure about the other users, but we usually know the names and types of the fields we want to retrieve, so that is not a typical use case.

Instead, we want to retrieve fields that correspond to some query (e.g. created today) and access some of their properties (e.g. Complexity). So I would expect to be able to issue query like:

...youtrack/api/issues?query=...&fields=idReadable,customFields(Complexity)

and receive JSON like:

[{"idReadable": "PROJ-1","customFields":{"Complexity":1}}, ...]

If I am receiving 1000+ issues, I don't need to include information about field type, value type and so on for every single one of them. In this manner I can also access the value I am interested in directly: issue.customFields.Complexity instead of having to iterate over a list of custom fields. This seems to me like a trivial and immediately obvious approach and I am sure that you have considered it. I would be more interested in finding out why it was rejected.

Hello Martin,

do I understand you correctly that you get too much information and that is the problem?

The reason why we don't officially support this sort of filtering is that we're not ready to support it for all kinds of YT configurations.

When you're making a request, there is no difference for the script as to how much data to retrieve, so the output contains all data.

We're sorry that this causes you inconvenience. Let us know if you have any other questions, we'll be happy to clarify.

Hello Liubov,

It's not so much the amount of information as its structure. Consider the following pieces of code:

let sum = 0;

for (let issue of issues) {

  for(let field of issue.fields {

    if(field.projectCustomField.field.name == "Complexity") {

      sum += field.value.name;

      break;

    }

}

in contrast with this:

let sum = 0;

for (let issue of issues) {

      sum += issue.fields.projectCustomField.Complexity;

}

I think it's obvious what's more convenient, not to mention faster.

I see your point, thanks for clarifications. The option to filter the response and narrow it down to a subset of custom fields (or simply one field) is a nice feature to have indeed. Unfortunately, this feature is not of the highest priority for us at the moment, so we can't give any estimations or even promise that it'll be implemented.

Anyway, please feel free to submit a feature request in our tracker here: https://youtrack.jetbrains.com/issues/JT so that we could see if there is demand for this. Thank you very much!

For anyone who comes to this issue via Google, I created the request there:

https://youtrack.jetbrains.com/issue/JT-53876

Thank you!