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 Sign up to answer
Community showcase
Published Feb 26, 2019 in Jira Software

How to prevent the propagation of unused project schemes, workflows & screens in Jira software

Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...

600 views 0 7
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