id,summary,reporter,owner,description,type,status,priority,component,severity,resolution,keywords,cc,release 1977,filtering with milestone and component may give wrong results,Markus Pelkonen,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 [http://trac.edgewall.org/ticket/5658#comment:7 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) ",defect,new,normal,TimeVisualizerPlugin,normal,,,,0.10