250410 - Time tracking summaries

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, enhancement)

Description

[Christian Reis]

I've implemented a CGI that performs time tracking summaries based on the result
of a buglist. Patch coming up shortly.

Comment 1

[Christian Reis]

Attachment: kiko_v9: implement functionality

Just follow the URL and click on the "Time Summary" button, and you'll be
magically transported into the summary form. Feel free to play around with it.

Comment 2

[Christian Reis]

Attachment: kiko_v12: latest iteration

This version:
 
  - sorts bug numbers and owners
  - offers both views for dependencies and from the buglist
  - includes formatted totals for each section
  - includes bug statuses in the output
  - implements cleaner CSS and template hacks

It should be ready for a first eye-over. Its output is nice:

http://www.async.com.br/~kiko/mybugzilla/summarize_time.cgi?id=3&do_depends=1

Comment 3

[Joel Peshkin]

We should start with a basic question.  If I cannot see bug X, should I be able
to follow its dependency tree? If Y depends on X, I should be able to know that
if I can see X or Y.  But if W blocks X, X blocks Y, Y blocks Z I normally could
not find my way from W to Z without access to either X or Y.

I can't see the harm in this, thought.

I'm presuming this is structured in a manner that would allow a call to
Search.pm to generate the list as well in a subsequent patch.

Comment 4

[Christian Reis]

The latest patch includes both support for producing reports based on buglists
and reports based on dependencies -- it's based on the *product* of Search.pm
which simplifies the form's interface (it just receives a list of bugs). Sound okay?

The logic implemented right now is:

  If you cannot see bug X, you cannot see its dependency tree.
  If you can see bug X but not its dependent bug Y, you can see bug X and all 
    its dependencies excluding bug Y.

Does that sound okay? It's a simple double-filter by CanSeeBug in the CGI.

Comment 5

[Joel Peshkin]

That sounds right.  I'll have to confirm it all when I am awake.

Comment 6

[Jeff Hedlund]

This is looking really good.  Just thinking off the top of my head:  Similar to
a buglist, I am wondering how difficult it would be to get the results in a CSV
format?

And also similar to a buglist, the ability to bookmark the results page (meaning
that it would need a query string in the URL)?

Comment 7

[Gervase Markham [:gerv]]

</me notices a review for a reporting enhancement on the mailing list>

Kiko: your Bugzilla requires a login...

Gerv

Comment 8

[Christian Reis]

(In reply to comment #6)
> This is looking really good.  Just thinking off the top of my head:  Similar to
> a buglist, I am wondering how difficult it would be to get the results in a CSV
> format?

I'm going to be working on that next.

> And also similar to a buglist, the ability to bookmark the results page (meaning
> that it would need a query string in the URL)?

This is more difficult. I'd love to do this, but there is a fundamental problem:
the fact that (if coming in via the buglist view) I store the buglist in a form
variable, which can grow very much and blow up HTTP GET restrictions (as has
happened in bug 250388 with dependency tree). The only solution I see for this
is using query.cgi's query string and redo the query here, but it has a
performance hit since we redo the query. I'd contemplate opening a bug to
evaluate these options.

(In reply to comment #7)
> </me notices a review for a reporting enhancement on the mailing list>
> 
> Kiko: your Bugzilla requires a login...

Well, this page needs to check if CanSeeBug for all the bugs it lists. Can I
just use LOGIN_NORMAL and pass in a null id to CanSeeBug? I need to check for that.

Comment 9

[Christian Reis]

(In reply to comment #8)
> (In reply to comment #7)
> > </me notices a review for a reporting enhancement on the mailing list>
> > 
> > Kiko: your Bugzilla requires a login...
> 
> Well, this page needs to check if CanSeeBug for all the bugs it lists. Can I
> just use LOGIN_NORMAL and pass in a null id to CanSeeBug? I need to check for
that.

By the way, this isn't the only problem. I can only check if a user is in the
timetracking group if he's logged in. What now?

Comment 10

[Joel Peshkin]

Comment on attachment 153107 [details] [diff] [review]
kiko_v12: latest iteration

We need to come up with clearer terminology saying that the time is computed on
bugs that block this one.

This also needs filters and html-validation checks.

We should revisit the use of time() to set limits on SQL-server time.  I'd
rather let the SQL server make its own determination if something is in the
future or not.	A bug based on that would be pretty darn obscure, though, so I
am probablyjust being dogmatic.

Comment 11

[Christopher Hicks]

(In reply to comment #2)
> http://www.async.com.br/~kiko/mybugzilla/summarize_time.cgi?id=3&do_depends=1

I put in various time spans up to to 10 years and was never able to hit any
valid data.

Comment 12

[Christian Reis]

It's just a permissions thing; I've fixed up your user. New users should be safe
because I made the Everybody group have a catch-all regexp.

Comment 13

[Christian Reis]

Attachment: kiko_v14: separate css, filter, HTML validate, add ctype support

I've done an update that should solve all pending review comments but the use
of time(). There is a change that needs to be done to support null start dates
when doing queries split into time summaries; I would like to review the use of
time() when I did that since I will be doing lots of time-based debugging. The
current situation is that there is a one-in-a-million chance that this will be
a problem IRL and I will follow up shortly with a fix for this as soon as this
is off my place (it is a large change and though not prone to bitrot requiring
a large context switch).

This version HTML validates correctly (thanks for reminding me) and passes
runtests flawlessly. I also amended the text that indicates we're summarizing
for dependent bugs, I think it's actually acceptable.

I added ctype support via a form select box. This isn't in use yet but I will
also follow-up with a CSV format that I have half-ready but still in need of
filtering and indentation.

Comment 14

[Christian Reis]

Attachment: kiko_v15: simplify and correct filtering

This also uses a hyphen-spaced CSS name.

Comment 15

[Joel Peshkin]

Comment on attachment 157806 [details] [diff] [review]
kiko_v15: simplify and correct filtering

runtests has a problem with one of the filter tests.

While you are at itm please fix the 4-space indent (should be 2, though I can
see the appeal of making the nesting of TT statements 4 and html statements 2)
in summarize-time.html.tmpl

I'm going to want an enhancment on this after it lands to specify that I only
want time for certain developers or gorups of developers.

Comment 16

[Mark Proctor]

I've just applied the patch against CVS head and I have to say this is an
awesome feature and will really appeal to PHBs - you guys really need to  get
this into the main release asap, its a killer feature. Just showed it to mine
and he nearly cried with joy. He did ask if it could show and summarise
"forcasts" ie estimated work. This will allow us to plan future milestones
against a 40 hour week.

I like the way it records which developer logged the hours against a bug, so you
can have multiple developers for a single bug. Maybe that could also be worked
into the "forcasting"

Comment 17

[Shane H. W. Travis]

Attachment: v16 - fix Joel's r- issues, update to tip

Kiko: this is beautiful. It makes me want to weep. It is *exactly* what the
PHBs around here have been bugging me for, and will bug me for even more once
we get everyone using timetracking more consistently.

I know how busy you are: I want this so much that I have updated it to the
current tip on my own, and fixed the problems that caused joel to r- it last
time.

Joel, can you please please please review and approve, so we can get this on
the trunk? If you simply don't have time, please say so, and I'll ask someone
else. Since you did the first few, though, the effort needed to finish this off
should be miniscule...

Comment 18

[Shane H. W. Travis]

Attachment: Further changes as per discussion with Kiko

Spoke with Kiko this afternoon; he indicated that there had been a few bugfixes
put in place since he posted the latest version here. He sent me a copy if
*his* latest version, and I merged it with v16 to get v17.

Comment 19

[Joel Peshkin]

Comment on attachment 175600 [details] [diff] [review]
Further changes as per discussion with Kiko

fix an indent nit in date_adjust on checkin and r=joel
This is really cool and thanks for keeping the access validation stuff so
readable.

Comment 20

[Shane H. W. Travis]

Indentation nits fixed on checkin.

Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.284; previous revision: 1.283
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/summarize_time.cgi,v
done
Checking in summarize_time.cgi;
/cvsroot/mozilla/webtools/bugzilla/summarize_time.cgi,v  <--  summarize_time.cgi
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/skins/standard/summarize-time.css,v
done
Checking in skins/standard/summarize-time.css;
/cvsroot/mozilla/webtools/bugzilla/skins/standard/summarize-time.css,v  <--  
summarize-time.css
initial revision: 1.1
done
Checking in template/en/default/filterexceptions.pl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/filterexceptions.pl,v  <-
-  filterexceptions.pl
new revision: 1.35; previous revision: 1.34
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--
  edit.html.tmpl
new revision: 1.57; previous revision: 1.56
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/summarize-
time.html.tmpl,v
done
Checking in template/en/default/bug/summarize-time.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/summarize-
time.html.tmpl,v  <--  summarize-time.html.tmpl
initial revision: 1.1
done
Checking in template/en/default/list/list.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.html.tmpl,v  <-
-  list.html.tmpl
new revision: 1.32; previous revision: 1.31
done

Comment 21

[Max Kanat-Alexander]

Added to the release notes in bug 286274.

Comment 22

[Frédéric Buclin]

Attachment: doc patch, v1

This patch also includes additional documentation about the time tracking feature as it doesn't make sense to mention the "Time Summary" feature if we don't mention the time tracking system first. :)

Comment 23

[Dave Miller [:justdave]]

Comment on attachment 254745 [details] [diff] [review]
doc patch, v1

you're missing a closing </para> on the last paragraph, but the text looks good to me.

Comment 24

[Frédéric Buclin]

Attachment: doc patch, v1.1

include </para>

Comment 25

[Frédéric Buclin]

tip:

Checking in docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.61; previous revision: 1.60
done

2.22.2:

Checking in docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.37.2.16; previous revision: 1.37.2.15
done

2.20.4:

Checking in docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.33.2.19; previous revision: 1.33.2.18
done