Confirm Variancy of JIRA Cloud issue field keys for custom fields

Jira Development Jira Cloud
, ,
1

Hi All,

We are recreating the Issue VIew in our jira cloud addon. However, since each field has their own renderings (html, css), we have to hardcode each field into our handlebars template.

The current Rest API for issues search can be parameterized with expand to return field names, rendered fields, etc using the same parameters as GET /issue, so we used that and were able to receive a list of issues.

Fields are included in the issue JSON like:

...
fields: {
 "status" : { .. status object here},
 "customfield_10016" : { Sprint object here }
 ...
}
...

We were working on the premise that:

  • On Jira Cloud, third party custom fields are not yet supported so we dont have to bother with making the handlebars template “dynamic” in guessing the custom fields’ field keys for other addons.
  • Jira Cloud has its own internal custom fields, like the Sprint and Epic fields, that have “fixed” keys like customfield_10016 and customfield_10010.

However, when we reached those JIRA custom fields, we found that their ids differ on every dev instance we used:
Developer instance 1:

|"customfield_10000":|"Development",|
|---|---|
|"customfield_10001":|"Team",|
|"customfield_10002":|"Organizations",|
|"customfield_10003":|"Approvers",|
|"customfield_10004":|"Impact",|
|"customfield_10005":|"Change type",|
|"customfield_10006":|"Change risk",|
|"customfield_10007":|"Change reason",|
|"customfield_10008":|"Change start date",|
|"customfield_10009":|"Change completion date",|
|"customfield_10013":|"Epic Link",|
|"customfield_10014":|"Start date",|
|"customfield_10015":|"Parent Link",|
|"customfield_10016":|"Sprint",|
|"customfield_10017":|"Rank",|
|"customfield_10018":|"[CHART] Date of First Response",|
|"customfield_10019":|"[CHART] Time in Status",|
|"customfield_10020":|"Approvals",|
|"customfield_10021":|"Request Type",|
|"customfield_10022":|"Request participants",|
|"customfield_10023":|"Satisfaction",|
|"customfield_10024":|"Satisfaction date",|
|"customfield_10025":|"Story Points"|

Developer instance 2:

|"customfield_10000":|"Development",|
|"customfield_10001":|"Team",|
|"customfield_10002":|"Organizations",|
|"customfield_10003":|"Epic Name",|
|"customfield_10004":|"Epic Status",|
|"customfield_10005":|"Epic Colour",|
|"customfield_10006":|"Epic Link",|
|"customfield_10007":|"Parent Link",|
|"customfield_10008":|"Sprint",|
|"customfield_10009":|"Rank",|
|"customfield_10010":|"[CHART] Date of First Response",|
|"customfield_10011":|"[CHART] Time in Status",|
|"customfield_10012":|"Approvals",|
|"customfield_10013":|"Request Type",|
|"customfield_10014":|"Request participants",|
|"customfield_10015":|"Satisfaction",|
|"customfield_10016":|"Satisfaction date",|
|"customfield_10017":|"Story Points",|
|"customfield_10020":|"Flagged",|
|"customfield_10021":|"Start date",|

My questions:

  1. Is this (varying of custom field id’s) the correct behavior for JIRA Cloud’s custom fields?
  2. If so, how do you suggest we handle this changing of id’s? We would still like to render them into our custom issue view, but have no way of recognizing them across every JIRA instance.

PS. We thought about using the fields’ Display Names, however, this will also change when the JIRA instance language is changed.

2

Hi, @lbermejo,

Custom fields may indeed have different IDs on every instance, this is expected.

There is the Get fields endpoint, which gives you information about all fields on a Jira instance. You would need to first call it and map IDs to field types.

For example, the sprint field the entry will look like this:

  {
    "id": "customfield_10880",
    "key": "customfield_10880",
    "name": "Sprint",
    "custom": true,
    "orderable": true,
    "navigable": true,
    "searchable": true,
    "clauseNames": [
      "cf[10880]",
      "Sprint"
    ],
    "schema": {
      "type": "array",
      "items": "string",
      "custom": "com.pyxis.greenhopper.jira:gh-sprint",
      "customId": 10880
    }
  }

As you can see, “schema” tells you that the type of the field is “com.pyxis.greenhopper.jira:gh-sprint”, which is the Sprint field custom field (this string will be the same on every instance).

Hope this helps.

Cheers
Krzysztof

3

Thanks for the reply @ Krzysztof, will try the custom type approach. I’ll update you later with what we come up with.

4

Hi kkercz,
I feel that the schema.custom for Story Points field (classic project use) should be something specific, but not generic as follows (com.atlassian.jira.plugin.system.customfieldtypes:float). Because we need the specific identifier to get the Story Point field id in every jira instance. What do you think of it?

for Story Points estimate field:
{
“id”: “customfield_10016”,
“key”: “customfield_10016”,
“name”: “Story point estimate”,
“untranslatedName”: “Story point estimate”,
“custom”: true,
“orderable”: true,
“navigable”: true,
“searchable”: true,
“clauseNames”: [
“cf[10016]”,
“Story point estimate”
],
“schema”: {
“type”: “number”,
“custom”: “com.pyxis.greenhopper.jira:jsw-story-points”,
“customId”: 10016
}
}

for Story Points field:
{
“id”: “customfield_10030”,
“key”: “customfield_10030”,
“name”: “Story Points”,
“untranslatedName”: “Story Points”,
“custom”: true,
“orderable”: true,
“navigable”: true,
“searchable”: true,
“clauseNames”: [
“cf[10030]”,
“Story Points”,
“Story Points[Number]”
],
“schema”: {
“type”: “number”,
“custom”: “com.atlassian.jira.plugin.system.customfieldtypes:float”,
“customId”: 10030
}
}