253562 - Hours Worked (actual_time) is being listed as 1

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect, P2)

Description

[Frank Kardel]

User-Agent:       Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.6) Gecko/20040209
Build Identifier: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.6) Gecko/20040209

When enableing the time tracking option the Hours Worked field lists
as 1 and that value also carries over into dependent fields.

Environment contained perl 5.8.0, Bugzilla 2.18rc2

Reproducible: Always
Steps to Reproduce:
1. enable time tracking (define respective group)
2. create a bug
3. look at Horus Worked - see a 1 without even working
4. attempt to collect cash from your employer - ok i am getting carried away...

Actual Results:  
It happened at step 3 already.

Expected Results:  
List 0.0 an empty Bug. The correct sum after times have been entered.

The Problem is in Bugzilla/Bug.pm sub actual_time:
Assignment to $self->{'actual_time'} is a scalar context. The result from
&::FetchSQLData() is a one element array. Assignment will assign the 1 for the
array size 8-(.

Possible fix:
        my @result = &::FetchSQLData();

        $self->{'actual_time'} = $result[0] if $#result >= 0;

Comment 1

[Christian Reis]

Why can't I reproduce this on my local system?

I added:

        $self->{'actual_time'} = &::FetchSQLData();
        print "OY". $self->{'actual_time'};

And I always get 0.00 back for bugs just created. 

This is Perl 5.6.1, MySQL 3.23.49 and DBI 1.37 and DBD::mysql v2.9002. Are you
using something different?

Anyway, it probably won't hurt to clarify that code a bit.

Comment 2

[Christian Reis]

Attachment: kiko_v1: the usual bite-sized cleanup

Frank, can you please give this a try and see if it fixes your error? It may,
but it may not given I'm not sure if fetchrow_array doesn't evaluate
incorrectly in scalar context again (but that's done all over the tree).

I'd really like to know why I can't reproduce this, but...

Comment 3

[Joel Peshkin]

Comment on attachment 154725 [details] [diff] [review]
kiko_v1: the usual bite-sized cleanup

The cleanup looks fine, but I cant see it being cause and effect with this bug.

I cannot reproduce this either.  Let's start by figuring out if it is in the
database wrong or in the UI wrong.

Frank, please go into mysql and do a 

select * from londescs where bug_id = NUMBER 

and see if the actual work time field has any non-zero values in it.

Comment 4

[Frank Kardel]

(In reply to comment #2)
> Created an attachment (id=154725)
> kiko_v1: the usual bite-sized cleanup
> 
> Frank, can you please give this a try and see if it fixes your error? It may,
> but it may not given I'm not sure if fetchrow_array doesn't evaluate
> incorrectly in scalar context again (but that's done all over the tree).
> 
> I'd really like to know why I can't reproduce this, but...
Well i am using perl 5.8.x maybe that is the difference ?

Comment 5

[Frank Kardel]

(In reply to comment #3)
> ...
> and see if the actual work time field has any non-zero values in it.
> 

data looks nice either 0.00 or a sensible value is in the table

Using fetch_arrayref in a scalar context (has element assignment) seems to be
somewhat 
risky according to the DBI documentation:
           If called in a scalar context for a statement handle
           that has more than one column, it is undefined whether

perl v5.8.0                 2004-01-08                         64

DBI(3)         User Contributed Perl Documentation         DBI(3)

           the driver will return the value of the first column
           or the last. So don't do that.  Also, in a scalar con-
           text, an "undef" is returned if there are no more rows
           or if an error occurred. That "undef" can't be distin-
           guished from an "undef" returned because the first
           field value was NULL.  For these reasons you should
           exercise some caution if you use "fetchrow_array" in a
           scalar context.

Comment 6

[Christian Reis]

(In reply to comment #4)
> Well i am using perl 5.8.x maybe that is the difference ?

Maybe. Does the patch I provided fix things for you?

Comment 7

[Frank Kardel]

(In reply to comment #6)
> (In reply to comment #4)
> > Well i am using perl 5.8.x maybe that is the difference ?
> 
> Maybe. Does the patch I provided fix things for you?
> 

Works - thanks !

Comment 8

[Christian Reis]

Comment on attachment 154725 [details] [diff] [review]
kiko_v1: the usual bite-sized cleanup

Since it fixes his problems and doesn't regress us..

Comment 9

[Joel Peshkin]

Comment on attachment 154725 [details] [diff] [review]
kiko_v1: the usual bite-sized cleanup

r=joel

Comment 10

[Dave Miller [:justdave]]

Comment on attachment 154725 [details] [diff] [review]
kiko_v1: the usual bite-sized cleanup

This will probably work for 2.18, but didn't the API for Bugzilla::User just
change on the trunk?

Comment 11

[Dave Miller [:justdave]]

ok, wth didn't that midair....   :)

Comment 12

[Christian Reis]

Checked into HEAD:

/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v  <--  Bug.pm
new revision: 1.44; previous revision: 1.43

and branch:

/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v  <--  Bug.pm
new revision: 1.37.2.1; previous revision: 1.37

Thanks.

Comment 13

[Myk Melez [:myk] [@mykmelez]]

clearing irrelevant approval request