Refreshing GreenHopper version statistics

[Matt Bates]

I've discovered that GreenHopper doesn't adjust its version statistics (e.g. Version Time Estimae/Time Spent/Time Remaining on the planning board) when an update fires a custom event, so I've removed all use of Custom Events from our workflows in order to try and keep our burndowns right, but it seems that there is no way to clean up historical data without toggling the fix version of every single issue.

Someone has just come to me with a burndown covering a four month release cycle that is showing 1063h remaining when running a filter shows 5 tickets with 19h 15m remaining. Understandably several people are now converned that other project burndowns may be similarly nonsensical. Note we use burndowns at the release level AND at the Sprint level,

So: Is there any way to force GreenHopper (5.4.2) to recalculate all its statistics for versions?

[Nicholas Muldoon]

Hi Matt,

GreenHopper has a specific release procedure to capture information for historical burndown charts. This includes the use of the GreenHopper Released Version History field which captures which versions an issue was previously in.

It sounds like your custom event was not triggering the addition of the required versions in the GreenHopper Released Version History field. Perhaps you can bulk update that field for the necessary issues.

Thank you Matt.

Regards,

Nicholas Muldoon

[Matt Bates]

1) Blaming others for GreenHopper not working with standard Jira functionality is pretty unattractive (especially when you have to go to an effort to ignore custom events).

2) The Released Version History is not available to be viewed in the issue navigator, update by bulk edit, and is ingored if added to a screen (update or view). I assume this means its derived and can't be updated.

3) In this specific case no issues are returned by any searches that specify a value for RVH in the affected project so I believe it can't have any affect on the statistics being generated.

[Matt Bates]

I've tried manually triggering the various GreenHopper Listeners by firing an Issue Update Event for all Issues in the affected project but this doesn't seem to have had any effect.