Picking the right fieldKey in /rest/api/2/field/{fieldKey}/option

Hi @kkercz,

Fair play for creating that JIRA issue. I have voted on it and I hope it gets many votes. I agree with the comments of the other frustrated developers above. This API is misleading from a REST point of view. It’s a real disappointment when it becomes apparent that what is documented can’t be done.

In terms of usefulness- our department at Guidewire Software are evaluating JIRA as a replacement for CA-Agile Central. In CA-Agile Central we had the ability to manually paste all options at once into an option field, when creating manually from the UI. The options we pasted were newline separated. In JIRA, we must create these manually from the UI, which is a big negative towards JIRA versus CA-Agile Central.

We were hoping that the REST API could come to the rescue and provide us a way of programmatically editing our custom fields. But now that hope has been dashed. The ability to manage custom field options via the public REST API would probably be a must have for us to make the switch.

Cheers,

Colm

1 Like

To be fair, the documentation does say that the endpoint is supposed to manage options for issue fields. And there is a link to the issue field Connect module. Implicit assumption here being that issue fields are different from custom fields. But I can see how this can be confusing. We will work on making the description more clear. Thank you for all the feedback.

Ah OK. Thanks @kkercz for clarifying. Yes that is the confusing point- the difference between “issue fields” and “custom fields”. It may be too subtle of a difference for a lazy human like myself to understand :wink:.

A clearer description would definitely be great, but it would probably just be shifting the disappointment to an earlier point in the discovery process. Instead of seeing the docs and saying “Cool! I can do CRUD on the options entities via the REST API!” and then being disappointed when it doesn’t work, people may simply feel that same disappointment now when they read the docs and it says “You can’t do CRUD on the options entities. You can only do this on issue fields which have been added via a Connect app through its JSON descriptor.” They might think “Oh no, this is very limited behaviour. I want to be able to dynamically, programmatically, manage these things. Having to specify them in a JSON descriptor in advance is too restrictive.”

For me anyway the real disappointment is that CRUD operations on options entities are not available.

1 Like

Just want to +1 @cbhandal’s comment. My mental model is that a ‘custom field’ is any field I define. I still don’t quite get the distinction between that and an ‘issue field’. It might be more clear if they were called App Connect Fields or something that didn’t use words that already have specific meaning. That ship has sailed though, but just having CRUD operations as the UI does via REST would be enough to get me out of the bind I’m in with Jira.

Just want to chime in and say I want exactly what several others in this thread want, to keep an option list in sync with an external system. Having to do this by hand every day in the UI is quite painful.

Very disappointed to find out that even though you can create new custom fields using the API, you can’t add any field options to those with the only response being a non-descriptive HTTP error status 400.

This issue completely blocks us from adding two additional field types that users can use in the app we’re developing while everything works well in the Jira Server version of the app.

I’m also scratching my head because in the Jira cloud rest api documentiation it clearly states that for connect aps you need to read this section:
V2
https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-custom-field-options--apps-/

V3
https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-custom-field-options--apps-/

But I could not get a regular GET request to work with a manually created customfield in a Jira cloud project. (Fieldkey invalid)

Meanwhile a post request with json data based on the example will result into:

{ resCode: 400,
  resMessage: 'Bad Request',
  resData:
   { errorMessages: [ 'No content to map to Object due to end of input' ] } }

Found out that httpclient.post does not use “data” as parameter key but “json”. That fixed the issue above.