36379 - bug_email.pl fixed to enable default component & product via command-line

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, enhancement, P3)

Description

[Matthew Barnson]

We're using bugzilla as both a bug-tracking and system administration
trouble-ticket tracking system.  The below diff allows default product and
component to be set via command-line switches.
The switches are:
-p='PRODUCT'
-c='COMPONENT'
  This comes in really handy if you specify different procmailrc files based
upon which email address things are sent to.  We have various queues for network
operations issues, development, QA, etc.  Hope this makes it into release!

724,731d712
<     if ( /-p=['"]?(.+)['"]?/ )
<     {
<       $DEFAULT_PRODUCT = $1;
<     }
<     if ( /-c=['"]?(.+)["']?/ )
<     {
<       $DEFAULT_COMPONENT = $1;
<     }

Comment 1

[Matthew Barnson]

We're continuing to modify this so that all parameters can be specified from
command-line options to bug_email.pl.  This way, users can just email to a
specific email address and receive no warnings regarding their mail -- it will
all be correct to good defaults for the queue to which they submitted the bug.

Comment 2

[Seth Landsman]

I don't know that this should be commandline.  Isn't this what params() are for?

Comment 3

[Matthew Barnson]

I don't agree that this should be in params, unless there is a way to be able to
specify multiple queues within params that submissions could be entered in.  We
are using Bugzilla as a comprehensive trouble-ticket and bug-tracking system --
it's very cool to be able to assign issues to our support tiers based upon what
mail address they are sent to.  Let me give you an idea how we're using this:

in /etc/aliases:
# Bugzilla stuff
bugs:                   | "/usr/bin/procmail -m /etc/procmailrcs/bugs"
operations:             | "/usr/bin/procmail -m /etc/procmailrcs/operations"
prodopsq:               | "/usr/bin/procmail -m /etc/procmailrcs/prodopsq"
it_support:             | "/usr/bin/procmail -m /etc/procmailrcs/it_support"
netops:                 | "/usr/bin/procmail -m /etc/procmailrcs/netops"
elbugs:                 | "/usr/bin/procmail -m /etc/procmailrcs/elbugs"
qa:                     | "/usr/bin/procmail -m /etc/procmailrcs/qa"
newstore_qa:            | "/usr/bin/procmail -m /etc/procmailrcs/qa"
build:                  | "/usr/bin/procmail -m /etc/procmailrcs/build"

OK, so the email goes into a different procmail file depending upon the email to
whom it was submitted...  Now a couple sample procmailrc files -- note that they
are very similar to the defaults, except for the RESULT line specifying the
command-line options for the queue they go into:

/etc/procmailrcs/operations:
:0 fhw
| formail -I "From " -a "From "
 
BUGZILLA_HOME=/usr/local/bugzilla/
 
:0
* ^Subject: .*\[Bug .*\]
RESULT=|(cd $BUGZILLA_HOME/contrib && ./bugzilla_email_append.pl)
 
 
# Feed mail to stdin of bug_email.pl
:0 Ec
#* !^Subject: .*[Bug .*]
RESULT=|(cd $BUGZILLA_HOME/contrib && ./bug_email.pl -p='Tier_3_Operations'
-c='General' )
 
# write result to a logfile
:0 c
|echo `date '+%d.%m.%y %H:%M:  '` $RESULT >> $HOME/bug_email.log
 
 
:0 c
|echo "----------------------------------" >> $HOME/bug_email.log
 
:0 c
$HOME/bug_email.log
 
# Move mail to the inbox
:0
$HOME/Mail/INBOX




Now /etc/procmailrcs/it_support (just for clarity):
:0 fhw
| formail -I "From " -a "From "
 
BUGZILLA_HOME=/usr/local/bugzilla/
 
:0
* ^Subject: .*\[Bug .*\]
RESULT=|(cd $BUGZILLA_HOME/contrib && ./bugzilla_email_append.pl)
 
 
# Feed mail to stdin of bug_email.pl
:0 Ec
#* !^Subject: .*[Bug .*]
RESULT=|(cd $BUGZILLA_HOME/contrib && ./bug_email.pl -p='IT_Support'
-c='General' )
 
# write result to a logfile
:0 c
|echo `date '+%d.%m.%y %H:%M:  '` $RESULT >> $HOME/bug_email.log
 
 
:0 c
|echo "----------------------------------" >> $HOME/bug_email.log
 
:0 c
$HOME/bug_email.log
 
# Move mail to the inbox
:0
$HOME/Mail/INBOX


------
Understand my background -- we are using Bugzilla to move away from separate
request ticket tracking systems (wwwreq/reqng) and bug-tracking database
(globetrack).  It's incredibly convenient to have multiple email aliases that
dump requests in based on to whom they are sent.

Seth, I'm assigning this one to you, along with 36341; let me know if you'd
prefer it not be :)  Also, I think this one would be better served by using the
Getopt::Long module for parsing command-line options rather than my code above
-- what do you think?

Comment 4

[Seth Landsman]

I'm fine taking this.  Life is a little busy until end of next week, but I'll
make this happen after that.

Comment 5

[Seth Landsman]

Ugh.  I thought I accepted these.

Comment 6

[Dave Miller [:justdave]]

Matt, I'm very interested in this...  we would make use of it at my site.  Since 
you sound like you have it running already, would it be possible to supply a 
patch?  It would save Seth the trouble of trying to recreate what you already 
did...

Comment 7

[Dave Miller [:justdave]]

CCing Dan Berlin, who from stuff I've seen around, I know is actually using the
bug_email stuff.  I'd appreciate any input or fixes you'd be willing to provide
on these bugs :-)

Comment 8

[Ludovic Dubost]

Attachment: Patch against 2.17 Head

Here is a patch for this modification. I also added the ability to set the
VERSION field by command line..

Comment 9

[Dave Miller [:justdave]]

approved for contrib

Comment 10

[Dave Miller [:justdave]]

Checking in bug_email.pl;
/cvsroot/mozilla/webtools/bugzilla/contrib/bug_email.pl,v  <--  bug_email.pl
new revision: 1.18; previous revision: 1.17
done