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

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
Accepted answer

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.

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.

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
Joseph Pitt Community Champion Sep 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.

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.

Joseph Pitt Community Champion Sep 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.

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
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,265 views 5 10
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