2.3. Optional Additional Configuration

2.3.1. Bug Graphs

If you have installed the necessary Perl modules you can start collecting statistics for the nifty Bugzilla graphs.

bash# crontab -e

This should bring up the crontab file in your editor. Add a cron entry like this to run collectstats.pl daily at 5 after midnight:

5 0 * * * cd <your-bugzilla-directory> ; ./collectstats.pl

After two days have passed you'll be able to view bug graphs from the Reports page.

Windows does not have 'cron', but it does have the Task Scheduler, which performs the same duties. There are also third-party tools that can be used to implement cron, such as nncron.

2.3.2. Dependency Charts

As well as the text-based dependency trees, Bugzilla also supports a graphical view of dependency relationships, using a package called 'dot'. Exactly how this works is controlled by the 'webdotbase' parameter, which can have one of three values:

1. A complete file path to the command 'dot' (part of GraphViz) will generate the graphs locally

2. A URL prefix pointing to an installation of the webdot package will generate the graphs remotely

3. A blank value will disable dependency graphing.

The easiest way to get this working is to install GraphViz. If you do that, you need to enable server-side image maps in Apache. Alternatively, you could set up a webdot server, or use the AT&T public webdot server. This is the default for the webdotbase param, but it's often overloaded and slow. Note that AT&T's server won't work if Bugzilla is only accessible using HARTS. Editor's note: What the heck is HARTS? Google doesn't know...

2.3.3. The Whining Cron

What good are bugs if they're not annoying? To help make them more so you can set up Bugzilla's automatic whining system to complain at engineers which leave their bugs in the NEW or REOPENED state without triaging them.

This can be done by adding the following command as a daily crontab entry, in the same manner as explained above for bug graphs. This example runs it at 12.55am.

55 0 * * * cd <your-bugzilla-directory> ; ./whineatnews.pl

Windows does not have 'cron', but it does have the Task Scheduler, which performs the same duties. There are also third-party tools that can be used to implement cron, such as nncron.

2.3.4. Whining

As of Bugzilla 2.20, users can configure Bugzilla to regularly annoy them at regular intervals, by having Bugzilla execute saved searches at certain times and emailing the results to the user. This is known as "Whining". The process of configuring Whining is described in Section 5.13, but for it to work a Perl script must be executed at regular intervals.

This can be done by adding the following command as a daily crontab entry, in the same manner as explained above for bug graphs. This example runs it every 15 minutes.

*/15 * * * * cd <your-bugzilla-directory> ; ./whine.pl

Whines can be executed as often as every 15 minutes, so if you specify longer intervals between executions of whine.pl, some users may not be whined at as often as they would expect. Depending on the person, this can either be a very Good Thing or a very Bad Thing.

Windows does not have 'cron', but it does have the Task Scheduler, which performs the same duties. There are also third-party tools that can be used to implement cron, such as nncron.

2.3.5. Serving Alternate Formats with the right MIME type

Some Bugzilla pages have alternate formats, other than just plain HTML. In particular, a few Bugzilla pages can output their contents as either XUL (a special Mozilla format, that looks like a program GUI) or RDF (a type of structured XML that can be read by various programs).

In order for your users to see these pages correctly, Apache must send them with the right MIME type. To do this, add the following lines to your Apache configuration, either in the <VirtualHost> section for your Bugzilla, or in the <Directory> section for your Bugzilla:

AddType application/vnd.mozilla.xul+xml .xul AddType application/rdf+xml .rdf