Opened 16 years ago
Last modified 14 years ago
#4669 assigned defect
Tickets removed from milestone are not reflected in burndown chart
Reported by: | Owned by: | Joachim Hoessler | |
---|---|---|---|
Priority: | normal | Component: | EstimationToolsPlugin |
Severity: | normal | Keywords: | |
Cc: | Trac Release: | 0.11 |
Description
In the common scenario that some tickets are moved out of a milestone during the course of that milestone, the burndown chart does not reflect historically-accurate information.
This is caused by the burndownchart.py _calculate_timetable method, which only considers tickets that are currently assigned to the milestone in question. Any ticket which is assigned to another milestone _at this moment_ is not considered when computing the chart's values. This ignores all tickets that used to be part of the milestone but have now been moved.
To find these tickets for each day, you can use a query like this, where $milestone$, $midnightBefore$, and $midnightAfter$ are the appropriate values:
select * from ticket_change where field = 'milestone' and oldvalue = $milestone$ and time >= $midnightBefore$ and time < $midnightAfter$;
Attachments (0)
Change History (5)
comment:1 Changed 16 years ago by
comment:2 Changed 16 years ago by
It appears that the current loop over changes is moving forwards through time. My algorithm above still works in that case, but you need to pre-compute the flag for the start date instead.
comment:4 Changed 16 years ago by
Status: | new → assigned |
---|
This issue has been raised by several people already, so I would be happy to update the algorithm to include all tickets that have been moved into other sprints. However, I probably won't find the time to do that anytime soon, but I gladly accept any patch...
comment:5 Changed 14 years ago by
Please, find time! :) I guess we could also do it. Can you provide an idea of how you would do it?
Determining if the ticket belongs to the milestone on a particular day requires backtracking from the current status backwards through all milestone changes for that ticket until you reach the end date on the graph. Once it is established whether the ticket belonged on the end date, you can track it's membership status with a boolean flag and update it in the main loop over ticket_change records. If the flag is on, the current logic applies. If the flag is off, the ticket contributes zero to the estimate on that day.
I apologize that I can only contribute psuedocode, but I'd have to learn a lot more Python in order to express this as a patch.