643681 - Bug.get should also return the time spent on a bug for users in the timetracking group

Status: RESOLVED FIXED

(Bugzilla :: WebService, enhancement)

Description

[Daniel Liljeberg]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
Build Identifier: Bugzilla version 4.0+

It doesn't seem to be possible to fetch information about the number of hours put into working on a bug. Since fetching data to display for external parties or use in external applications is probably the major use of the RPC, this is probably one of the most important data to be able to keep track of even outside of Bugzilla.

Reproducible: Always

Steps to Reproduce:
1. Add some worked time to a bug
2. 'Get' the bug using the XML-RPC
3. Fetch the comments of the bug
4. Inspect the returned data of the bugs and the comments
Actual Results:  
No data about hors worked in either the comments of the bug, nore in the bug itself.

Expected Results:  
A total of the worked hours should be part of the returned bug data and each "Additional hours..." comments should be returned when fetching the comments of a bug. Would be nice to have the hours worked for a comment in it's own field to avoid having to parse the comment 'text' field. And comments that don't have any additional worked time could just set this to 0.

Comment 1

[George Hockney]

Attachment: Adds 'hours_worked' to the comments hash if user is timetracker

Comment 2

[George Hockney]

I'm having the same issue here.  I've made a patch for just the comments hash returning the "work_time" entry for hours worked for the comment. Correct operation is probably to return an 'hours_worked' hash containing the work_time if the user is a member of the timetracking group and not otherwise.  This would match the behavior of estimated_time and remaining_time in the bug itself.

I've implemented and tested this by editing Bug.pm translate_comment routine to add 'hours_worked' if the user is a timetracker.    This change only involves the file Bugzilla/Webservice/Bug.pm, with the changes I've included below.


I've also attached a patch.diff file made following the instructions on the web page for someone not using bzr; I'm not sure I did it right. Here's how I made the attachment:

diff -Nru --exclude=data --exclude='*.orig' --exclude=CVS --exclude=localconfig --exclude=.bzr --exclude=.htaccess --exclude='.#*' --exclude='*.rej' Bugzilla ../bugzilla-4.0.orig/Bugzilla > ../patch643681.diff

so it's a diff which needs to be applied to bugzilla-4.0/Bugzilla.  I hope it's useful.  



diff Bug.pm Bug.pm.orig
296c296
<     my %item = (
---
>     return filter $filters, {
305,313c305
<     );
< 
<     # Timetracking field is only sent if the user can see it.
<     if (Bugzilla->user->is_timetracker) {
<         $item{'hours_worked'} = $self->type('double', $comment->work_time);
<     }
< 
<     return filter $filters, \%item;
< 
---
>     };
1519,1525d1510
< =item C<hours_worked>
< 
< C<double> The number of hours worked submitted with this comment
< 
< If you are not in the time-tracking group, this field will not be included
< in the return value.
<

Comment 3

[Max Kanat-Alexander]

Thanks for the patch! The reason that we didn't do this when implementing Bug.comments is that work_time really should not be associated with comments at all. It's an architectural mistake that those two things are linked. I don't want to perpetuate that mistake into a stable API.

Question is, though, how *should* the information be represented? I was thinking that just having Bug.get return the total amount of time worked on the bug should be enough, no?

Comment 4

[Daniel Liljeberg]

@Max: I agree that the close linkage between the comments and hours worked doesn't feel quite right. Regarding having the total returned I would say that it would be enough to start with anyways. I would probably like to see an array/hash of "worked hours"-entries containing hours and the time of the creation of the entry, alongside a total in the main bug object (to just avoid having to calculate it each time if it's the total you are after. This way it would be easy to plot the number of hours worked for a given bug during the previous week for example.

You could retrieve it in the same way you get comments about a bug. Another off-topic thing that could be implemented here but also on comments would be the ability to request them being sent along with the retrieved bugs when you make a request? That way you could reduce the number of calls needed.
For me now I want to get info about som bugs in a current iteration. The only way I seem to be able to do this is to request all bugs updated during the last few weeks, filter out the ones not part of the milestone I'm interested in, get all the bug id's of the bugs that are left and request the comments of all these bugs. Seems like we could streamline this quite a bit and make it more affective. But, as I said... a vit off-topic

Comment 5

[Frank]

Yes to "return the total amount of time worked on the bug should be enough"

This is something that is needed.  Total amount of time worked on a bug for a product.

Comment 6

[damluar]

Hello,
what is the situation now? How can I get (or approximate) time spent on a bug? Is there any workaround or another API?

Comment 7

[Fraser Tweedale]

Attachment: add 'actual_time' to bug fields if user is timetracker

Comment 8

[Fraser Tweedale]

In the mean time... you can actually calculate the hours worked from
the bugs history.  Ugly and expensive but effective.

Comment 9

[David Lawrence [:dkl]]

Comment on attachment 580614 [details] [diff] [review]
add 'actual_time' to bug fields if user is timetracker

Review of attachment 580614 [details] [diff] [review]:
-----------------------------------------------------------------

You will need to add a bit to the History section stating the addition of the 'actual_time' in the return value. Otherwise looks good 
and I will r+ the revised patch.

Thanks!
dkl

Comment 10

[Fraser Tweedale]

Attachment: add 'actual_time' to bug fields if user is timetracker; now with history

Comment 11

[David Lawrence [:dkl]]

Comment on attachment 610517 [details] [diff] [review]
add 'actual_time' to bug fields if user is timetracker; now with history

Review of attachment 610517 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. r=dkl

Comment 12

[David Lawrence [:dkl]]

Bug.get is considered STABLE in 4.2 so only requesting for trunk.

Comment 13

[Frédéric Buclin]

dkl: before you commit this patch, is actual_time really the best field name for this? We aren't force to reuse the internal field name in the API.

Comment 14

[David Lawrence [:dkl]]

Leaving the name as actual_time for now per our discussion in IRC.

trunk:
Committing to: bzr+ssh://[e-mail]/bugzilla/trunk
modified Bugzilla/WebService/Bug.pm
Committed revision 8170.

dkl

Comment 15

[Frédéric Buclin]

Added to the relnotes for 4.4.