158 lines
5.3 KiB
ReStructuredText
158 lines
5.3 KiB
ReStructuredText
.. _optional-features:
|
|
|
|
Optional Features
|
|
#################
|
|
|
|
XXXHACKME
|
|
|
|
Bugzilla has a number of optional features. This section describes how
|
|
to configure or enable them.
|
|
|
|
Bug Graphs
|
|
==========
|
|
|
|
If you have installed the necessary Perl modules you
|
|
can start collecting statistics for the nifty Bugzilla
|
|
graphs.
|
|
|
|
::
|
|
|
|
# crontab -e
|
|
|
|
This should bring up the crontab file in your editor.
|
|
Add a cron entry like this to run
|
|
:file:`collectstats.pl`
|
|
daily at 5 after midnight:
|
|
|
|
.. code-block:: none
|
|
|
|
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.
|
|
|
|
.. note:: 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 <http://www.nncron.ru/>`_.
|
|
|
|
.. _installation-whining-cron:
|
|
|
|
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 CONFIRMED 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.
|
|
|
|
.. code-block:: none
|
|
|
|
55 0 * * * cd <your-bugzilla-directory> && ./whineatnews.pl
|
|
|
|
.. note:: 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 <http://www.nncron.ru/>`_.
|
|
|
|
.. _installation-whining:
|
|
|
|
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 :ref:`whining`, 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.
|
|
|
|
.. code-block:: none
|
|
|
|
*/15 * * * * cd <your-bugzilla-directory> && ./whine.pl
|
|
|
|
.. note:: 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.
|
|
|
|
.. note:: 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 <http://www.nncron.ru/>`_.
|
|
|
|
.. _apache-addtype:
|
|
|
|
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:
|
|
|
|
.. code-block:: apache
|
|
|
|
AddType application/vnd.mozilla.xul+xml .xul
|
|
AddType application/rdf+xml .rdf
|
|
|
|
.. _multiple-bz-dbs:
|
|
|
|
Multiple Bugzilla databases with a single installation
|
|
======================================================
|
|
|
|
The previous instructions referred to a standard installation, with
|
|
one unique Bugzilla database. However, you may want to host several
|
|
distinct installations, without having several copies of the code. This is
|
|
possible by using the PROJECT environment variable. When accessed,
|
|
Bugzilla checks for the existence of this variable, and if present, uses
|
|
its value to check for an alternative configuration file named
|
|
:file:`localconfig.<PROJECT>` in the same location as
|
|
the default one (:file:`localconfig`). It also checks for
|
|
customized templates in a directory named
|
|
:file:`<PROJECT>` in the same location as the
|
|
default one (:file:`template/<langcode>`). By default
|
|
this is :file:`template/en/default` so PROJECT's templates
|
|
would be located at :file:`template/en/PROJECT`.
|
|
|
|
To set up an alternate installation, just export PROJECT=foo before
|
|
running :command:`checksetup.pl` for the first time. It will
|
|
result in a file called :file:`localconfig.foo` instead of
|
|
:file:`localconfig`. Edit this file as described above, with
|
|
reference to a new database, and re-run :command:`checksetup.pl`
|
|
to populate it. That's all.
|
|
|
|
Now you have to configure the web server to pass this environment
|
|
variable when accessed via an alternate URL, such as virtual host for
|
|
instance. The following is an example of how you could do it in Apache,
|
|
other Webservers may differ.
|
|
|
|
.. code-block:: apache
|
|
|
|
<VirtualHost 212.85.153.228:80>
|
|
ServerName foo.bar.baz
|
|
SetEnv PROJECT foo
|
|
Alias /bugzilla /var/www/bugzilla
|
|
</VirtualHost>
|
|
|
|
Don't forget to also export this variable before accessing Bugzilla
|
|
by other means, such as cron tasks for instance.
|
|
|