Opened 7 years ago

Closed 7 years ago

# Expected cannot exceed 100 initially

Reported by: Owned by: andreas.schroeder@… Odd Simon Simonsen normal EstimationToolsPlugin minor 0.11

### Description

Initially, without having any tickets assigned to a milestone, the expected value can't exceed 100, and it also can't exceed the maximum of the intial hours left (i.e. on the first day) of all tickets. This isn't a big issue, but the limit of 100 seems arbitrary :)

The example below was created with the following settings and no tickets associated with the milestone: [[BurndownChart(milestone=Iteration 1, startdate=2010-05-03, expected=192)]]

### comment:1 Changed 7 years ago by andreas.schroeder@…

Severity: normal → minor

fixing the severity...

### comment:2 follow-up:  3 Changed 7 years ago by Odd Simon Simonsen

I haven't seen the details of this code, but looks like a similar issue to what is seen in the XmlRpcPlugin where queries just return a fixed number of tickets. This number is tied to the paging of web queries, and is a trac.ini config value. You can also override it on individual queries by using 'max' argument - like max=500 or similar.

### comment:3 in reply to:  2 Changed 7 years ago by anonymous

I haven't seen the details of this code, but looks like a similar issue to...

Browsing docs and the code, I see that that this can't possibly be related... Trying to help based on a quick hunch, and instead I just end up making noise. Please ignore :-)

### comment:4 Changed 7 years ago by François Boissonneault

mmh, it seems it's related to the number of hours calculated in the milestone. If, per example, I have 345 hours in the milestones, it seems I can't make expected higher than this. Can you guys confirm the problem is the same?

### comment:5 Changed 7 years ago by andreas.schroeder@…

Yes, that's exactly it. If your max hours is at 345 and you set expected to 500, the burndown's "left hours" axis will cap at 345, and the expected line will start at 345.

Btw, we had milestones with far less than 100 tickets and still got this capping problem with expected hours, so I don't think that it's related to a ticket-max cap.

### Changed 7 years ago by Odd Simon Simonsen

Fixing scaling of Y axis when expected value exceeds maxhours.

### comment:6 Changed 7 years ago by Odd Simon Simonsen

Owner: changed from Joachim Hoessler to Odd Simon Simonsen

attachment:t7003-expected_y_axis-r8886.diff should fix this issue. Most of the patch is unittest and test infrastructure, so the only line that in the end needed changing was this:

• ## estimationtools/burndownchart.py

 a dates = timetable.keys() dates.sort() maxhours = max(timetable.values()) maxhours = max(timetable.values() + [int(options.get('expected', 0))]) if maxhours <= Decimal(0): maxhours = Decimal(100)

Anyone up for testing the patch before I commit?

### comment:7 Changed 7 years ago by Ryan J Ollos

I can test with Trac 0.11.7 by end of day tomorrow. I haven't used this plugin before, but was planning to install it soon anyway.

### comment:8 Changed 7 years ago by Odd Simon Simonsen

Resolution: → fixed new → closed

(In [9029]) EstimationToolsPlugin: Fix issue with Y-axis scaling when 'expected' value was higher than any max value for hours. Tests included. Closes #7003.

### Modify Ticket

Change Properties