[rt-users] Avg Time To Resolve graphing troubles fixed! (was RE: [rt-users] RT Statistics Package)

[Beachey, Kendric]

> From: Beachey, Kendric [mailto:Kendric.Beachey at garmin.com]
> 
> Hmmm, one thing I noticed:  the "time to resolution" page 
> isn't drawing a
> graph.  I checked the underlying html and saw a url for a 
> graph, but it was
> incomplete:
> 
> 
> <img
> SRC="/chart?type=lines&x_labels=[Sat%2016,Sun%2017,Mon%201
> 8,Tue%2019,Wed
> %2020&y_number_format=">
> 
> 
> (Yes, it really says ampersand-amp-semicolon.)  Has anyone 
> seen anything
> like this?  I looked at the code that produces this, but all 
> I could do was
> scratch my head:
> 
> 
> % my $url = '/chart?type=lines&x_labels=[';
> % $url .= join ",", @{ shift @data };
> % $url .= ']&';
> % $url .= 'y_number_format=&';
> % for (0..$#data) {
> %  $url .= "data".(1+$_)."=[".(join ",", @{$data[$_]})."]&";
> % }
> % chop $url;
> <IMG SRC="<% $url %>">

(Simon suggested changing that last line to <img src="<% url |n%>".)

I realized that when I ask Mozilla to show me the source of a page, it
doesn't show me the source it used to draw the page I'm looking at.
Instead, it makes a fresh server query and shows me what comes back.  And in
the case of any form that uses the POST method, it forgets to include the
form data.  So what I usually end up seeing is some kind of error page.

In this case, though, it returns something that looks like the normal page,
but it's just using a couple of default values fo r the form, I think, and
has no actual data.  That's how the graph URL above was left half-baked.

I re-hit the report page specifying the parameters in the URL, GET-style
(i.e. http://blah/Statistics/Resolution.html?queue=6&max=10), and then I did
View Source again.

This time I saw a chart call that at least went all the way to the end:

/chart?type=lines&x_labels=[Tue%2012,Wed%2013,Thu%2014,Fri%2015,Sat%2016,Sun
%2017,Mon%2018,Tue%2019,Wed%2020,Thu%2021]&y_number_format=&data1=[27,4118,3
00330,,,10564,54277]

I tried hitting that URL directly, which usually just shows a graph all by
itself, like when you do "View Image" on a picture in a web site.  But
instead it complained with a bluish error page, saying the number of data
points and the number of x-axis labels were not equal.  I counted, and sure
enough, there are 10 labels but only 7 data points.  I added a few more fake
data points to the URL and tried again, and then the graph came up fine.

Why would it leave out some data points?  I tried it again with different
values for max, and each time it was short by three data points.  Hmmm.

I looked at the actual data, and slowly the light bulb began to grow
brighter above my head.  For the last three days, no tickets have been
resolved in this queue.  So the "time to resolve" for those days is listed
as "N/A".  There were some other "N/A" days in the middle of the data too,
and they show up in the data1 array above as commas with nothing between
them.  Could the script just be leaving out those last three data points?

I created a quick dummy ticket in my queue and resolved it right away, and
went back to view the report again.  Now the graph shows up!  But the next
time we get a day where no tickets are resolved in the queue, the graph will
disappear again.

Apparently, some parts of the script understand that there are $max data
points, but other parts somehow miss out on any data points that are N/A at
the end of the data set.  I found that the time-to-resolve part of the data
set is computed and stored in this block of code, which is the part that
displays the last column in the table on the report page:


  <td align=right>
%    if ($tix->Count) {
%       my @tix = @{$tix->ItemsArrayRef};
%       my $total;
%       $total += ($_->ResolvedObj->Unix - $_->CreatedObj->Unix) for @tix;
%       my $average = int ($total / @tix);
     <& DurationAsString, Duration => $average &>
%    $data[$x++][$d] = $average;
%    } else {
      N/A
%    }
  </td>


Aha!  "If I have some tickets in my hand (I'd guess these are the ones that
were resolved for a given day), do some math, display a value, and store the
value.  Otherwise, just display 'N/A'."  So if there were no tickets
resolved for a given day, we skip the part where we store data for later.
Woops!  To partly let Simon off the hook, I'm sure his RT instance gets a
lot more action than mine, and he probably never has a day go by without at
least one ticket getting resolved.

So I decided to use zero as my value for when there were no tickets resolved
in a day, and I made this change:


  <td align=right>
%    if ($tix->Count) {
%       my @tix = @{$tix->ItemsArrayRef};
%       my $total;
%       $total += ($_->ResolvedObj->Unix - $_->CreatedObj->Unix) for @tix;
%       my $average = int ($total / @tix);
     <& DurationAsString, Duration => $average &>
%    $data[$x++][$d] = $average;
%    } else {
%    $data[$x++][$d] = 0; #   <--- added this line
      N/A
%    }
  </td>


And presto, the report now works, even for my "just testing" queues that lay
idle for months at a time.
--
Kendric Beachey