Jira Tempo custom fields metadata

Samrat Dutta February 16, 2025

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—

  • Fields of type option2 need to be sent as a key-value pair (e.g., "io.tempo.jira__account": 2).
  • However, fields of type 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

0 answers

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events