I switched our project to Simplified Workflow and then removed the statuses not needed but now the Sprint Report is all messed up because of this. I can "repair" this by putting the old statuses back so the statistics are correct but then those statuses also show up so they can be used by people and i don't want that.
Is there anything i can do about it ?
I used to use my own workflow in the Greenhopper (rapidboard), everything was working fine. We have completed many sprints with that workflow. When you finalize a sprint in Greenhopper it "freezes" which issues were done and which not and that list is created from the workflow like what state makes an issue complete and so on. Because i have changed to the new workflow (simplified) then the Sprint Reports wants to use the old information which is not available anymore because those statuses are gone so the sprin reports/burn down charts and velocity charts are all messed up.
It seems that after all those reports eventhough finished are still using information from the workflow so if you change it then all your historical data are "destroyed".
The only way i can have my old stuff ok that is to leave the new statuses in place which is not what i need because i WANT to get rid of them and change to the new ones.
What i wish was that i could change the status of the old ones to the new ones so that all the old data would be ok but i there is no support for that in Greenhopper so i am asking for help.
Hope this made it more clear.
I think there was a bug with this in previous versions of GreenHopper because we were using status ids rather than names. I think if you use the latest version of GreenHopper with JIRA 5.2 this won't happen any more as long as your new workflow still includes statuses with those names. Could that work?
Nice to see you around ;)
Unfortunnately this is still a bug in the latest Greenhopper 6.0.8 which we are using.
It's extremely easy to reproduce:
You say in your last line "as long as your new workflow still includes statuses with those names". That's exactly what i would like to avoid. If this is the case then everytime you change statuses in a workflow you need to keep the old ones which means that the user will be able to use them. That is no go for me. As i pointed out, if i keep the old statuses together with the new ones the historical data is ok but again not a solution i can use.
I would be happy if there were some kind of work around before (if) you fix this. I guess the best fix would be to warn the user when he removes a status which is used in historical data and that you give him the option to fix this. One would need to state what the old statuses are in the new workflow.
I just hit this issue in JIRA 6.0.5 with GreenHopper 188.8.131.52 - after migrating our JIRA issues to our new workflow, my Sprint Velocity report looks very, very bad. Before the migration our completed exceeded our committed for the last half-dozen sprints but now our completed reporting as a tiny fraction of our committed for all completed sprints. This is very, very bad.
I'm guessing I need to write some SQL to fix this issue since there are no responses since November of last year...?
Any help would be greatly appreciated.
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...
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!
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