46753 - old owner is set to null in activity table when bug reassigned

Status: VERIFIED FIXED

(mozilla.org Graveyard :: Server Operations, task, P3)

Description

[Dawn Endico]

Reassigning bugs sets the "Old Value" to null in the activity log.

Bug 43690 was owned by me but when I reassigned it to dmose the
activity log showed nothing for the previous owner.

http://bugzilla.mozilla.org/show_activity.cgi?id=43690

I imagine this has to do with this change but i'm not sure how.
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/webtools/bugzilla&command=DIFF_FRAMESET&root=/cvsroot&file=process_bug.cgi&rev1=1.62&rev2=1.63

The problem started happening when I updated bugzilla to the tip.
These are the changes since my last sync:


http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=mozilla%2Fwebtools%2Fbugzilla%2F&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=07%2F14%2F2000+08%3A31&maxdate=07%2F27%2F2000+13%3A10&cvsroot=%2Fcvsroot

Comment 1

[Dawn Endico]

I commented out line 906 of process_bug.cgi and it solved
my problem. That doesn't make any sense but I'll leave it
like that. (Its only changed on bugzilla.mozilla.org)

http://bugzilla.mozilla.org/show_activity.cgi?id=43559

Comment 2

[Dawn Endico]

btw, that change was made by tara 07/25/2000 15:00. The checkin comment
says it was from a patch by Dave Miller. Assigning to Dave.

Comment 3

[Dave Miller [:justdave]]

Yep, that's from my patch.  Here's how to switch it back:

Index: processmail
===================================================================
RCS file: /cvsroot/mozilla/webtools/bugzilla/processmail,v
retrieving revision 1.41
diff -u -r1.41 processmail
--- processmail 2000/07/13 03:38:30     1.42
+++ processmail 2000/07/28 02:10:30
@@ -191,7 +191,7 @@
     my $status_whiteboard = "";
     if (Param('useqacontact') && $::bug{'qa_contact'} > 0) {
         $::bug{'qa_contact'} = DBID_to_name($::bug{'qa_contact'});
-        $qa_contact = "$::bug{'qa_contact'}\n";
+        $qa_contact = "QAContact: $::bug{'qa_contact'}\n";
     } else {
         $::bug{'qa_contact'} = "";
     }

My server is down, and everyone from the office is in Kansas City for a 
conference this week, so there's no one there to let the tech in to fix it.  So I 
can't check it in myself.  Likewise I can't test it until then either (likely 
Monday).  Leaving this as NEW so I'll get mail about it when the server is back 
up.

Comment 4

[Dawn Endico]

thanks, this is what I did on bugzilla.mozilla.org to fix the problem.
(Although I didn't check in yet)

I thought I read in some bug that you deleted the "QAContact: " string
from here because it was duplicated. Would adding it back in make it
duplicate again for you? I don't know anywhere else that string could
have been added.

Comment 5

[Dave Miller [:justdave]]

Yeah, there's two places it gets used.  I only noticed the one place at the point 
I created that patch...   one of the templates that gets placed into has the "QA 
Contact: " title in it already, the other doesn't.  It's placing the title into 
the variable with the QA Contact name when it assigns it, before passing it to 
the template.  So in the one case it winds up duplicated and in the other it 
doesn't.   But since it only affects the old email tech, and I don't use it (I 
use the new stuff, and have my local install hacked to give that to everyone, 
because it's less confusing to read for people that aren't familiar with diffs), 
I don't really care if the duplication this is fixed or not.  I just noticed it 
when I was in looking at the other stuff.  So if no one else has run into any 
trouble with it, I'll just go ahead and put it back the way it was. :)

I hate server problems.  Router died, and they had to replace it.  No one was 
there to let them in to install the new one until this morning (we were all in 
Kansas City), so we went without email, and without a webpage (including our 
bugzilla) for a week.  Ack!  So now I have tons of email, just like coming back 
from a vacation (fortunately we have an offsite MX backup, so all our incoming 
mail got held).  I'll hopefully get this re-checked in tonight or tomorrow.

Comment 6

[Dave Miller [:justdave]]

The last three comments on this bug have nothing to do with this bug, no idea how 
they got here...  they really belong to bug 30826.

Got some time this afternoon, going to try to nail this bug finally.  This is 
really a failure of the fix on 30824, so I'm reopening that one and setting a 
dependency.

Comment 7

[Dave Miller [:justdave]]

OK, 30824 is re-fixed, now.  If this works for you, Dawn, I'll let you mark this 
bug fixed.

Comment 8

[Dave Miller [:justdave]]

Reassigning to Dawn, back in her ballpark now...

Comment 9

[Chris Yeh]

please respond. if this is checked into the trunk, please close this as fixed if 
dawn is okay

Comment 10

[Dave Miller [:justdave]]

bug 30824 was marked fixed when this was checked this into the trunk.  This bug 
wound up being for the mozilla.org installation for them to get the update on 
their site to fix it.  Changing product, component to match.

Comment 11

[Dawn Endico]

bugzilla.mozilla.org was last updated Thu Aug 17 14:12:09 PDT 2000.

Marking fixed.

Comment 12

[Matthew Tuck [:CodeMachine]]

V.