summaryrefslogtreecommitdiffstats
path: root/contrib
diff options
context:
space:
mode:
authorterry%mozilla.org <>2000-03-08 02:36:38 +0100
committerterry%mozilla.org <>2000-03-08 02:36:38 +0100
commit7f9697e92f49678189365c0a70349a55bf8d83c1 (patch)
tree56091f0731087bec2123cf4a69d9b09e7d6659fb /contrib
parentd587a9fa5bb0e2733770fb36e4c1b40af31e82a9 (diff)
downloadbugzilla-7f9697e92f49678189365c0a70349a55bf8d83c1.tar.gz
bugzilla-7f9697e92f49678189365c0a70349a55bf8d83c1.tar.xz
Submission by Klaas Freitag <freitag@suse.de>.
Diffstat (limited to 'contrib')
-rw-r--r--contrib/README8
-rw-r--r--contrib/README.Mailif68
-rw-r--r--contrib/bugmail_help.html223
3 files changed, 299 insertions, 0 deletions
diff --git a/contrib/README b/contrib/README
index 89ad2c58d..32ec834a9 100644
--- a/contrib/README
+++ b/contrib/README
@@ -8,3 +8,11 @@ This directory includes:
gnats2bz.pl -- a perl script to help import bugs from a GNATS
database into a Bugzilla database. Contributed by
Tom Schutter <tom@platte.com>
+
+ bug_email.pl -- a perl script that can receive email containing
+ bug reports (email-interface). Contributed by
+ Klaas Freitag <freitag@SuSE.de>
+
+ README.Mailif -- Readme describing the mail interface.
+ bugmail_help.html -- User help page for the mail interface.
+
diff --git a/contrib/README.Mailif b/contrib/README.Mailif
new file mode 100644
index 000000000..c058b0e16
--- /dev/null
+++ b/contrib/README.Mailif
@@ -0,0 +1,68 @@
+
+The Bugzilla Mail interface
+===========================
+The Bugzilla Mail interface allows to submit bugs to Bugzilla by email.
+
+The Mail Interface Contribution consists of three files:
+README.Mailif - this readme.
+bug_email.pl - the script
+bugmail_help.html - a user help html site
+
+Installation:
+
+Copy the files
+ bugmail_help.html
+ bug_email.pl
+to your bugzilla-directory, where all your bugzilla cgi-files reside.
+
+Next is to add a user who receives the bugmails, e. g. bugmail. Create a
+mail account and a home directory for the user.
+
+The mailinterface script bug_email.pl needs to get the mail through stdin.
+I use procmail for that, with the following line in the .procmailrc:
+
+BUGZILLA_HOME=/usr/local/httpd/htdocs/bugzilla
+:0 c
+|(cd $BUGZILLA_HOME/contrib; ./bug_email.pl)
+
+This defines the Bugzilla directory as the variable BUGZILLA_HOME and passes
+all incoming mail to the script after cd'ing into the bugzilla home.
+
+Customation:
+
+There are some values inside the script which need to be customized for your
+needs:
+
+1. In sub-routine Reply (search 'sub Reply':
+there is the line
+ print MAIL "From: Bugzilla Mailinterface<yourmail\@here.com>\n";
+ ^^^^^^^^^^^^^^^^^^^^
+Fill in your correct mail here. That will make it easy for people to reply
+to the mail.
+
+2. check, if your sendmail resides in /usr/sbin/sendmail, change the path if neccessary.
+Search the script after 'default' - you find some default-Settings for bug
+reports, which are used, if the sender did not send a field for it. The defaults
+should be checked and changed.
+
+Thats hopefully all, we will come up with any configuration file or something.
+
+
+If your mail works, your script will insert mails from now on.
+
+The mailinterface supports two commandline switches:
+
+There are two command line switches :
+
+-t: Testmode
+ The mailinterface does not really insert the bug into the database, but
+ writes some debug output to stdout and writes the mail into the file
+ bug_email_test.log in the data-dir.
+
+-r: restricted mode
+ All lines before the first line with a keyword character are skipped.
+ In not restricted, default mode, these lines are added to the long
+ description of the bug.
+
+
+02/2000 - Klaas Freitag, SuSE GmbH <freitag@suse.de> \ No newline at end of file
diff --git a/contrib/bugmail_help.html b/contrib/bugmail_help.html
new file mode 100644
index 000000000..00b0f5153
--- /dev/null
+++ b/contrib/bugmail_help.html
@@ -0,0 +1,223 @@
+<HTML>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<!--
+ The contents of this file are subject to the Mozilla Public
+ License Version 1.1 (the "License"); you may not use this file
+ except in compliance with the License. You may obtain a copy of
+ the License at http://www.mozilla.org/MPL/
+
+ Software distributed under the License is distributed on an "AS
+ IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
+ implied. See the License for the specific language governing
+ rights and limitations under the License.
+
+ The Original Code is the Bugzilla Bug Tracking System.
+
+ Contributor(s): Klaas Freitag <Freitag@SuSE.de>
+-->
+
+<HEAD> <TITLE>Bugzilla Mail Interface</TITLE> </HEAD>
+<BODY BGCOLOR="#FFFFFF">
+<CENTER><H1>The Bugzilla Mail Interface</H1>
+Contributor: <A HREF="mailto:freitag@suse.de">Klaas Freitag</A>, SuSE GmbH
+</CENTER>
+<P>
+The bugzilla Mail interface allows the registered bugzilla users to submit bugs by
+sending email with a bug description. This is usefull for people, who do not work
+inhouse and want to submitt bugs to the bugzilla system.
+<p>
+
+
+I know, show me the <A HREF="#examplemail">example-mail !</A>
+
+
+<H2>What do you need to do to submitt a bug by mail ?</H2>
+You need to send a email in the described format to the bugmail-user of the
+bugzilla-system. This is <A HREF="mailto:our_bugzilla@xyz.com">yourbugzilla@here.com</A>
+
+You receive a reply mail with the new bug-ID if your request was ok.
+If not, you get a mail with
+some help on the bugmail system and a specific analysis of your request.
+<P>
+Please dont refuse to send one or two wrong mails, you will get all the information
+you need in the replies, and <I>only</I> in the mail replies. The information on this
+page, concerning available products, versions and so on, is not dynamicly generated and
+may be old therefore.
+
+<H1>The Mail Format</H1>
+The bugmail needs a special format , which consists of some keywords and suitable
+values for them and a description text. Note that the keyword block needs to be
+above of the description text.
+
+<H2>Keywords</H2>
+You need to tell bugzilla some properties of the bugs. This is done by keywords, which
+start on a new line with a @, followed by the keyword and and equal-sign, followed by a
+hopefully valid value.
+
+
+<TABLE BORDER=4 FRAME=box CELLSPACING="5" width=95%> <COLGROUP> <col width="2*">
+<col width="5*"> <col width="1*"> </COLGROUP>
+ <TR>
+ <TH>Keyword</TH>
+ <TH>Value description</TH>
+ <TH>required and default value</TH>
+ </TR>
+ <TR>
+ <TD>@product</TD>
+ <TD>The product which has a bug</TD>
+ <TD>yes. <br> This is the most important information. Many other
+ fields depend on the product.</TD>
+ </TR>
+ <TR>
+ <TD>@component</TD>
+ <TD>the desired component which is affected by the bug</TD>
+ <TD>yes. <br> As the @product, this is a very important
+ field.</TD>
+ </TR>
+ <TR>
+ <TD>@version</TD>
+ <TD>The version of the product</TD>
+ <TD>yes. <br>See @product and @component</TD>
+ </TR>
+ <TR>
+ <TD>@short_desc</TD>
+ <TD>A summary of your bug report</TD>
+ <TD>yes. <br>This summary of the error you want to report
+ describes what happen. You may skip the long description,
+ but not this summary.<br>
+ <b>Note:</b>The short description may be given in the mail subject
+ instead of using the keyword !</TD>
+ </TR>
+ <TR>
+ <TD>@rep_platform</TD>
+ <TD>The desired platform</TD>
+ <TD>no.<br>If you dont give a value, this field is set to <I>All</I>.</TD>
+ </TR>
+ <TR>
+ <TD>@bug_severity</TD>
+ <TD>The severity of the bug</TD>
+ <TD>no. <br> If you dont give a value, this field is set to
+ <I>normal</I></TD>
+ </TR>
+ <TR>
+ <TD>@priority</TD>
+ <TD>The priority of the bug</TD>
+ <TD>no.<br>If you dont give a value, this field is set to <I>P3</I></TD>
+ </TR>
+ <TR>
+ <TD>@op_sys</TD>
+ <TD>The operating system</TD>
+ <TD>no.<br>If you dont give a value, this field is set to <I>Linux</I>.</TD>
+ </TR>
+ <TR>
+ <TD>@assigned_to</TD>
+ <TD>The one to whom the bug is assigned to</TD>
+ <TD>no. <br>There is an initial owner for every product/version/component.
+ He owns the bug by default. The initial owner can only be found if
+ product, version and component are valid.</TD>
+ </TR>
+ <TR>
+ <TD>@bug_file_loc</TD>
+ <TD>?</TD>
+ <TD>no.</TD>
+ </TR>
+ <TR>
+ <TD>@status_whiteboard</TD>
+ <TD>?</TD>
+ <TD>no.</TD>
+ </TR>
+ <TR>
+ <TD>@target_milestone</TD>
+ <TD>?</TD>
+ <TD>no.</TD>
+ </TR>
+ <TR>
+ <TD>@groupset</TD>
+ <TD>rules the visibility of the bug.</TD>
+ <TD>no.<br>This value defaults to the smallest of the available groups,
+ which is <I>readInternal</I>.</TD>
+ </TR>
+ <TR>
+ <TD>@qa_contact</TD>
+ <TD>the quality manager for the product</TD>
+ <TD>no.<br>This value can be retrieved from product, component and
+ version</TD>
+ </TR>
+
+</TABLE>
+<H2>Valid values</H2>
+Give string values for the most keys above. Some keywords require special values:<br>
+<ol>
+<li>E-Mail adresses: If you want to set the qa-contact, specify a email-adress for @qa_contact. The email must be known by bugzilla of course.</li>
+<li>Listvalues: Most of the values have to be one of a list of valid values. Try by sending
+a mail and read the reply. Skip fields if you dont get help for them unless you dont know
+which values you may choose.</li>
+<li>free Text: The descriptions may be free text. </li>
+<li>Special: The field groupset may be specified in different in three different kinds:
+ <ol>
+ <li> A plain numeric way, which is one usually huge number, e. g. <I>65536</I></li>
+ <li> a string with added numbers e.g. <I>65536+131072</I></li>
+ <li> a string list, e.g. <I>ReadInternal, ReadBeta </I></li>
+ </ol>
+</li>
+</ol>
+
+<p>
+
+But most of them need <b>valid</b> values.
+<p>
+Sorry, you will not find lists of valid products, components and the other stuff
+here. Send a mail to with any text, and you will get a list of valid keywords in the reply.
+
+<p>
+Some of the values must be choosen from a list:<br>
+<ol>
+ <li>bug_severity: blocker, critical, major, normal, minor, trivial, enhancement</li>
+ <li>op_sys: Linux </li>
+ <li>priority: P1, P2, P3, P4, P5</li>
+ <li>rep_platform: All, i386, AXP, i686, Other</li></ol>
+
+
+<p>
+
+After you have specified the required keywords and maybe some other value, you may
+describe your bug. You dont need a keyword for starting your bug description. All
+text which follows the keyword block is handled as long description of the bug.
+<p>
+
+The bugmail interface is able to find required information by itself. E.g. if you specify
+a product which has exactly one component, this component will be found by the interface
+automatically.
+
+<H1>Attachments</H1>
+
+The mail interface is able to cope with MIME-attachments.
+People could for example add a logfile as a mail attachment, and it will appear in
+bugzilla as attachment. A comment for the attachment should be added, it will describe
+the attachment in bugzilla.
+
+<H1><A NAME="examplemail">Example Mail</A></H1>
+
+See the example of the mail <b>body</b> (Dont forget to specify the short description
+in the mail subject):<hr><pre>
+
+ @product = Bugzilla
+ @component = general
+ @version = All
+ @groupset = ReadWorld ReadPartners
+ @op_sys = Linux
+ @priority = P3
+ @rep_platform = i386
+
+
+ This is the description of the bug I found. It is not neccessary to start
+ it with a keyword.
+
+ Note: The short_description is neccessary and may be given with the keyword
+ @short_description or will be retrieved from the mail subject.
+
+
+</pre><hr>
+
+</BODY>
+</HTML>