Any harm in updating resolution and resolutiondate in the database?

I'm looking to run a report of open vs. completed issues, and the "created vs. resolved issues" gadget is basically exactly what i'm looking for. However, when I ran it, i found that there were very few resolved issues. It turns out that there are 3 ways to get to a status of "closed" and only one of them sets the resolution as part of the transition. Therefore, I'd like to update the resolution and resolutiondate for the remaining issues. I'll use the "updateddate" for resolution date, as *typically* the last update was to close the issue.

So, my question is, is there any risk if I update these fields in the database? Will I be breaking some connection I don't know about?

3 answers

1 accepted

1 vote
Accepted answer

Don't do this in the database. If it's *just* resolution to change, it won't be too bad - you just need to stop jira, backup the database, prove the backup is good, run your sql, restart and re-index Jira, and explain to your users that there's a bit of missing history.

But the script runner is a far better idea - it uses the API, so Jira is aware of the changes and hence handels the database persistence, cache updates and indexing for you.

For what it's worth, the "date of resolution" is a derived field - you don't need to think about updating it yourself, although I'd very much recommend making sure the issues are reindexed (Again, if you go via the API with something like the script runner, you'll be fine)

I understand that Date of Resolution is derived, but it sounds like it'll be set to the date when I make the update with script runner, not the date that the issue was actually closed. Therefore, my created vs resolved chart will be wrong.

It sounds like I'm just SOL on past issues because the workflow wasn't set up correctly on day one, and I'll just have to live with it.

Hi Justin, I am facing the same issue, where I just want to modify resolution and keep resolution date. Where you able to do this from db. I will try on my dev jira, but I just want to check if you have any recommendation. Thanks Nelson

The recommendation remains "don't do it". If you must take the risk, then make sure you've got a backup, and JIRA is offline when you do it. You'll need to alter the id values held on jiraissue, and you probably want to add some history records to say "we botched a resolution change in the database" too - generate changeitem/group lines for them and don't forget to update the sequence table. Do a full reindex after restarting Jira too.

It seems like the Bulk Fix Resolutions script in the script runner plugin ( will get me what I need, but I also need to make sure that the date of the resolution is correct. Does anyone know how this script sets the resolutiondate field?

I also tried this several years ago and it caused my Integrity Check to fail because Jira recorded the new resolution and status but since it couldn't report how it got there, it cause the status to show correctly but still show workflow actions for where the issue was previously (Jira 4.3.4)

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,711 views 17 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you