Closed Bug 220034 Opened 16 years ago Closed 16 years ago

empty form after changing bug details

Categories

(Bugzilla :: Creating/Changing Bugs, defect, P1, blocker)

defect

Tracking

()

RESOLVED FIXED
Bugzilla 2.18

People

(Reporter: dreeh, Assigned: wicked)

References

Details

(Keywords: dataloss, regression)

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827

after changing and submitting a bug, you get normally a "Bug processed"-message
an seeing the next bug. but the next bug isn't shown korrectly. the heading "
The next bug in your list is bug 1347:" is shown, but the formular fields are empty.
with mozilla, i'm getting javascript-errors:

Error: syntax error
Source File: http://devel.ets-online.de/bugzilla/process_bug.cgi
Line: 243, Column: 23
Source Code:
  var fRemainingTime = ; // holds the original value


Error: addReplyLink is not defined
Source File: http://devel.ets-online.de/bugzilla/process_bug.cgi
Line: 614

Reproducible: Always

Steps to Reproduce:
1. select a bug
2. change details
3. submit the changes

Actual Results:  
the bug changes are saved, but the next bug isn't shown.

Expected Results:  
mozilla shows an empty formular.
This sounds like it's related to the reply-link thing....   kiko?
OS: Linux → All
Hardware: PC → All
Summary: empty formular after changing bug details → empty form after changing bug details
Reproduced on landfill.  This is pretty severe....
Severity: normal → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss, regression
Priority: -- → P1
Target Milestone: --- → Bugzilla 2.18
Actually, it's more related to the time-tracking implementation. The code in
fault (in edit.html.tmpl) follows:

[% IF UserInGroup(Param('timetrackinggroup')) %]
  var fRemainingTime = [% bug.remaining_time %]; // holds the original value

As you can see from the output in the error, bug.remaining_time is null.

This error only occurs if timetrackinggroup is on, the user is in the group, and
the bug has no remaining time. 

The bandaid fix is maybe (I have no idea on the real implementation of this):

[% IF UserInGroup(Param('timetrackinggroup')) and bug.remaining_time %]
    var fRemainingTime = [% bug.remaining_time %]; // holds the original value

-- but maybe Jeff has a better idea.

Now I'm not saying there's nothing I can do about the addReplyLink consequences,
of course :-) I need some help from caillon: is there a way I can work around JS
errors and make addReplyLink not die a horrible death if an unrelated problem
occurs?
Jeff did some JS changes in bug 179293 that did some bulletproofing, but if the
user *is* in a timetrackinggroup, the code is included.

I guess the real question is why is bug.remaining_time null in this case? 
Do Denny or Jeff have any idea?
Given that JS auto-converts from strings to numbers, an alternative band-aid
might be:

var fRemainingTime = "[% bug.remaining_time %]";

Better, though, is to make sure remaining_time is never null - null has no
meaning for a remaining time. It should always be a non-negative decimal.

Gerv
I'm seeing this on my site and I do not have time tracking enabled. All bugs are
in one or more group. These are the error messages I'm getting:

[Fri Oct  3 01:36:32 2003] process_bug.cgi: Argument "" isn't numeric in numeric
gt (>) at data/template/en/default/bug/edit.html.tmpl line 310.
[Fri Oct  3 01:36:32 2003] process_bug.cgi: Argument "" isn't numeric in numeric
gt (>) at data/template/en/default/bug/edit.html.tmpl line 419.
[Fri Oct  3 01:36:32 2003] process_bug.cgi: Date/Time format () unrecogonzied at
Bugzilla/Util.pm line 167.

The first error comes from line 294 in edit.html.tmpl:
        [% IF bug.flag_types.size > 0 %]

So could it be that bug is not defined for some reason?
Sounds like flag_types is null, more likely. Possible?

Anyway.. Gerv, where should we go with this?
Actually to me it seems that the whole bug object is null. Line "$vars->
{'bug'} = $bug;" that was in the file process_bug.cgi before processing 
next.html.tmpl was removed as part of bug 208699. I take this makes bug object 
missing from $vars when edit.html.tmpl template is processed.

See http://bonsai.mozilla.org/cvsview2.cgi?
diff_mode=context&whitespace_mode=show&file=process_bug.cgi&branch=&root=/cvsro
ot&subdir=mozilla/webtools/bugzilla&command=DIFF_FRAMESET&rev1=1.189&rev2=1.190

Adding that line back to process_bug.cgi seems to fix this bug.
I don't know if this fixes the time-thing, but right now the whole information
for the next bug is empty. All the fields.

Steps to reproduce:

-> make a query which returns multiple bugs.
-> select the first bug.
-> change something, click Submit.

Result: the "next" bug displayed has completely empty forms.
Expected results: the actual data for the next bug.

This patch fixes this.
Attachment #133030 - Flags: review?(kiko)
Comment on attachment 133030 [details] [diff] [review]
Adding the next bug information to the template.

Yep, seems that bbaetz missed that dependency. 

Maybe add a comment that makes it clear that the template wants $bug defined?
At any rate, good catch, r=kiko.
Attachment #133030 - Flags: review?(kiko) → review+
Attached patch Version 2 (obsolete) — Splinter Review
>> At any rate, good catch

Well, the credit goes to Teemu (comment #8) :).
Attachment #133030 - Attachment is obsolete: true
Attached patch Version 2Splinter Review
Seems the previous one is corrupted.
Attachment #133185 - Attachment is obsolete: true
Attachment #133186 - Flags: review?(kiko)
Well, your comment describes "the what" instead of "the why". While the code
itself should make the former clear, good comments focus on the latter. I suggest

   # next.html.tmpl includes edit.html.tmpl, and therefore we
   # need $bug defined in $vars.

The comment was just a nit, though, you can carry on my r= and just fix it on
checkin.
Assignee: myk → jocuri
Thanks!

I'll replace my comment with yours upon checkin, if that's ok.
Status: NEW → ASSIGNED
Flags: approval?
Attachment #133186 - Flags: review?(kiko) → review+
-> patch author.

Vladd: go ahead and check it in, with the comment changes you noted.
Assignee: jocuri → wicked
Status: ASSIGNED → NEW
Flags: approval? → approval+
Vladd, before closing please make sure the original problem reported isn't
happening any more (i'm still a bit sketchy as to what bug.remaining_time is
being set to right now, and I originally thought that was the actual problem).
Status: NEW → ASSIGNED
Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.192; previous revision: 1.191
done

I'll let this opened until someone can confirm that it's fully fixed.
Removing the approval+ flag to:

-> make the bug disappear from the "ready to checkin" query (already checked in).
-> allow the "a?" flag to be set for eventually new patches that will be posted
here.
Flags: approval+
uh, say what?

What's happening that this didn't fix?
Well, I am still curious about bug.time_remaining, but I'm very busy today. I'll
look into this tomorrow if nobody can do it before that.
It's 4am right now but as this bug is assigned to me I couldn't resist the 
temptation to test it more. So I went and updated process_bug.cgi from cvs to 
v1.192 and tested the code.

Re problem in description and in comment #9: next bug is shown with correct 
information. There are no erroneous empty fields. Same data is displayed as in 
show_bug.cgi for the same bug.

Re problem in comment #6: there are no errors in error log after the change.

Re comment #4 and comment #7: to my understanding the bug.remaining_time and 
bug.flag_types were null because the bug object that contained them was null 
thus making them null also.

Re comment #16 and comment #20: I'm in timetrackinggroup and can see the 
correct values in the time tracking fields. Even the javascript updating Hours 
left fields seems to behave normally (or atleast the same as in show_bug.cgi).

I would say this is fixed but feel free to test some more if you think 
otherwise or want to make the timetracking code more robust. I can't think of 
anything more to test and besides I have run out of bugs to change..
yeah, I thought as much.  If someone thinks this is still broken, reopen this
and tell us why.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: approval+
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.