Is it possible to edit the transition date so reports are accurate?

James September 14, 2014

I want to be able to override the current date/time recorded for a transition - our teams sometimes forget to update an issue, so although the real life state is 'Done', Jira thinks it is still 'In Progress'. When someone notices, the issue will be moved through the workflow to 'Done' is the space of seconds, so none of the transition dates reflects what actually happened. Consequently reports such CFD will be misleading and therefore not useful.

Being able to override the transition dates with a correct date would fix the problem.  Is this possible?

2 answers

1 accepted

0 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 14, 2014

Not natively.  The code is recording what it's told, the proper "fix" for this problem is for your teams to do their job properly.  Inaccurate CFDs tend to point at broken process rather than bad data.

You could try scripting something with the script-runner plugin for one-off data mangling, but you'll need to write a proper full plugin to hack the data directly if you want some form of button or edit option.

James September 14, 2014

Thanks for the answer, I'll look into creating a full plugin. I'd contend however that the teams *are* doing their job properly (they're delivering high quality software regularly and reliably and have been for 6+ years); using Jira is not a primary part of their job because the ultimate source of truth is the board next to their pod with cards all over it. Even if it were something the team had a responsibility to do accurately, mistakes still happen - not being able to fix these does seem like a significant constraint. Deming would not blame the team for failing to follow the process, he would expect the process to change to allow for human behaviour. Perhaps an alternative fix is to distinguish between audit date (when a transition was effected) and the date the transition actualy happened (which may or may not be the same). It seems like audit date has been misused to represent something else in order to create reports.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 14, 2014

When our CFDs went wrong, we did the obvious thing - stated that the electronic boards were the source of truth. It's a bit of a jolt for users, and I wouldn't try it on anything lower than Jira 6.2 because the boards aren't really quite there until later versions of Jira. The other option is what Joseph suggests - a separate field.

1 vote
Joe Pitt
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 14, 2014

A work around would be to add a field for the transitions. That also allows easy before/after searches. We capture the dates of milestone transitions in a separate field for that reason. It is human nature it seems to 'leave the paperwork till the end'. I know it gives a false picture of progress to management, but shy of giving people fines or days off without pay it is hard to stop. You might try a small, $1, fine for anyone not executing the transition and use the money for donuts at the end of a sprint. Keeping everyone's running total fine on a public board may help too.

James September 14, 2014

Fields might work, but that adds an overhead to each project. Can the CFD reports be driven off custom fields, or do you munge the data in Excel? None of this is used to report progress, so it's not a question of misleading management but rather a missed opportunity to provide data to the team which could help them improve.

Joe Pitt
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 14, 2014

I'm not familiar with the CFD report, but I presume it is a build in report so the only way to change how it works would be to modify the base code, which I don't recommend as you'll need to maintain that modification forever going forward. I believe this is really a training and management issue. People need to see maintaining the correct JIRA status as part of the overall job just like adhering to coding standards. It is like forgetting to hand in your homework on time even if it was done and wanting the teacher to take it anyway for full credit.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 14, 2014

My 2p worth - yes the CFD works off the data in system fields. I really do agree with Joseph on this - the best option is to get your users to use JIRA properly, not mess around with two boards. The whole point of an issue tracker is to keep track of stuff, ideally in a transparent and visible way. Sticking notes to a board breaks that, and maintaining information in two separate disparate places simply does not work.

Suggest an answer

Log in or Sign up to answer