[PATCH] rounding error can corrupt progress bar in milestone_view

[Andrew C Martin <andrew.c.martin@…>]

Note the progress bar in the bottom right corner of this image:

Despite the fact that there are zero closed tickets, the progress bar shows ~100% are.

If you look at the HTML generated below, you can see that the first TD is getting a negative width. It should actually show "display: none" since there are no "closed" tickets. IE/Chrome/FF all interpret the negative width as ~100% width:

  <table class="progress" style="width: 80%">
    <tr>
      <td class="closed" style="width: -1%">
        <a href="/test/query?status=closed&amp;group=status&amp;type=defect&amp;milestone=milestone1" title="0/8 closed"></a>
      </td><td class="new" style="width: 13%">
        <a href="/test/query?status=new&amp;group=status&amp;type=defect&amp;milestone=milestone1" title="1/8 new"></a>
      </td><td class="open" style="width: 88%">
        <a href="/test/query?status=assigned&amp;status=accepted&amp;status=reopened&amp;group=status&amp;type=defect&amp;milestone=milestone1" title="7/8 in progress"></a>

      </td>
    </tr>
  </table>

I am proposing attachment:progress_bar.patch​ to fix this issue. roadmap.py doesn't handle a boundary case for when the rounded sum of all the percentages can be greater than 100.

This is easy to reproduce:

1. Fire up a new trac test environment
2. Append these lines to your trac.ini:

   [milestone-groups]
   closed = closed
   closed.order = 0
   closed.overall_completion = true
   new = new
   new.order = 1
   new.css_class = new
   new.label = new
   new.overall_completion = false
   active = *
   active.order = 2
   active.css_class = open
   active.label = in progress
   

3. Write 8 tickets and assign all of them to milestone1.
4. "Accept" all but 1 ticket in the tickets' workflow.
5. Click on milestone1 from the roadmap.

I think there's an issue with the way that "1 / 8" gets calculated when "overall_completion = false" that may be a separate bug…

[Remy Blank]

Thanks for the patch.

[Andrew C Martin <andrew.c.martin@…>]

Replying to Andrew C Martin <andrew.c.martin@…>:

I think there's an issue with the way that "1 / 8" gets calculated when "overall_completion = false" that may be a separate bug…

I wrote #9721 for this issue and proposed a patch for it.

[Remy Blank]

Perfect bug description, perfect patch, applied in [10304]. Thanks!