I have several issues which should have been resolved some time back. I want to close and resolve them now, but do not know how to properly backdate the Resolved date. it is important for reporting purpuses and GH charts.
I know I'm hopping onto an old thread, but this was the first page I came across when searching for an answer.
This turned out to be a very straight forward fix in SQL. The resolved date is stored in the dbo.jiraissue table.
I updated the resolved date on mine by executing the following:
UPDATE dbo.jiraissue SET UPDATED = '2013-05-23 12:19:22.087', RESOLUTIONDATE = '2013-05-23 12:19:22.127' WHERE pkey = 'CCSP-455'
Just change the pkey to the issue key that you're trying to update. The update didn't require any re-indexing nor did I bring Jira offline (rebel!).
Hope this helps anyone doing the same search as me.
UPDATE FOR JIRA 6.1+:
It looks like they deprecated the pkey identifier starting in Jira v6.1. This is the new query I ran to accomplish the same in the new version:
UPDATE dbo.jiraissue SET UPDATED = '2014-02-03 14:07:22.087', RESOLUTIONDATE = '2014-02-03 14:07:22.087' WHERE PROJECT = 10104 AND issuenum = 44
It may take some searching for you to identify the PROJECT value.
Remember that this is only appropriate for imported issues that don't have a history entry for when the resolution changed from <null> to <something>
If you have history records, then hacking the resolution date will make your data inconsistent nonsense.
You can't. The resolved date is derived from the last time you resolved the issue, which you can't alter.
Of course, there's always hacking - in this case, you'd need to use SQL to change the date on the changegroup (and I think you'd need to alter the os_workflow too). That does require backups, downtime and re-indexing though (never alter a Jira database while it's running. Just. No. Never), and will destroy the information about when your users actually resolved it.
I was thinking you could go in to the workflow and do the modification that way. Create a new field put it on the transistion. Then as a part of the post workflow actions, have the Resolved date copy the date of the field you just entered.
(Added in later) But make the transistion go back to the same step it was previously ie. New - New, Open -Open, etc> You will lose the last updated date but at least you get your Resolved data back
Also then to protect yourself, go back and make sure that you or the jira-admins are the only people who can see that workflow option.
No. Generally, that is a very good approach and exactly what I'd do. Looped transitions are immensely useful to get around the weakness in "edit" permissions. It's just that for this one field, it's not right - because it's derived field, you don't need to touch it - and in fact, you can't. It'll take its value from the changed change history.
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
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!
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