Making sense of the values of fields from get issue REST API

[aaron]

I am trying to get the fields that display as part of the default issue view in jira, using the GET /rest/api/2/issue/{issueIdOrKey} API.

As far as I can tell there is no way to get exactly what I'm looking for via the API, so the closest thing I can find for this use-case is passing in ?expand=editmeta to get the edit issue metadata, which is supposed to show fields that are editable on the issue screen, and therefore viewable on the issue screen. While this response does not contain any ordering information, it seems like the best I can do.

I tried to use the expand=renderedFields parameter to get similar information, as the documentation seems to indicate passing this in will give me back values for fields as they are rendered on the issue screen; however, 90% of the fields have a value set to null even though those fields are very obviously displaying a value on the issue detail page. As far as I can tell renderedFields does not actually give you any information about fields as they are rendered unless the field is a date field, or a rich text field, but this is just a shot in the dark observing the API response as there is nothing that indicates this is the case in the API documentation.

The problem with the editmeta path that I'm hitting is that the data returned back on the actual fields property does not make much sense in many cases. I don't understand how many of these fields are going from the values the REST API is returning to what displays in Jira. 

Here are a few examples:

customfield_10000: This field is named "Development" (the description of the field in the field configurations screen is "Includes development summary panel information used in JQL"), however it is not visibly displayed or editable in any context that I can see, and it either never has a value or is simply set to "{}". What is the meaning of a value of "{}" for this field, and what does it translate to in the view issue context?

customfield_10021: This field is named "Flagged", however it's value is set to "Impediment". In the view issue screen, there is nothing resembling "Impediment" displayed anywhere in the UI. "Flagged" is displayed, however. Am I just supposed to know that for this exact custom field that the display value is actually the field name instead of the field value?

customfield_10019: This field is named "Rank", and it's value is set to something that looks like "0|i0002n:". Again, I cannot find this field displayed in any context on the view issue screen, and the value of the field does not seem to be anything that can be interpreted by a human.

Further adding to the confusion, when I look at my field configurations, all 3 of these fields display as not associated with any screens. If this is the case, why are they even coming back when I am asking specifically for fields that are associated with the edit screen for this issue?

[Nic Brough -Adaptavist- · Accepted solution]

These are all "system" fields, ones that are sort of background (and injected by Jira Software)

The Development field is not really a field, it's a way to display a load of data from linked development systems.  Technically, there's nothing in it really, it's a panel display.  {} simply means "nothing there"

The flagged field is an on-off switch.  It's either empty or contains "impediment".  But the display is a flag on issues on boards, not a field, and shown as "flagged" in other places (the impediment value is historic)

Rank is a field that indicates where an issue is in the global list of issues.   Its value is sortable, but it's not really for direct read by humans, it only really makes sense when looking at it in the context of a list of many issues.

None of these three are on screens, the system renders and uses them internally, it's not up to the humans to decide where they appear.

[aaron]

I see, is there any way to determine that a field is a system field other than just hardcoding to ignore these field ids? And are the field Id's constant across jira cloud instances?

Is there a way to get the call to not return these fields as part of the editmeta? It seems like they should not be returned if they are not a part of the edit screen for this issue.

[Nic Brough -Adaptavist-]

Not from the field names I'm afraid.  System fields have names rather than customfield_##### but a lot of apps and applications add custom fields then treat them as system fields.

Field ids are not consistent across cloud or server.  

You can't supress them from the editmeta if they are enterable, no.  that's the point of it - finding out what you could set.  Best you can do is ignore the ones you don't want to set.