Bugzilla:Modifying Your Installation

The purpose of this wiki is to describe how Bugzilla bug tracking tool can be modified to fit a particular need or support a particular feature.

Before modifying Bugzilla, make sure to make a backup of any and all Bugzilla files.

Before Modifying

Before doing any modifications to Bugzilla, you must have access to the server where Bugzilla is kept and the database used by Bugzilla. In addition, you should have Bugzilla administrator access to edit various program parameters. Make sure that you know any required passwords like the login to Bugzilla or the password to access the database.

Bugzilla Components

The Bugzilla implementation is divided into four separate parts each of which may need modification depending on the talks.

Database

The most important part of Bugzilla is the MySQL database. The default installation contains 35 tables - for Bugzilla 2.18.

• bugs: the most important table contains all of the bugs of the system. It is made up of various bug properties including all of the enum values like severity and priority. To change those values in the user interface, they must be changed in the database in the bugs table. It is important to first create the new value in addition to the old value, copy the old value into the new value, and only afterwards get rid of the old value.
• fielddefs: this table contains all of the fields of the user interface with their default names and descriptions. The descriptions are what shows up when viewing bug history and should be changed if a name of a field is changed in the user interface. DO NOT change the name column as this will break the system. Only the description column is visible to the user - except when exporting a CSV file, when the user gets the column name.
• series: this table contains the default search parameters for reports. It should be edited if status and/or resolution enum values are changed.
• All other tables are self explanatory. Most, like product, component, version, and target_milestone can be changed from the user interface.

Note on changing things directly in the database, especially the bugs table: If you're not careful, you'll change the delta_ts (timestamp) field of the affected bugs, and the next time you do a sanity check, Bugzilla will warn you that bugmail hasn't been sent out! To avoid this, set up your SQL statement like this:

UPDATE bugs SET whateverfield="whatever", anotherfield="something", delta_ts=delta_ts ...

CSS

All of Bugzilla CSS files are in the Bugzilla root css folder. They are solely used for colors and fonts within Bugzilla. The following CSS files are present

• buglist.css: this is the CSS for the list of bugs displayed by search.
• duplicates.css: specifies how duplicate bugs are displayed.
• global.css: contains data for displaying the banner, header, and footer on multiple pages.
• Two other CSS files (panel.css and show_multiple.css) are present but I am not sure what their use is.

Templates - Look and Feel

This is the most important part of the user interface. It should be noted that templates work very closely with Perl CGI (used to provide logic for accessing the database and generating HTML pages) and PL (used as separate scripts to perform operations like diagnostics outside of normal Bugzilla functionality) files described in the next section, and depending on what needs to be done, both may require editing. For templates, only the templates in the root template folder should be edited. DO NOT edit templates in any folder that is in the data root folder as those are the compiled template and will be overwritten. Templates are located in various folders that represent parts of the user interface. The are .html.tmpl files that are made up of html, Perl, and java script. NOTE: files generated from templates look different in IE compared to Mozilla based browsers like Firefox.

• The templates used are from the Template Toolkit 2 - see http://www.template-toolkit.org/

• account: this folder contains templates that display user account preferences pages.
• admin: contains templates for admin pages.
• attachments: contains templates for attachment pages like pages for adding the attachments.
• bug: contains templates for displaying bugs. The top directory contains the show.html.tmpl template that encapsulates all other templates.
  • edit: this is the template for the bug display page. This file was heavily edited. It contains special CSS inlines that change color to gray on knobs.
  • knob: this is the template for the submit button with the radio buttons displayed on the edit page.
  • navigate: this is the template for the navigation menu on the top.
  • show-multiple: this is the template for page that displays bug info as it is formatted for printing.
  • Inside the bug folder are various folders that provide bug functions.
    • activity: this is where the template for the bug activity page is stored. The values and names of fields have to be edited in the database.
    • create: the template for the page for creating the bug is in the template by the same name. Very heavily modified.
• flag: this folder contains a single template for displaying flags. This is where the visualization of flags is modified.
• global: this contains various global templates
  • banner: the banner at the top in the header.
  • field-descs: contains descriptions of the fields. Should be edited if a field name in the user interfaces changes.
  • footer/header: footers and headers for all of the pages.
• list: contains templates for listing bugs after they are found by search.
  • change-columns: the change columns template for the edit page where the user selects which columns to display. The actual list is stored in globals.pl.
  • edit-multiple: page for editing multiple bugs at the same time; similar to the edit page in bug; however, the knob button and radio buttons are built into this template along with all the fields.
  • list: this is the list of bugs being displayed.
  • table: various properties, like names of column headers, for displaying the columns in the list are stored in this file. The order of columns is in globals.pl file.
• pages: contains help templates that display help messages and are linked to field names in edit and create pages. The two important templates here are bug-writing and fields.
• reports: this is where various templates for charts, graphs, and reports are stored.
• request: not sure. Never had to edit anything here. Probably email requests.
• search: here is where all the search pages are located.
  • boolean-charts: the three horizontal fields at the bottom of the search page.
  • form: the main search page with all fields on it.
  • search-specific: the search specific page. Here is where you can edit the contents of the search specific fields. Make sure to edit just their names and not their values.

Perl files

Come in .cgi and .pl varieties and are in the root Bugzilla directory. They are arguably the hardest part to understand and work closely with both database and templates.

• buglist.cgi: this is the list of bugs and how it is displayed to the user. This is where the order of columns should be edited for the Mozilla browsers.
• checksetup.pl: this script is run on setup of the database to set default values. I did some modifications to it but DO NOT run it.
• colchange.cgi: determines which columns are displayed and in what order on the column change page. The default selected columns are specified in the globals.pl file.
• edit.cgi: those files allow the editing of a variety of Bugzilla components like params, users, version, etc.
• enter_bug.cgi: displays bug entry form. Does not need to be changed if changes are made to the template.
• globals.pl: this is where default columns for lists and order of items for IE are specified.
• post_bug/process_bug.cgi: enter and edit scripts for the bugs. May require lots of changes. process_bug.cgi contains the switch statement for all knob buttons on edit pages based on the command each one generates.
• query.cgi: performs searches.

Bugzilla Parameters

Administrators have access to the parameters page in the footer of any Bugzilla page. Here is where a variety of global parameters can be activated or deactivated.

• Status Whiteboard: this is an extra field that can be used or called for anything extra like a new text field. It is not being used but can be activated here.
• Comment on: here is where you can set comments to be required depending on what the user does.
• Default search: sets the default options for the search page.
• Plug-ins/shadowing: allows the specification of plug-in and shadowing databases.
• Emails: this is where the contents of emails sent to the users are specified. The type of email is specified by each user through preferences.

Now that you have installed Bugzilla, you should visit the 'Parameters' page (linked in the footer of the Administrator account) to ensure it is set up as you wish - this includes setting the 'urlbase' option to the correct url.

Changes to Bugzilla

Status and Resolution

Changes in status and resolution require changes in many files including multiple scripts and knob/edit-multiple templates. It is best to do a global search in all files for old values to see where new values should be inserted.

How To Add Custom Fields

First, be aware that this may be a Bad Idea.

Gerv put together a good webpage about this: http://www.gerv.net/hacking/custom-fields.html

For example, Flags are currently used by many to represent versions in which the bug has been fixed. If components are used, different flags can be used with each component to represent something different.

If you absolutely have to have a custom field, consider co-opting one of the existing fields.

• For example, if you have only a dozen clients, then "Hardware" might be appropriate.
• If you don't use the URL, consider changing the front end to call it "Ticket number".
• For text, the Status Whiteboard and QA Contact fields are available.
• There are numerous enum fields like op_sys and hardware that are no longer being used.
• The priority field has been changed to display the type of bug.
• There are also dependency and voting fields that could be changes if needed.

You get the idea.

If that doesn't suffice for you, there is a patch (that works at least with 2.18) to add custom fields: https://bugzilla.mozilla.org/show_bug.cgi?id=91037

This may help, but the search front end isn't super, and there may be other problems. I can confirm that it worked on a clean installation of 2.18 & does provide functionality. I can also confirm that I found it easier to co-opt the hardware field - I never did use any of the custom fields.

Finally, if you absolutely have to build your own field, get ready to dig into the guts of Bugzilla, and good luck!

• There is a bug_type field in the database but it is not used in the Bugzilla implementation and is simply there for backwards compatibility. I have not been able to get it to show up in the user interface. Instead the priority field is used to store the type.
• Creating a new field from scratch is relatively hard. There are directions for how to do it in original Bugzilla report (bugzilla.doc). It seems relatively easy for a single value field to be added into the bug table; however, I tried to create by own table similar to cc and it turned out to be a nightmare. Perl knowledge may be required.

Other Tips and Hints

• To change font and/or background, it is easy to use CSS inlined within the template file. See bug/edit.html.tmpl for example.
• The easiest way to edit files is to make a copy of all files in the bugzilla directory and edit the files on the actual bugzilla server refreshing the browser to see the results. If something goes wrong, the original copy is saved. I made a copy of the very original files; compare it with the current version to see my changes. Remember that if you're changing templates, you'll need to rerun checksetup.pl!
• Use good software for editing files. I use PSPad (http://www.pspad.com/) which is a freeware and Beyond Compare to compare files. PSPad has a built-in global directory search and comparison. I used Wordpad originally and PSPad greatly improved my productivity.
• Pages show-up differently in Firefox (Mozilla) in comparison to IE. Make sure to test each page in both.

Known Modification Issues and Bugs

Modification Examples

See also

References

• http://www.bugzilla.org/docs/ - Bugzilla Official Manuals
• https://bugzilla.mozilla.org/ - Bugzilla's Bugzilla (see if your problem is described here)
• netscape.public.mozilla.webtools - Bugzilla's newsgroup (use it to post specific, detailed questions you cannot find solutions for on your own)
• http://www.google.com - Google (search for examples, how-tos for languages, etc.)

External links

• http://www.bugzilla.org - Bugzilla home page