The Bugzilla Mail Interface

Contributor: Klaas Freitag, SuSE GmbH

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.

I know, show me the example-mail !

What do you need to do to submitt a bug by mail ?

You need to send a email in the described format to the bugmail-user of the bugzilla-system. This is yourbugzilla@here.com 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.

Please dont refuse to send one or two wrong mails, you will get all the information you need in the replies, and only 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.

The Mail Format

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.

Keywords

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.
Keyword Value description required and default value
@product The product which has a bug yes.
This is the most important information. Many other fields depend on the product.
@component the desired component which is affected by the bug yes.
As the @product, this is a very important field.
@version The version of the product yes.
See @product and @component
@short_desc A summary of your bug report yes.
This summary of the error you want to report describes what happen. You may skip the long description, but not this summary.
Note:The short description may be given in the mail subject instead of using the keyword !
@rep_platform The desired platform no.
If you dont give a value, this field is set to All.
@bug_severity The severity of the bug no.
If you dont give a value, this field is set to normal
@priority The priority of the bug no.
If you dont give a value, this field is set to P3
@op_sys The operating system no.
If you dont give a value, this field is set to Linux.
@assigned_to The one to whom the bug is assigned to no.
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.
@bug_file_loc ? no.
@status_whiteboard ? no.
@target_milestone ? no.
@groupset rules the visibility of the bug. no.
This value defaults to the smallest of the available groups, which is readInternal.
@qa_contact the quality manager for the product no.
This value can be retrieved from product, component and version

Valid values

Give string values for the most keys above. Some keywords require special values:
  1. 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.
  2. 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.
  3. free Text: The descriptions may be free text.
  4. Special: The field groupset may be specified in different in three different kinds:
    1. A plain numeric way, which is one usually huge number, e. g. 65536
    2. a string with added numbers e.g. 65536+131072
    3. a string list, e.g. ReadInternal, ReadBeta

But most of them need valid values.

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.

Some of the values must be choosen from a list:

  1. bug_severity: blocker, critical, major, normal, minor, trivial, enhancement
  2. op_sys: Linux
  3. priority: P1, P2, P3, P4, P5
  4. rep_platform: All, i386, AXP, i686, Other

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.

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.

Attachments

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.

Example Mail

See the example of the mail body (Dont forget to specify the short description in the mail subject):

  @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.