BugsSite/contrib/bugmail_help.html - WebKit - Git at Google

 <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 a default assignee for every product/version/component.
 		He owns the bug by default. The default assignee 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>
	<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 a default assignee for every product/version/component.
	He owns the bug by default. The default assignee 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>