-
Suggestion
-
Resolution: Unresolved
-
None
-
75
-
21
-
NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.
Currently the REST API supports the GET method on api/2/customFieldOption/
{id}
With support of PUT (or POST) operation on that URI additional workflows would be supported.
Use Case: a system manages some mostly automatic process. When manual intervention is required the system opens an issue in Jira. Ticket resolution includes assigning a value to a field, accomplished via a Jira Custom Field. The domain of options, however, is managed by the system and any selected option must be valid within that domain. Since the system is used to add options to itself - stored in a database table - to ensure the automated parts and the Jira workflow parts work well together the sets of possible options need to stay in-sync. As part of its processing the system can create new option values within itself. Adding the ability to PUT/POST the Jira custom field option values would ensure data integrity and consistency across the automated and more manual, Jira-driven parts of the workflow.
As for needs, either a simple PUT with the full set of option values included in the request, or the ability to add and delete individual option items would work.
- is related to
-
- Closed
-
- Gathering Interest
- relates to
-
- Closed
[JRASERVER-36112] Add REST API (PUT, POST, DELETE) for custom field options
How is that even possible to not to have such feature to add/edit/remove options?
When will this be resolved? When need to delete old values in a custom field in version 9.4 Data Center!
Present we are at 8.20.12 version, We have an immediate need for this as well. Any update on an ETA?
We had been waiting and requesting this for years now. Its seems Jira PROD team never updates or reviews customer feedback. This capability is not available even in ATLASSIAN CLOUD Jira option as well.
This is a basic feature; I can't recommend the Jira product if it's not implemented. Making a customer pay $2750 to get a custom solution (script runner) to work around this obvious deficiency is just wrong.
Your customers have been asking for this for ten years... listen to them!
@Jamie Echlin [Adaptavist] ... Thank you for the update; I have used the Adaptavist example as a base and have extended it quite a bit to include additional functionality and security
Why is this only available in DC edition (8.16 and higher) and not in the standard edition?
Thanks for letting me know.
> Looks like the response is "405 - Method Not Allowed" on the POST
This is likely a client issue, perhaps you are doing it from a browser... We attempt to redirect you to '/rest/api/2/customFieldOption/' + createdOption.optionId ... so you can see the option you just created (perhaps you need the ID). It seems some clients attempt to POST to that which is not allowed, only GET is allowed.
If it's an issue replace line 84 (which is):
Response.temporaryRedirect(URI.create(applicationProperties.getBaseUrl(UrlMode.ABSOLUTE) + '/rest/api/2/customFieldOption/' + createdOption.optionId)).build()
with
Response.noContent().build()
cheers, jamie
I fully understand that it's always hard for the product team to balance customer feedback and exciting new features. However, a ticket that remains unresolved for a decade and could drag on for another is still ridiculous and unacceptable to me.