Closed Bug 325579 Opened 19 years ago Closed 19 years ago

changing a bug generates multiple "Bug Processed"

Categories

(Bugzilla :: Creating/Changing Bugs, defect)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Version:
2.20
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: lbirdwell, Unassigned)

References

(
URL
)

Details

Attachments

(4 files)

html version of problem
45.09 KB, text/html
Details
text diffs for modified files
4.31 KB, text/plain
Details
html ver of problem #2
21.38 KB, text/html
Details
printscreen of html attachment
38.08 KB, image/png
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)
Build Identifier: Version 2.20

Making a change to a bug results in multiple "Bug Processed" tables with identical information and multiple emails sent to the same folks.

Reproducible: Always

Steps to Reproduce:
1. Change a bug, enter new comment, etc.
2. Click on commit
3. Resulting page shows multiple "Bug Processed" tables and sends multiple emails
Is it the same bug number which is reported in each "Bug Processed"? If not, can you make sure that these bugs are not in the "depends on" or "blocks" fields?
I made the attached file from the source of a page showing the problem. Some things like images are missing, but you should be able to get the idea. The bug is not related, depends on, etc. to anyother bug.
How can you have several times the page footer??? That's clearly not a standard bug. You probably have changed the code in some way.
I am the maintainer for the bugzilla that is having this problem.

The files that I have changed are the following:
skins/standard/global.css
a whole bunch of new files in skins/custom/ (all css files)
a new image (corporate logo)

new template files modified from the default ones:
template/en/custom/account/auth/login.html.tmpl
template/en/custom/bug/edit.html.tmpl
template/en/custom/bug/create/create.html.tmpl
template/en/custom/flag/list.html.tmpl
template/en/custom/global/banner.html.tmpl


Attached is a set of text diffs that I have made from the default files onto the custom files(so you can understand what changed in the codebase). These changes are not the cause of the problem because I have removed the template/en/custom folder from the installation and the problem remains.
by the way here is my checksetup.pl run:

[root@support bugzilla]# ./checksetup.pl  

Checking perl modules ...
Checking for       AppConfig (v1.52)   ok: found v1.56
Checking for             CGI (v2.93)   ok: found v3.10
Checking for    Data::Dumper (any)     ok: found v2.121_02
Checking for    Date::Format (v2.21)   ok: found v2.22
Checking for             DBI (v1.38)   ok: found v1.50
Checking for      File::Spec (v0.84)   ok: found v3.16
Checking for      File::Temp (any)     ok: found v0.14
Checking for        Template (v2.08)   ok: found v2.14
Checking for      Text::Wrap (v2001.0131) ok: found v2005.0824
Checking for    Mail::Mailer (v1.65)   ok: found v1.73
Checking for        Storable (any)     ok: found v2.15

The following Perl modules are optional:
Checking for              GD (v1.20)   ok: found v2.30
Checking for     Chart::Base (v1.0)    ok: found v2.3
Checking for     XML::Parser (any)     ok: found v2.34
Checking for       GD::Graph (any)     ok: found v1.43
Checking for GD::Text::Align (any)     ok: found v1.18
Checking for     PatchReader (v0.9.4)  ok: found v0.9.5

Checking user setup ...
Removing existing compiled templates ...
Precompiling templates ...
Checking for      DBD::mysql (v2.9003) ok: found v3.0002
Checking for           MySQL (v3.23.41) ok: found v4.1.11
Checking for        GraphViz (any)     ok: found

and I am using fedora core 4 with apache 2.0.54-10 (as listed as installed from the command "yum list | grep httpd"
These are the versions on the old slow server we had that worked

AppConfig   v1.56
CGI    v3.05
Data::Dumper      v2.121
Date::Format    v2.22
DBI    v1.40
File::Spec    v0.87
File::Temp   v0.14
Template    v2.14
Text::Wrap   v2001.09292
Mail::Mailer  v1.67
Storable  v2.13
GD  v2.23
Chart::Base  v2.3
XML::Parser  v2.34
GD::Graph  v1.43
GD::Text::Align  v1.18
PatchReader  v0.9.5

MySQL (v3.23.41) ok: found v3.23.58
GraphViz (any)     ok: found


could someone set the version to 2.20?
For the patch. Please use patch -up. But instead of diffing each file, make sure you have cvs installed and do:
cvs diff -up

(shows differences in the files known to cvs)
Severity: major → normal
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → 2.20
Thanks for the tip with cvs (I have only ever used subversion, and only in windows).

The text diffs are not meant to be a patch though, merely a demonstration that I didn't change anything other then the look and feel of bugzilla as Frédéric Buclin seemed to state. Also, wouldn't the cvs command only show the diffs for files that are under cvs? If so, it would only show the changes in skins/standard/global.css

There are changes made via the custom templates that (I think) should make there way into the codebase though (namely the changeset in template/en/custom/account/auth/login.html.tmpl) so as to facilitate skinning bugzilla with css files (it is much easier to get at the table containing the login information when it is in a named table). If that command will create a diff file that can be patched with then maybe I will file the bug.
Can you remove the skins/custom/ and template/en/custom/ directories, run checksetup.pl again and then show me how the UI looks like?

Have you altered process_bug.cgi too?
Attached file html ver of problem #2 — 

    
    

    
  


  
here it is without any modifications to the bugzilla source in an image and html forms

    
    

    
  
no I didn't modify process_bug.cgi at all

    
    

    
  
We have the same problem with our installation. It's an unmodified installation from the FreeBSD 4.10-RELEASE ports system, version 2.20.

Output of checksetup.pl:
Checking perl modules ...
Checking for       AppConfig (v1.52)   ok: found v1.56
Checking for             CGI (v2.93)   ok: found v3.15
Checking for    Data::Dumper (any)     ok: found v2.121
Checking for    Date::Format (v2.21)   ok: found v2.22
Checking for             DBI (v1.38)   ok: found v1.50
Checking for      File::Spec (v0.84)   ok: found v3.16
Checking for      File::Temp (any)     ok: found v0.16
Checking for        Template (v2.08)   ok: found v2.14
Checking for      Text::Wrap (v2001.0131) ok: found v2001.0929
Checking for    Mail::Mailer (v1.65)   ok: found v1.73
Checking for        Storable (any)     ok: found v2.15

The following Perl modules are optional:
Checking for              GD (v1.20)   ok: found v2.30
Checking for     Chart::Base (v1.0)    ok: found v2.3
Checking for     XML::Parser (any)     ok: found v2.34
Checking for       GD::Graph (any)     ok: found v1.4305
Checking for GD::Text::Align (any)     ok: found v1.18
Checking for     PatchReader (v0.9.4)  ok: found v0.9.5

Checking user setup ...
Removing existing compiled templates ...
Precompiling templates ...
Checking for      DBD::mysql (v2.9003) ok: found v3.0002
Checking for           MySQL (v3.23.41) ok: found v4.0.21-standard
Checking for        GraphViz (any)     ok: found


    
    

    
  
Bill Barry, is the comment also duplicated in bugs? Or do you "only" get several times the same email, but the comment is added only once in the bug itself?
Keywords: qawanted

    
    

    
  
I only get one comment entry, and exactly 4 copies of the same HTML output, including DOCTYPE.

It's the same wheter I comment a single bug, or a bug in a search. Ie. if I do it in a search, it will go to the next bug, and display the page with bug processed and the new bug 4 times.

    
    

    
  
(In reply to comment #16)
> I only get one comment entry, and exactly 4 copies of the same HTML output,
> including DOCTYPE.

But you say in bug 326217 that the comment is added several times: "causing the same comment to be added over 200 times to each of the bugs I change" ?!?

    
    

    
  
*** Bug 326217 has been marked as a duplicate of this bug. ***

    
    

    
  
Bug 326217, comment 7 together with http://search.cpan.org/src/MARKOV/MailTools-1.73/ChangeLog makes me think that MailTools may be the culprit... Can you try MailTools-1.67 (which is the version http://landfill.bugzilla.org/ uses)?

    
    

    
  
(In reply to comment #17)
> (In reply to comment #16)
> > I only get one comment entry, and exactly 4 copies of the same HTML output,
> > including DOCTYPE.
> 
> But you say in bug 326217 that the comment is added several times: "causing the
> same comment to be added over 200 times to each of the bugs I change" ?!?
> 

There is (was) a difference between when I changed a single bug, and when I changed multiple bugs at once.

My current fix was to swap from smtp to sendmail for mailsending.

    
    

    
  
It looks like the problem cannot be reproduced with Mail::Mailer 1.67, so it seems to be a problem with Mail::Mailer 1.73, which you both use. Moreover, we cannot reproduce the bug on 2.20.1 and 2.22rc1 seems unaffected, so for some unknown reason the bug has been fixed meanwhile.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Keywords: qawanted
Resolution: --- → INVALID

    
    

    
  
In other words: you should be able to fix the issue for you by upgrading Bugzilla to 2.20-BRANCH (and 2.20.1 after its release) or to HEAD (and 2.22 after its release). Alternatively, it appears to work with 2.20 if you downgrade MailTools to version 1.67.

If it doesn't work for you with Bugzilla 2.20-BRANCH or HEAD (no matter which version of MailTools you're using), please reopen this bug, and add a comment.

    
    

    
  
I have this problem as well.  I have Mail::Mailer 1.73, like the others who have posted here.  I upgraded to 2.20.1, and the problem persists.

For me this is reproducible by bug.  That is, for a given bug it will always happen, and the number of 'Processed' repetitions will be the same every time.  But the number of repetitions varies by bug, and some bugs have 1.  It seems to correlate with the number of email addresses in the CC list, so it may well be a mailer problem.  I will try downgrading my Mail::Mailer.

I don't have permission to reopen this bug.

    
    

    
  
(In reply to comment #23)
> I don't have permission to reopen this bug.

If it's a Mail::Mailer issue, then that's not a valid *Bugzilla* bug. And so there is no reason to reopen it.

    
    

    
  
I solved this by upgrading my Mail::Mailer from 1.73 to 1.74.  When process_bug.cgi executed this line:

    $template->process("bug/process/results.html.tmpl", $vars)
      || ThrowTemplateError($template->error());

... Mail::Mailer would somehow fork into two or more processes, all of which sent mail and then retured from this method call and executed the rest of the cgi script, leading to more than one 'Bug processed' message.  But all looks good in 1.74.

    
    

    
  
Thanks for the feedback, Dan. This may mean to 1.73 users that it's not necessary to downgrade, but that they may upgrade instead.

    
    

    
  
*** Bug 338548 has been marked as a duplicate of this bug. ***

    
    

    
  
(In reply to comment #26)
> Thanks for the feedback, Dan. This may mean to 1.73 users that it's not
> necessary to downgrade, but that they may upgrade instead.
> 

I am running 2.22, and it was exhibiting this problem with 1.73. I just upgraded to 1.74 and confirmed that it fixes it.

    
    

    
  
This bug no longer needs to be relnoted, since we use Email:: and not Mail:: now.
Keywords: relnote

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: