How to Retrieve the Original Value Entered in a Custom Field During Issue Creation

[sundeepkothurthi]

Hi Team,

We recently encountered a situation where data from a custom field was lost due to an incorrect field merge.

We are trying to determine whether it is possible to retrieve the original value that was entered into a custom field at the time of issue creation.

We have already checked the History and Activity tabs, but we're looking for guidance on the following:

• Is there a way to view the value that was originally entered into a custom field when the issue was created?
• Can this information be retrieved from the issue history, activity log, audit log, or any other source?
• Are there any Jira or ScriptRunner methods to recover the initial custom field values after they have been overwritten?

Any suggestions or recommendations would be greatly appreciated.

Thank you!

[John Funk]

Hi Sundeep,

If there is no entry in the history for any changes to that field, then the current value in the field is the value that was entered when the work item was created. 

[Sami Shaik]

Hello @sundeepkothurthi , the good news first: if the value was entered at creation and later changed by a person or a bulk operation, the original value is still recoverable. Jira does not store a separate "as created" snapshot, but it stores every change as a from and to pair, and that is enough to reconstruct creation state. The logic that matters:

The earliest changelog entry for a field contains the original value in its "from" side. So you are not looking for the creation event (there is none for field values), you are looking for the first change to that field: whatever it changed from is what was entered at creation. And the corollary: if a field has no changelog entries at all, it was never touched after creation, and the current value is the original.

Route 1, the UI (what you already did, read differently): in the History tab, find the oldest entry mentioning your custom field and read its left-hand side. If History shows nothing for that field, see the boundary note below.

Route 2, REST, the reliable way to do this at scale on Data Center:

GET https://your-base-url/rest/api/2/issue/KEY-123?expand=changelog

The full history arrives under changelog.histories, each item with fromString and toString. Atlassian has a KB with exactly this workflow, including a ready-made jq one-liner that flattens the changelog of many issues into a sorted from/to table, built for post-incident reconstruction like yours: https://support.atlassian.com/jira/kb/how-to-analyze-the-history-or-changelog-of-an-issue-in-jira/ (Note the dedicated /issue/{key}/changelog endpoint is Cloud only; on Data Center use expand=changelog as above.)

Route 3, ScriptRunner: the ChangeHistoryManager component gives you the same data in Groovy (getAllChangeItems or getChangeItemsForField per issue), which is the practical option if you need to sweep a whole project and write recovered values back: https://docs.atlassian.com/software/jira/docs/api/latest/com/atlassian/jira/issue/changehistory/ChangeHistoryManager.html

Now the honest boundary, and it matters for your case specifically. Everything above depends on the merge having gone through Jira's API or UI, because that is what writes changelog entries. If the "field merge" was performed by a tool writing directly at the database level, no history was recorded, and the changelog cannot help. The tell: the field's value is visibly wrong, but History shows no corresponding change. In that scenario you have two remaining options on Data Center: restore a pre-merge backup (XML or database) into a staging instance and read the values from there, or query the change tables in a pre-merge database copy. The audit log will not help either way: it records administrative and configuration events, not field value changes.

Quick diagnostic for you: pick one affected issue, run the expand=changelog call, and check whether the merge itself appears as a change entry. If it does, the fromString values across your affected issues are your recovery dataset. If it does not, go straight to the backup route.

[Steve S_]

@sundeepkothurthi you may want to try sending a web request via an automation rule to get the changelog of the ticket.  From there you can send that change log to your parsing solution of choice (e.g. Rovo agent, etc.).

Steps

1. Decide on a trigger, like a value change for a field.

2. Create a smart value variable (name: "key" --- smart value: {{issue.key}})

3. Send a web request GET to https://<your_site.atlassian.net>/rest/api/3/issue/{{issue.key}}?expand=changelog  (use the api basic auth and content-type headers)

4. send the {{webResponse.body}} to your preferred parse solution (e.g. a Rovo agent).

Depending on how you plan on parsing the {{webResponse.body}} will determine the rest of  your automation steps.  I recommend trying the Rovo agent, as you can then specify json guidelines and manipulate the data before Rovo hands it back.

Good luck!

[Staffan Redelius]

Hi @sundeepkothurthi and welcome to the community.

How was the merge done? Did you do it within Jira or directly in the database? As @John Funk  describes the original value should be visible in the field if it was updated.

Is it possible that the value is still available in the original field? Check if you have several fields with the same name under Settings ->  Work item -> "fields".

Best regards,
/Staffan 

[sundeepkothurthi]

Hello Staffan, Thank you..

Actually The merge was performed using ScriptRunner's Copy Field Value functionality within Jira, not directly in the database.

Unfortunately, while configuring the script, we accidentally reversed the source and destination field IDs. As a result, the issues from one custom field were overwritten, and we lost the data from that field.

We have checked a few issues in the History/Activity tab, but we're trying to determine whether the original values entered in the custom field at issue creation can be retrieved from Jira.

We also verified the list of custom fields and confirmed that there are no duplicate fields with the same name containing the missing data.

Is there any way to recover the original field values from issue history, change logs, backups, or any other Jira mechanism?