Refreshing GreenHopper version statistics

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?

2 answers

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

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.

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.

Suggest an answer

Log in or Join to answer
Community showcase
Teodora [Botron]
Published Thursday in Marketplace Apps

Jira Inferno: The Nine Circles of Jira Administration Hell

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...

239 views 0 11
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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot