alainlompo alainlompo - 1 month ago 11x
Groovy Question

migrating from jira soap api to jira rest api: issues with getCustomFieldValues

I am working on migrating some code from Jira Soap Api to Jira Rest API. I have a line of the legacy code that looks like:

String estimationTypes = issue.getCustomFieldValues().find{it.customfieldId == SOME_STRING_VALUE_HERE}?.values.toString()

variable is of type
and I am trying to migrate it and use an implementation of the new
interface (
), and so I am looking for an equivalent of the
method that is defined as

public RemoteCustomFieldValue[] getCustomFieldValues() {
return this.customFieldValues;

But I did not find it. the Issue interface defines the
Object getCustomFieldValue(CustomField customField)
which is not the same. So how could I use a method equivalent to

I guess if I had a method like

List<CustomField> getCustomFields()
then I would be able to create a method: something like

public List<Object> getCustomFieldValues() {
List<Object> result = new ArrayList<>()
List<CustomField> customFields = getCustomFields()
for(CustomField cs: customFields) {
return result

My goal is to make the migration with the minimum possible impact on the legacy code. There I would like to be able to mimic the behavior of the legacy code as much as possible. Any help or indication is highly appreciated.


After a lot of research and curling in one of the most interesting APIs I ever used, I find some very usefull informations on Atlassian knowledge base here. The text is targeting a multi - select custom field but is usefull for other types of custom fields as well.

It mentions clearly that JIRA's REST API doesn't provide a method to simply retrieve all the options available to a multi-option custom field. The approach used here is therefore considered a workaround. So we can use

  • The create issue meta api (here)
  • Or the edit issue meta api (here)

Showing the custom field allowed values

Following the two meta apis links, the parameters from the create meta api are simple but in the case of the edit meta api there is one request parameter called overrideScreenSecuritythat is related to add-on users and a direct access to the add-ons market place from the web interface, but does is not relevant in my case and the default (false) value is fine for me.

From here I can parse the json to get the values