Opened 7 years ago

Closed 6 years ago

#7003 closed defect (fixed)

Expected cannot exceed 100 initially

Reported by: andreas.schroeder@… Owned by: osimons
Priority: normal Component: EstimationToolsPlugin
Severity: minor Keywords:
Cc: Trac Release: 0.11


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)]]

Attachments (2)

expected-buggy.png (11.6 KB) - added by anonymous 7 years ago.
t7003-expected_y_axis-r8886.diff (3.5 KB) - added by osimons 6 years ago.
Fixing scaling of Y axis when expected value exceeds maxhours.

Download all attachments as: .zip

Change History (10)

Changed 7 years ago by anonymous

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

  • Severity changed from normal to minor

fixing the severity...

comment:2 follow-up: Changed 6 years ago by osimons

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 6 years ago by anonymous

Replying to osimons:

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 6 years ago by FakePlasticFrank

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 6 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 6 years ago by osimons

Fixing scaling of Y axis when expected value exceeds maxhours.

comment:6 Changed 6 years ago by osimons

  • Owner changed from hoessler to osimons

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/

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

Anyone up for testing the patch before I commit?

comment:7 Changed 6 years ago by rjollos

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 6 years ago by osimons

  • Resolution set to fixed
  • Status changed from new to 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.

Add Comment

Modify Ticket

as closed The owner will remain osimons.
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.