This article is part of Managing bug report in issue tracker series.

See managing bug reports in issue tracker for common information. Please, read it first. For common information and setup of BugZilla itself - please see this article. The text below assumes that you already completed BugZilla installation.

Below are detailed steps for recommended BugZilla setup for automatic bug report submission. Before going through setup - make sure to upgrade your BugZilla to the latest version.

Some steps below are optional, some steps must be executed only once (like custom fields creation), other are executed from time to time (like creating new projects for your new products) and the rest are executed regularly (like creating product versions).

Full list of necessary actions contains:

Please note that all actions below are just examples. It's recommendation, but it's not necessary to be absolutely like that. You may use another configuration.

Note: You can use BugZilla as external bug tracker for GitLab.

Creating custom fields

1. (Administration/Custom Fields) Create custom field to improve usefulness of EurekaLog. Most important field is "Count" - to store number of sent/occurred problems. Its type should be "Integer"; field name can be arbitrary, like "Occurrences", "Bug count", "Popularity", "Incidents", "Hit Count", etc. Other suggested custom fields are: "BugID" (to store BugID and search issues) and "e-mail" ("user e-mail", which is typically entered in MS Classic error dialog). Both fields should be text fields. Do not use "Bug ID" field type for "BugID" field. Again, field names can be anything.

We strongly recommend to create at least "Count" field.

Example: two new custom fields

Suggested setup for "Count" field

Suggested setup for "e-mail" and "BugID" fields

2. Create any other additional fields as you need/like (you can submit values for custom fields at run-time via OnCustomWebFieldsRequest event).

Creating user accounts

1. (Administration/Users) Create new non-admin user account for bug report submission. Create it with disabled e-mail notifications:

Creating new user

2. Log off and log in as this user. Go to "Preferences" and clear e-mail notifications, set default settings and switch language to "English":

Setting properties of submitter account - general

Setting properties of submitter account - e-mail notifications

3. (Optional, but strongly recommended; only for latest BugZilla versions) Go to Preferences / API Keys and create new API token:

Creating new API token for bug reporter account

New API key was created

Once API key was created - select it and copy to buffer. You will need to enter it into EurekaLog settings later.

You may create additional token keys.

4. Now, log off and log in again as administrator.

Repeat these steps for each bug submitter user account which you've created.

5. You can also create a new group of users and include all bug-reporting user accounts into that group (Administration/Groups):

Creating new user group for bug reporting

Note: by default "editbugs" group is assigned to all users. You may want to exclude your bug reporting account from "editbugs" - to do this, edit "editbugs" group and remove default regular expression ".*". Include all necessary users to that group.

6. Open bug reporting user account and include it into a bug reporting group:

Suggested group setup for bug reporting user accounts

Repeat this for all bug reporting accounts.

Creating projects

1. (Administration/Products) Create project for your software product (projects are called products in BugZilla). You may create several projects - one for each of your software products.

Creating new project for bug reports

2. Create components for the projects. If you don't need components - create something like "General" or "unspecified" component. Typically component is used for identification of the part of your software product.

3. Create versions for the project. If you don't use versioning (highly unrecommended) - you can skip this step.

You should create new version for each release of your software. I.e. when you release (publish on site, send to custom, etc) "YourSoftware 1.0.0.0" - you need to create "1.0.0.0" version. When you release update: "YourSoftware 1.0.1.0" - you need to add "1.0.1.0" version.

Version strings can be arbitrary like "1", "1.0", "1.0.1", "1.0.1.0" or even "1.0.1.0 beta 3". However, it's recommended to use four-number versions with optional textual description, for example: "1.0.1.0" and "1.0.1.0 beta 3".

Note: if you don't want to edit project each time you release new version - you can create versions for the future use. I.e. when you release "YourSoftware 1.0.0.0" - you can create "1.0.0.0", "1.0.1.0", "1.0.2.0", "1.0.3.0"..."1.0.10.0" versions.

For example:

Components and versions

When reporting - version are taken from file's version information, so you must supply the corresponding version in description of your .exe or .dll files.

4. Setup project access rights - limit actions to members of auto-reporting group:

Example of limited rights configuration

Detailed view of group access rights to the project

Note: by default bug reporting user accounts will have access to all other projects, unless these projects has group with "Entry" assigned. I.e. by default project has no group assigned - this means world access to project. You should explicitly add group to project to exclude other users (non-members) from accessing project.

EurekaLog setup

1. Enter BugZilla details into EurekaLog settings of your projects:

BugZilla settings filled into EurekaLog options

Important Note: we recommend to use API keys (tokens) when possible. If you are still going to use login/password pair (for example, you are using old BugZilla version, which does not have API keys) - use your e-mail as login.

2. Set any additional/common send options.

3. Set/fill custom fields. EurekaLog has support for automatic managing of "Count", "BugID" and "E-Mail" fields. You just need to enter field names in EurekaLog options. For other custom fields you have to fill them manually, for example:

uses

  EEvents, ESysInfo;

procedure SetCustomFields(const ACustom: Pointer; AExceptionInfo: TEurekaExceptionInfo; 

  ASender: TObject; AWebFields: TStrings; var ACallNextHandler: Boolean);

begin

  AWebFields.Values['cf_license'] := GetYourApplicationLicense;

end;

initialization

  RegisterEventCustomWebFieldsRequest(nil, SetCustomFields);

end.

4. Add any custom data, additional attached files, write necessary event handlers, set exception filters, etc, etc.

Testing

1. Test sending. You can do this right in the EurekaLog send options dialog - by clicking on "Test..." button. This will send test bug report.

Suggested actions are:

These actions should test that sending is actually working.

2. Now it's time to test your application-specific sending.

Now your application is ready for deployment.

Maintaining projects

1. You need to create or update project versions when you ship new release of your software. If you've created a batch of versions in BugZilla for future use - you may skip it until you've run out of versions.

See also: