How to handle option2
Field Type in Jira’s Get Issue Metadata Endpoint (Tempo Fields)???
Hey Atlassian Community,
We're encountering inconsistencies with field types in the Get Issue Metadata endpoint, particularly when working with Tempo fields. For example, in the response below, the field type for io.tempo.jira__account
is option2
:
{
"allowedValues": [
{ "id": 2, "value": "Team Technologies - Internal Costs" },
{ "id": 309, "value": "BDO - RPA - RPA_Acceptance -- 1711234" },
{ "id": 292, "value": "Schreder Testing - Implementation -- 1559461" }
],
"hasDefaultValue": false,
"key": "io.tempo.jira__account",
"name": "Account",
"operations": ["set"],
"required": true,
"schema": {
"custom": "com.atlassian.plugins.atlassian-connect-plugin:io.tempo.jira__account",
"customId": 10030,
"type": "option2"
}
}
The issue arises when making a Create Issue API call—
option2
need to be sent as a key-value pair (e.g., "io.tempo.jira__account": 2
).option
must be sent as an object (e.g., "customfield_10030": { "id": "2" }
).This makes it difficult to handle field types dynamically, especially for plugins like Tempo.
Question:
What is Jira's recommendation for handling such inconsistencies in third-party plugin field types??? Is there an official guideline on how to determine the correct payload format based on the schema type???
Would appreciate any insights from the community!
TIA