Any harm in updating resolution and resolutiondate in the database?

[Justin Corcoran]

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?

[Nic Brough -Adaptavist- · Accepted solution]

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)

[Justin Corcoran]

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.

[Nelson Carranza]

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

[Nic Brough -Adaptavist-]

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.

[Nelson Carranza]

Thanks Nic

[Derrick Taylor David]

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)

[Justin Corcoran]

It seems like the Bulk Fix Resolutions script in the script runner plugin (https://studio.plugins.atlassian.com/wiki/display/GRV/Built-In+Scripts#Built-InScripts-BulkFixResolutions) 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?