Changelog histories -- no custom field IDs, only changeable names (big hole) - fix?

[Chris Lenzini]

Hello there --

I know in the Jira REST API Endpoint /search?jql=updated>2018-01-01&maxResults=50&expand=changelog

Just an example but -- they have the current fields and custom fields of Jira tickets. Including the field ID, field name, value ID, and value name.

HOWEVER, the historical changelog (not current field values) ... they only display the current field name --- the field ID is nowhere to be found. Here's an example with a random custom field "Epic Link" -- the field ID is nowhere to be found. Is there a way to include this in the REST API request?

As you can probably see coming, this presents a challenge when a custom field name CHANGES. In our example, if you are querying this data, you would query "Epic Link" ... when the name changed (to Epic Links or anything stupid), the data query would be broken. Really a field ID should be present here, but it's glaringly omitted.

I guess there can be some roundabout work-around that you fetch every custom field ID and name daily --- and then when querying, instead of querying by Field ID, you reverse fetch the known field ID back into all historical field name values and return all of those.

Obviously this workaround is messy -- the JIRA API has a glaring omission here --- but anyone else dealing with this? Is there a better way?

[Sabina Heim]

Hi @Daniel Eads ,

Is there an open issue on jira.atlassian.com for this? This is really a huge problem, especially because the REST API doesn't give you the untranslated field name. So if we have two custom fields with the same translated name but with different untranslated names, we have no possibility to distinguish those two fields. It is not possible to use the REST API for any system integrations if it works like that. Ideally, we would get the ID and not the field name.

[Daniel Eads]

Hi Chris,

Luckily the example field you used ("Epic Link") is a Locked custom field. It takes quite a bit of work to rename one of these fields. Under normal circumstances, this and other fields used by Jira Software won't see random renamings by a haphazard application administrator.

Agreed though that having the custom field ID for other fields in the changelog would be beneficial. I believe it's only using the field name currently because of readability. Just getting the fields through a regular /search or /issue query will yield something like customfield_10058 instead of the field name, which you noted is significantly more safe to rely on. It's only in the changelog specifically that you'll see some possibility for disruption.

We don't currently have an open issue on jira.atlassian.com for this. If you are concerned about some custom fields that aren't Locked, let me know and we can open an issue.

Thanks,
Daniel

[Chris Lenzini]

Hi Daniel -- that was just an example but actually not the custom field in question.

I can come up with a work-around for now which amounts to either having a daily/ weekly data pull of the 'current fields' in Jira through the fields endpoint, which has the current ID/ current name. An 'up/sert' statement will essentially keep a separate changelog of field names outside of Jira (currently Jira doesn't have any field changelog that is possible --- old field names have no direct connection to either the immutable field ID or the new field name).

That would be a work-around. As well as an imperfect but practical approach of seeing what fields have historically had the same 'value' options available.

This is probably a niche case --- but still, following normalization practices, the ID should be saved in the changelog. And of course there is already a table that has field ID - current field name. The old name doesn't really need to be saved -- they are subjective descriptions of what should be a somewhat stable idea.