filtering with milestone and component may give wrong results

[Markus Pelkonen]

Trac & 3rd components may change milestone name or component name without writing that to ticket_change. This in turn messes the graph if filtering is used for milestone or component. For details, see my post ​Trac#5658.

This is unpleasant news to scrum people using my plugin. A workaround is

• not to retarget tickets when closing milestone but moving each ticket manually from ticket page

• not to use webadmin to milestones

• not to change component names (ever)

Please feel free to document any other similar cases.

Unfortunately there is no good fix for this problem. The original idea of using ticket_change has to be probably abandoned. Other possible approach could include (not tested):

• writing set of listeners (ticket, milestone and component) and ensuring that history is properly written
• using traditional burndown plugin approach: taking snapshots of estimates and totalhours at certain times (however, only polling would be 100% reliable due there are no listeners for all kind of events which would end up with unreliable graph)

[Markus Pelkonen]

I have now run few projects with my plugin. I found it quite easy fix ticket history with SQL, if milestones or component names are changed. However, I've done those manually... Still, be carefull - bad place to go to tell to ur boss (who has seen the burndown graph eralier) that i messed the data, now we would need SQL/Trac expert to fix this :)

However, retargeting tickets when closing milestone (sprint), can't be fixed if made, untill u remember all id's, which were open before retargeting... Thus, be extremely carefull when closing milestones - and move each ticket separately (by hand). Well, this is good practice in general in sprint demo / planning - if u had backlog items open, that's good discussion source for retrospective..