Add value to custom field (single/multi select) via rest API

[Jochen Betz]

As Jira does not support out of the box usage of versions of a different project in the service management project I decided to create a custom field reproducing the same options (versions) as in the development project.
Now, each time a new release is created in the development project I need to add this version manually in the service management custom field as an option.

I'm currently using the python jira API for some interactions anyway. But I could not find a way to achieve what I described above. But neither did I find a way to invoke the low level rest API.
What I'm able to do is to get the current possibilities of a custom field. Albeit it's already weird that one needs an issue to get to the field instead of accessing the field directly.
And as well it's unfortunate in this case, that it's not just a simple list of values but a list containing among others a unique ID for each option; which makes it impossible to just add a value - because how should we create this ID?

Thus: How can you add a new option to the "allowed Values" of a custom field either (best) via jira python or alternatively using the rest API direct?

[Lina Kuhn _TNG_ · Accepted solution]

Hi @Jochen Betz ,

The first thing that came into my mind is to use a global automation instead. You can find a tutorial here that describes how to copy versions among different projects.

If you want to solve it via REST API, I would suggest to use v3. You can access customfield options of a field via its context id (without an actual issue) using https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-custom-field-options/#api-rest-api-3-field-fieldid-context-contextid-option-get

The same way you can post new options with https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-custom-field-options/#api-rest-api-3-field-fieldid-context-contextid-option-post

The mentioned documentation contains also example snippets for python.

[Jochen Betz]

Thank you @Lina Kuhn _TNG_ for your reply. I'm currently working on using the low level access with python/request/json/rest API. Albeit it would be neither if the jira python lib would support this. Thanks for pointing in the right direction.

Especially thanks for the link to how to solve it with global automation, that's definitely a good solution to go for with new created versions.

[Jochen Betz]

As @Lina Kuhn _TNG_ was suggesting, I used global automation rules. Unfortunately the Jira API is pretty inconsistent and incomplete, even after all this years. While it has a building block to react to "version creation" it does not have a block to allow "creating version" on the other side. ANd this "pattern" occurs not just in this place. Each time you have eventually to fiddle around with Web Send Requests to the REST API.

After figuring out how to somehow use web send requests (still open question about storing the response in a variable see HERE) it turned out it was almost for nothing.
All this copy (aka duplicating, which is usually a bad idea) the versions from one project to another I was NOT able to use these in the especially designed fields of type "version picker" on forms. Why? God knows, especially is it is a known problem

So it just the creation of yet another rule, another custom field another duplication.

Conclusions: Jira/Atlassian never fails to disappoint.

[Jochen Betz]

Thanks again @Lina Kuhn _TNG_ . The global automation for simply creating a new version in project B when one is created in project A was done rather quick and works well.

The attempt to copy all versions from project A to project B using web request and rest API was a nightmare. Eventually I managed to achieve what I wanted, but not all issues solved along the way.