18361 lines
414 KiB
HTML
18361 lines
414 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>The Bugzilla Guide - 3.6.1
|
|
Release</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><META
|
|
NAME="KEYWORD"
|
|
CONTENT="Bugzilla"><META
|
|
NAME="KEYWORD"
|
|
CONTENT="Guide"><META
|
|
NAME="KEYWORD"
|
|
CONTENT="installation"><META
|
|
NAME="KEYWORD"
|
|
CONTENT="FAQ"><META
|
|
NAME="KEYWORD"
|
|
CONTENT="administration"><META
|
|
NAME="KEYWORD"
|
|
CONTENT="integration"><META
|
|
NAME="KEYWORD"
|
|
CONTENT="MySQL"><META
|
|
NAME="KEYWORD"
|
|
CONTENT="Mozilla"><META
|
|
NAME="KEYWORD"
|
|
CONTENT="webtools"></HEAD
|
|
><BODY
|
|
CLASS="book"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="BOOK"
|
|
><A
|
|
NAME="index"
|
|
></A
|
|
><DIV
|
|
CLASS="TITLEPAGE"
|
|
><H1
|
|
CLASS="title"
|
|
><A
|
|
NAME="AEN2"
|
|
>The Bugzilla Guide - 3.6.1
|
|
Release</A
|
|
></H1
|
|
><H3
|
|
CLASS="corpauthor"
|
|
>The Bugzilla Team</H3
|
|
><P
|
|
CLASS="pubdate"
|
|
>2010-06-24<BR></P
|
|
><DIV
|
|
><DIV
|
|
CLASS="abstract"
|
|
><P
|
|
></P
|
|
><A
|
|
NAME="AEN7"
|
|
></A
|
|
><P
|
|
> This is the documentation for Bugzilla, a
|
|
bug-tracking system from mozilla.org.
|
|
Bugzilla is an enterprise-class piece of software
|
|
that tracks millions of bugs and issues for hundreds of
|
|
organizations around the world.
|
|
</P
|
|
><P
|
|
> The most current version of this document can always be found on the
|
|
<A
|
|
HREF="http://www.bugzilla.org/docs/"
|
|
TARGET="_top"
|
|
>Bugzilla
|
|
Documentation Page</A
|
|
>.
|
|
</P
|
|
><P
|
|
></P
|
|
></DIV
|
|
></DIV
|
|
><HR></DIV
|
|
><DIV
|
|
CLASS="TOC"
|
|
><DL
|
|
><DT
|
|
><B
|
|
>Table of Contents</B
|
|
></DT
|
|
><DT
|
|
>1. <A
|
|
HREF="#about"
|
|
>About This Guide</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>1.1. <A
|
|
HREF="#copyright"
|
|
>Copyright Information</A
|
|
></DT
|
|
><DT
|
|
>1.2. <A
|
|
HREF="#disclaimer"
|
|
>Disclaimer</A
|
|
></DT
|
|
><DT
|
|
>1.3. <A
|
|
HREF="#newversions"
|
|
>New Versions</A
|
|
></DT
|
|
><DT
|
|
>1.4. <A
|
|
HREF="#credits"
|
|
>Credits</A
|
|
></DT
|
|
><DT
|
|
>1.5. <A
|
|
HREF="#conventions"
|
|
>Document Conventions</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>2. <A
|
|
HREF="#installing-bugzilla"
|
|
>Installing Bugzilla</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>2.1. <A
|
|
HREF="#installation"
|
|
>Installation</A
|
|
></DT
|
|
><DT
|
|
>2.2. <A
|
|
HREF="#configuration"
|
|
>Configuration</A
|
|
></DT
|
|
><DT
|
|
>2.3. <A
|
|
HREF="#extraconfig"
|
|
>Optional Additional Configuration</A
|
|
></DT
|
|
><DT
|
|
>2.4. <A
|
|
HREF="#multiple-bz-dbs"
|
|
>Multiple Bugzilla databases with a single installation</A
|
|
></DT
|
|
><DT
|
|
>2.5. <A
|
|
HREF="#os-specific"
|
|
>OS-Specific Installation Notes</A
|
|
></DT
|
|
><DT
|
|
>2.6. <A
|
|
HREF="#nonroot"
|
|
>UNIX (non-root) Installation Notes</A
|
|
></DT
|
|
><DT
|
|
>2.7. <A
|
|
HREF="#upgrade"
|
|
>Upgrading to New Releases</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>3. <A
|
|
HREF="#administration"
|
|
>Administering Bugzilla</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>3.1. <A
|
|
HREF="#parameters"
|
|
>Bugzilla Configuration</A
|
|
></DT
|
|
><DT
|
|
>3.2. <A
|
|
HREF="#useradmin"
|
|
>User Administration</A
|
|
></DT
|
|
><DT
|
|
>3.3. <A
|
|
HREF="#classifications"
|
|
>Classifications</A
|
|
></DT
|
|
><DT
|
|
>3.4. <A
|
|
HREF="#products"
|
|
>Products</A
|
|
></DT
|
|
><DT
|
|
>3.5. <A
|
|
HREF="#components"
|
|
>Components</A
|
|
></DT
|
|
><DT
|
|
>3.6. <A
|
|
HREF="#versions"
|
|
>Versions</A
|
|
></DT
|
|
><DT
|
|
>3.7. <A
|
|
HREF="#milestones"
|
|
>Milestones</A
|
|
></DT
|
|
><DT
|
|
>3.8. <A
|
|
HREF="#flags-overview"
|
|
>Flags</A
|
|
></DT
|
|
><DT
|
|
>3.9. <A
|
|
HREF="#keywords"
|
|
>Keywords</A
|
|
></DT
|
|
><DT
|
|
>3.10. <A
|
|
HREF="#custom-fields"
|
|
>Custom Fields</A
|
|
></DT
|
|
><DT
|
|
>3.11. <A
|
|
HREF="#edit-values"
|
|
>Legal Values</A
|
|
></DT
|
|
><DT
|
|
>3.12. <A
|
|
HREF="#bug_status_workflow"
|
|
>Bug Status Workflow</A
|
|
></DT
|
|
><DT
|
|
>3.13. <A
|
|
HREF="#voting"
|
|
>Voting</A
|
|
></DT
|
|
><DT
|
|
>3.14. <A
|
|
HREF="#quips"
|
|
>Quips</A
|
|
></DT
|
|
><DT
|
|
>3.15. <A
|
|
HREF="#groups"
|
|
>Groups and Group Security</A
|
|
></DT
|
|
><DT
|
|
>3.16. <A
|
|
HREF="#sanitycheck"
|
|
>Checking and Maintaining Database Integrity</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>4. <A
|
|
HREF="#security"
|
|
>Bugzilla Security</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>4.1. <A
|
|
HREF="#security-os"
|
|
>Operating System</A
|
|
></DT
|
|
><DT
|
|
>4.2. <A
|
|
HREF="#security-webserver"
|
|
>Web server</A
|
|
></DT
|
|
><DT
|
|
>4.3. <A
|
|
HREF="#security-bugzilla"
|
|
>Bugzilla</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>5. <A
|
|
HREF="#using"
|
|
>Using Bugzilla</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>5.1. <A
|
|
HREF="#using-intro"
|
|
>Introduction</A
|
|
></DT
|
|
><DT
|
|
>5.2. <A
|
|
HREF="#myaccount"
|
|
>Create a Bugzilla Account</A
|
|
></DT
|
|
><DT
|
|
>5.3. <A
|
|
HREF="#bug_page"
|
|
>Anatomy of a Bug</A
|
|
></DT
|
|
><DT
|
|
>5.4. <A
|
|
HREF="#lifecycle"
|
|
>Life Cycle of a Bug</A
|
|
></DT
|
|
><DT
|
|
>5.5. <A
|
|
HREF="#query"
|
|
>Searching for Bugs</A
|
|
></DT
|
|
><DT
|
|
>5.6. <A
|
|
HREF="#bugreports"
|
|
>Filing Bugs</A
|
|
></DT
|
|
><DT
|
|
>5.7. <A
|
|
HREF="#attachments"
|
|
>Attachments</A
|
|
></DT
|
|
><DT
|
|
>5.8. <A
|
|
HREF="#hintsandtips"
|
|
>Hints and Tips</A
|
|
></DT
|
|
><DT
|
|
>5.9. <A
|
|
HREF="#timetracking"
|
|
>Time Tracking Information</A
|
|
></DT
|
|
><DT
|
|
>5.10. <A
|
|
HREF="#userpreferences"
|
|
>User Preferences</A
|
|
></DT
|
|
><DT
|
|
>5.11. <A
|
|
HREF="#reporting"
|
|
>Reports and Charts</A
|
|
></DT
|
|
><DT
|
|
>5.12. <A
|
|
HREF="#flags"
|
|
>Flags</A
|
|
></DT
|
|
><DT
|
|
>5.13. <A
|
|
HREF="#whining"
|
|
>Whining</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>6. <A
|
|
HREF="#customization"
|
|
>Customizing Bugzilla</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>6.1. <A
|
|
HREF="#extensions"
|
|
>Bugzilla Extensions</A
|
|
></DT
|
|
><DT
|
|
>6.2. <A
|
|
HREF="#cust-skins"
|
|
>Custom Skins</A
|
|
></DT
|
|
><DT
|
|
>6.3. <A
|
|
HREF="#cust-templates"
|
|
>Template Customization</A
|
|
></DT
|
|
><DT
|
|
>6.4. <A
|
|
HREF="#cust-change-permissions"
|
|
>Customizing Who Can Change What</A
|
|
></DT
|
|
><DT
|
|
>6.5. <A
|
|
HREF="#integration"
|
|
>Integrating Bugzilla with Third-Party Tools</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>A. <A
|
|
HREF="#troubleshooting"
|
|
>Troubleshooting</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>A.1. <A
|
|
HREF="#general-advice"
|
|
>General Advice</A
|
|
></DT
|
|
><DT
|
|
>A.2. <A
|
|
HREF="#trbl-testserver"
|
|
>The Apache web server is not serving Bugzilla pages</A
|
|
></DT
|
|
><DT
|
|
>A.3. <A
|
|
HREF="#trbl-perlmodule"
|
|
>I installed a Perl module, but
|
|
<TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> claims it's not installed!</A
|
|
></DT
|
|
><DT
|
|
>A.4. <A
|
|
HREF="#trbl-dbdSponge"
|
|
>DBD::Sponge::db prepare failed</A
|
|
></DT
|
|
><DT
|
|
>A.5. <A
|
|
HREF="#paranoid-security"
|
|
>cannot chdir(/var/spool/mqueue)</A
|
|
></DT
|
|
><DT
|
|
>A.6. <A
|
|
HREF="#trbl-relogin-everyone"
|
|
>Everybody is constantly being forced to relogin</A
|
|
></DT
|
|
><DT
|
|
>A.7. <A
|
|
HREF="#trbl-index"
|
|
><TT
|
|
CLASS="filename"
|
|
>index.cgi</TT
|
|
> doesn't show up unless specified in the URL</A
|
|
></DT
|
|
><DT
|
|
>A.8. <A
|
|
HREF="#trbl-passwd-encryption"
|
|
>checksetup.pl reports "Client does not support authentication protocol
|
|
requested by server..."</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>B. <A
|
|
HREF="#patches"
|
|
>Contrib</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>B.1. <A
|
|
HREF="#cmdline"
|
|
>Command-line Search Interface</A
|
|
></DT
|
|
><DT
|
|
>B.2. <A
|
|
HREF="#cmdline-bugmail"
|
|
>Command-line 'Send Unsent Bug-mail' tool</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>C. <A
|
|
HREF="#install-perlmodules-manual"
|
|
>Manual Installation of Perl Modules</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>C.1. <A
|
|
HREF="#modules-manual-instructions"
|
|
>Instructions</A
|
|
></DT
|
|
><DT
|
|
>C.2. <A
|
|
HREF="#modules-manual-download"
|
|
>Download Locations</A
|
|
></DT
|
|
><DT
|
|
>C.3. <A
|
|
HREF="#modules-manual-optional"
|
|
>Optional Modules</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
>D. <A
|
|
HREF="#gfdl"
|
|
>GNU Free Documentation License</A
|
|
></DT
|
|
><DD
|
|
><DL
|
|
><DT
|
|
>0. <A
|
|
HREF="#gfdl-0"
|
|
>Preamble</A
|
|
></DT
|
|
><DT
|
|
>1. <A
|
|
HREF="#gfdl-1"
|
|
>Applicability and Definition</A
|
|
></DT
|
|
><DT
|
|
>2. <A
|
|
HREF="#gfdl-2"
|
|
>Verbatim Copying</A
|
|
></DT
|
|
><DT
|
|
>3. <A
|
|
HREF="#gfdl-3"
|
|
>Copying in Quantity</A
|
|
></DT
|
|
><DT
|
|
>4. <A
|
|
HREF="#gfdl-4"
|
|
>Modifications</A
|
|
></DT
|
|
><DT
|
|
>5. <A
|
|
HREF="#gfdl-5"
|
|
>Combining Documents</A
|
|
></DT
|
|
><DT
|
|
>6. <A
|
|
HREF="#gfdl-6"
|
|
>Collections of Documents</A
|
|
></DT
|
|
><DT
|
|
>7. <A
|
|
HREF="#gfdl-7"
|
|
>Aggregation with Independent Works</A
|
|
></DT
|
|
><DT
|
|
>8. <A
|
|
HREF="#gfdl-8"
|
|
>Translation</A
|
|
></DT
|
|
><DT
|
|
>9. <A
|
|
HREF="#gfdl-9"
|
|
>Termination</A
|
|
></DT
|
|
><DT
|
|
>10. <A
|
|
HREF="#gfdl-10"
|
|
>Future Revisions of this License</A
|
|
></DT
|
|
><DT
|
|
><A
|
|
HREF="#gfdl-howto"
|
|
>How to use this License for your documents</A
|
|
></DT
|
|
></DL
|
|
></DD
|
|
><DT
|
|
><A
|
|
HREF="#glossary"
|
|
>Glossary</A
|
|
></DT
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="LOT"
|
|
><DL
|
|
CLASS="LOT"
|
|
><DT
|
|
><B
|
|
>List of Figures</B
|
|
></DT
|
|
><DT
|
|
>5-1. <A
|
|
HREF="#lifecycle-image"
|
|
>Lifecycle of a Bugzilla Bug</A
|
|
></DT
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="LOT"
|
|
><DL
|
|
CLASS="LOT"
|
|
><DT
|
|
><B
|
|
>List of Examples</B
|
|
></DT
|
|
><DT
|
|
>A-1. <A
|
|
HREF="#trbl-relogin-everyone-share"
|
|
>Examples of urlbase/cookiepath pairs for sharing login cookies</A
|
|
></DT
|
|
><DT
|
|
>A-2. <A
|
|
HREF="#trbl-relogin-everyone-restrict"
|
|
>Examples of urlbase/cookiepath pairs to restrict the login cookie</A
|
|
></DT
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="chapter"
|
|
><HR><H1
|
|
><A
|
|
NAME="about"
|
|
></A
|
|
>Chapter 1. About This Guide</H1
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="copyright"
|
|
>1.1. Copyright Information</A
|
|
></H2
|
|
><P
|
|
>This document is copyright (c) 2000-2010 by the various
|
|
Bugzilla contributors who wrote it.</P
|
|
><A
|
|
NAME="AEN26"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> Permission is granted to copy, distribute and/or modify this
|
|
document under the terms of the GNU Free Documentation
|
|
License, Version 1.1 or any later version published by the
|
|
Free Software Foundation; with no Invariant Sections, no
|
|
Front-Cover Texts, and with no Back-Cover Texts. A copy of
|
|
the license is included in <A
|
|
HREF="#gfdl"
|
|
>Appendix D</A
|
|
>.
|
|
</P
|
|
></BLOCKQUOTE
|
|
><P
|
|
> If you have any questions regarding this document, its
|
|
copyright, or publishing this document in non-electronic form,
|
|
please contact the Bugzilla Team.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="disclaimer"
|
|
>1.2. Disclaimer</A
|
|
></H2
|
|
><P
|
|
> No liability for the contents of this document can be accepted.
|
|
Follow the instructions herein at your own risk.
|
|
This document may contain errors
|
|
and inaccuracies that may damage your system, cause your partner
|
|
to leave you, your boss to fire you, your cats to
|
|
pee on your furniture and clothing, and global thermonuclear
|
|
war. Proceed with caution.
|
|
</P
|
|
><P
|
|
> Naming of particular products or brands should not be seen as
|
|
endorsements, with the exception of the term "GNU/Linux". We
|
|
wholeheartedly endorse the use of GNU/Linux; it is an extremely
|
|
versatile, stable,
|
|
and robust operating system that offers an ideal operating
|
|
environment for Bugzilla.
|
|
</P
|
|
><P
|
|
> Although the Bugzilla development team has taken great care to
|
|
ensure that all exploitable bugs have been fixed, security holes surely
|
|
exist in any piece of code. Great care should be taken both in
|
|
the installation and usage of this software. The Bugzilla development
|
|
team members assume no liability for your use of Bugzilla. You have
|
|
the source code, and are responsible for auditing it yourself to ensure
|
|
your security needs are met.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="newversions"
|
|
>1.3. New Versions</A
|
|
></H2
|
|
><P
|
|
> This is the 3.6.1 version of The Bugzilla Guide. It is so named
|
|
to match the current version of Bugzilla.
|
|
</P
|
|
><P
|
|
> The latest version of this guide can always be found at <A
|
|
HREF="http://www.bugzilla.org/docs/"
|
|
TARGET="_top"
|
|
>http://www.bugzilla.org/docs/</A
|
|
>. However, you should read
|
|
the version which came with the Bugzilla release you are using.
|
|
</P
|
|
><P
|
|
>
|
|
In addition, there are Bugzilla template localization projects in
|
|
<A
|
|
HREF="http://www.bugzilla.org/download/#localizations"
|
|
TARGET="_top"
|
|
>several languages</A
|
|
>.
|
|
They may have translated documentation available. If you would like to
|
|
volunteer to translate the Guide into additional languages, please visit the
|
|
<A
|
|
HREF="https://wiki.mozilla.org/Bugzilla:L10n"
|
|
TARGET="_top"
|
|
>Bugzilla L10n team</A
|
|
>
|
|
page.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="credits"
|
|
>1.4. Credits</A
|
|
></H2
|
|
><P
|
|
> The people listed below have made enormous contributions to the
|
|
creation of this Guide, through their writing, dedicated hacking efforts,
|
|
numerous e-mail and IRC support sessions, and overall excellent
|
|
contribution to the Bugzilla community:
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
>Matthew P. Barnson <CODE
|
|
CLASS="email"
|
|
><<A
|
|
HREF="mailto:mbarnson@sisna.com"
|
|
>mbarnson@sisna.com</A
|
|
>></CODE
|
|
></DT
|
|
><DD
|
|
><P
|
|
>for the Herculean task of pulling together the Bugzilla Guide
|
|
and shepherding it to 2.14.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Terry Weissman <CODE
|
|
CLASS="email"
|
|
><<A
|
|
HREF="mailto:terry@mozilla.org"
|
|
>terry@mozilla.org</A
|
|
>></CODE
|
|
></DT
|
|
><DD
|
|
><P
|
|
>for initially writing Bugzilla and creating the README upon
|
|
which the UNIX installation documentation is largely based.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Tara Hernandez <CODE
|
|
CLASS="email"
|
|
><<A
|
|
HREF="mailto:tara@tequilarists.org"
|
|
>tara@tequilarists.org</A
|
|
>></CODE
|
|
></DT
|
|
><DD
|
|
><P
|
|
>for keeping Bugzilla development going strong after Terry left
|
|
mozilla.org and for running landfill.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Dave Lawrence <CODE
|
|
CLASS="email"
|
|
><<A
|
|
HREF="mailto:dkl@redhat.com"
|
|
>dkl@redhat.com</A
|
|
>></CODE
|
|
></DT
|
|
><DD
|
|
><P
|
|
>for providing insight into the key differences between Red
|
|
Hat's customized Bugzilla.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Dawn Endico <CODE
|
|
CLASS="email"
|
|
><<A
|
|
HREF="mailto:endico@mozilla.org"
|
|
>endico@mozilla.org</A
|
|
>></CODE
|
|
></DT
|
|
><DD
|
|
><P
|
|
>for being a hacker extraordinaire and putting up with Matthew's
|
|
incessant questions and arguments on irc.mozilla.org in #mozwebtools
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Jacob Steenhagen <CODE
|
|
CLASS="email"
|
|
><<A
|
|
HREF="mailto:jake@bugzilla.org"
|
|
>jake@bugzilla.org</A
|
|
>></CODE
|
|
></DT
|
|
><DD
|
|
><P
|
|
>for taking over documentation during the 2.17 development
|
|
period.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Dave Miller <CODE
|
|
CLASS="email"
|
|
><<A
|
|
HREF="mailto:justdave@bugzilla.org"
|
|
>justdave@bugzilla.org</A
|
|
>></CODE
|
|
></DT
|
|
><DD
|
|
><P
|
|
>for taking over as project lead when Tara stepped down and
|
|
continually pushing for the documentation to be the best it can be.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><P
|
|
> Thanks also go to the following people for significant contributions
|
|
to this documentation:
|
|
Kevin Brannen, Vlad Dascalu, Ben FrantzDale, Eric Hanson, Zach Lipton, Gervase Markham, Andrew Pearson, Joe Robins, Spencer Smith, Ron Teitelbaum, Shane Travis, Martin Wulffeld.
|
|
</P
|
|
><P
|
|
> Also, thanks are due to the members of the
|
|
<A
|
|
HREF="news://news.mozilla.org/mozilla.support.bugzilla"
|
|
TARGET="_top"
|
|
> mozilla.support.bugzilla</A
|
|
>
|
|
newsgroup (and its predecessor, netscape.public.mozilla.webtools).
|
|
Without your discussions, insight, suggestions, and patches,
|
|
this could never have happened.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="conventions"
|
|
>1.5. Document Conventions</A
|
|
></H2
|
|
><P
|
|
>This document uses the following conventions:</P
|
|
><DIV
|
|
CLASS="informaltable"
|
|
><P
|
|
></P
|
|
><A
|
|
NAME="AEN103"
|
|
></A
|
|
><TABLE
|
|
BORDER="0"
|
|
FRAME="void"
|
|
CLASS="CALSTABLE"
|
|
><COL><COL><THEAD
|
|
><TR
|
|
><TH
|
|
>Descriptions</TH
|
|
><TH
|
|
>Appearance</TH
|
|
></TR
|
|
></THEAD
|
|
><TBODY
|
|
><TR
|
|
><TD
|
|
>Caution</TD
|
|
><TD
|
|
> <DIV
|
|
CLASS="caution"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="caution"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/caution.gif"
|
|
HSPACE="5"
|
|
ALT="Caution"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Don't run with scissors!</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
>
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Hint or Tip</TD
|
|
><TD
|
|
> <DIV
|
|
CLASS="tip"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="tip"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>For best results... </P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
>
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Note</TD
|
|
><TD
|
|
> <DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Dear John...</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
>
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Warning</TD
|
|
><TD
|
|
> <DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Read this or the cat gets it.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
>
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>File or directory name</TD
|
|
><TD
|
|
> <TT
|
|
CLASS="filename"
|
|
>filename</TT
|
|
>
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Command to be typed</TD
|
|
><TD
|
|
> <B
|
|
CLASS="command"
|
|
>command</B
|
|
>
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Application name</TD
|
|
><TD
|
|
> <SPAN
|
|
CLASS="application"
|
|
>application</SPAN
|
|
>
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> Normal user's prompt under bash shell</TD
|
|
><TD
|
|
>bash$</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> Root user's prompt under bash shell</TD
|
|
><TD
|
|
>bash#</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> Normal user's prompt under tcsh shell</TD
|
|
><TD
|
|
>tcsh$</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Environment variables</TD
|
|
><TD
|
|
> <CODE
|
|
CLASS="envar"
|
|
>VARIABLE</CODE
|
|
>
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Term found in the glossary</TD
|
|
><TD
|
|
> <A
|
|
HREF="#gloss-bugzilla"
|
|
><I
|
|
CLASS="glossterm"
|
|
>Bugzilla</I
|
|
></A
|
|
>
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Code example</TD
|
|
><TD
|
|
> <TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
><CODE
|
|
CLASS="sgmltag"
|
|
><para></CODE
|
|
>
|
|
Beginning and end of paragraph
|
|
<CODE
|
|
CLASS="sgmltag"
|
|
></para></CODE
|
|
></PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
</TD
|
|
></TR
|
|
></TBODY
|
|
></TABLE
|
|
><P
|
|
></P
|
|
></DIV
|
|
><P
|
|
>
|
|
This documentation is maintained in DocBook 4.1.2 XML format.
|
|
Changes are best submitted as plain text or XML diffs, attached
|
|
to a bug filed in the <A
|
|
HREF="https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&component=Documentation"
|
|
TARGET="_top"
|
|
>Bugzilla Documentation</A
|
|
> component.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="chapter"
|
|
><HR><H1
|
|
><A
|
|
NAME="installing-bugzilla"
|
|
></A
|
|
>Chapter 2. Installing Bugzilla</H1
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="installation"
|
|
>2.1. Installation</A
|
|
></H2
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>If you just want to <EM
|
|
>use</EM
|
|
> Bugzilla,
|
|
you do not need to install it. None of this chapter is relevant to
|
|
you. Ask your Bugzilla administrator for the URL to access it from
|
|
your web browser.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
>The Bugzilla server software is usually installed on Linux or
|
|
Solaris.
|
|
If you are installing on another OS, check <A
|
|
HREF="#os-specific"
|
|
>Section 2.5</A
|
|
>
|
|
before you start your installation to see if there are any special
|
|
instructions.
|
|
</P
|
|
><P
|
|
>This guide assumes that you have administrative access to the
|
|
Bugzilla machine. It not possible to
|
|
install and run Bugzilla itself without administrative access except
|
|
in the very unlikely event that every single prerequisite is
|
|
already installed.
|
|
</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>The installation process may make your machine insecure for
|
|
short periods of time. Make sure there is a firewall between you
|
|
and the Internet.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> You are strongly recommended to make a backup of your system
|
|
before installing Bugzilla (and at regular intervals thereafter :-).
|
|
</P
|
|
><P
|
|
>In outline, the installation proceeds as follows:
|
|
</P
|
|
><DIV
|
|
CLASS="procedure"
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
><A
|
|
HREF="#install-perl"
|
|
>Install Perl</A
|
|
>
|
|
(5.8.1 or above)
|
|
</P
|
|
></LI
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
><A
|
|
HREF="#install-database"
|
|
>Install a Database Engine</A
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
><A
|
|
HREF="#install-webserver"
|
|
>Install a Webserver</A
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
><A
|
|
HREF="#install-bzfiles"
|
|
>Install Bugzilla</A
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
><A
|
|
HREF="#install-perlmodules"
|
|
>Install Perl modules</A
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
> <A
|
|
HREF="#install-MTA"
|
|
>Install a Mail Transfer Agent</A
|
|
>
|
|
(Sendmail 8.7 or above, or an MTA that is Sendmail-compatible with at least this version)
|
|
</P
|
|
></LI
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
>Configure all of the above.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-perl"
|
|
>2.1.1. Perl</A
|
|
></H3
|
|
><P
|
|
>Installed Version Test: <TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>perl -v</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Any machine that doesn't have Perl on it is a sad machine indeed.
|
|
If you don't have it and your OS doesn't provide official packages,
|
|
visit <A
|
|
HREF="http://www.perl.org"
|
|
TARGET="_top"
|
|
>http://www.perl.org</A
|
|
>.
|
|
Although Bugzilla runs with Perl 5.8.1,
|
|
it's a good idea to be using the latest stable version.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-database"
|
|
>2.1.2. Database Engine</A
|
|
></H3
|
|
><P
|
|
> Bugzilla supports MySQL, PostgreSQL and Oracle as database servers.
|
|
You only require one of these systems to make use of Bugzilla.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-mysql"
|
|
>2.1.2.1. MySQL</A
|
|
></H4
|
|
><P
|
|
>Installed Version Test: <TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>mysql -V</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
> If you don't have it and your OS doesn't provide official packages,
|
|
visit <A
|
|
HREF="http://www.mysql.com"
|
|
TARGET="_top"
|
|
>http://www.mysql.com</A
|
|
>. You need MySQL version
|
|
4.1.2 or higher.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Many of the binary
|
|
versions of MySQL store their data files in
|
|
<TT
|
|
CLASS="filename"
|
|
>/var</TT
|
|
>.
|
|
On some Unix systems, this is part of a smaller root partition,
|
|
and may not have room for your bug database. To change the data
|
|
directory, you have to build MySQL from source yourself, and
|
|
set it as an option to <TT
|
|
CLASS="filename"
|
|
>configure</TT
|
|
>.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
>If you install from something other than a packaging/installation
|
|
system, such as .rpm (Redhat Package), .deb (Debian Package), .exe
|
|
(Windows Executable), or .msi (Microsoft Installer), make sure the MySQL
|
|
server is started when the machine boots.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-pg"
|
|
>2.1.2.2. PostgreSQL</A
|
|
></H4
|
|
><P
|
|
>Installed Version Test: <TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>psql -V</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
> If you don't have it and your OS doesn't provide official packages,
|
|
visit <A
|
|
HREF="http://www.postgresql.org/"
|
|
TARGET="_top"
|
|
>http://www.postgresql.org/</A
|
|
>. You need PostgreSQL
|
|
version 8.00.0000 or higher.
|
|
</P
|
|
><P
|
|
>If you install from something other than a packaging/installation
|
|
system, such as .rpm (Redhat Package), .deb (Debian Package), .exe
|
|
(Windows Executable), or .msi (Microsoft Installer), make sure the
|
|
PostgreSQL server is started when the machine boots.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-oracle"
|
|
>2.1.2.3. Oracle</A
|
|
></H4
|
|
><P
|
|
> Installed Version Test: <TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>select * from v$version</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
(you first have to log in into your DB)
|
|
</P
|
|
><P
|
|
> If you don't have it and your OS doesn't provide official packages,
|
|
visit <A
|
|
HREF="http://www.oracle.com/"
|
|
TARGET="_top"
|
|
>http://www.oracle.com/</A
|
|
>. You need Oracle
|
|
version 10.02.0 or higher.
|
|
</P
|
|
><P
|
|
> If you install from something other than a packaging/installation
|
|
system, such as .rpm (Redhat Package), .deb (Debian Package), .exe
|
|
(Windows Executable), or .msi (Microsoft Installer), make sure the
|
|
Oracle server is started when the machine boots.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-webserver"
|
|
>2.1.3. Web Server</A
|
|
></H3
|
|
><P
|
|
>Installed Version Test: view the default welcome page at
|
|
http://<your-machine>/</P
|
|
><P
|
|
>You have freedom of choice here, pretty much any web server that
|
|
is capable of running <A
|
|
HREF="#gloss-cgi"
|
|
><I
|
|
CLASS="glossterm"
|
|
>CGI</I
|
|
></A
|
|
>
|
|
scripts will work.
|
|
However, we strongly recommend using the Apache web server
|
|
(either 1.3.x or 2.x), and
|
|
the installation instructions usually assume you are
|
|
using it. If you have got Bugzilla working using another web server,
|
|
please share your experiences with us by filing a bug in <A
|
|
HREF="https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&component=Documentation"
|
|
TARGET="_top"
|
|
>Bugzilla Documentation</A
|
|
>.
|
|
</P
|
|
><P
|
|
> If you don't have Apache and your OS doesn't provide official packages,
|
|
visit <A
|
|
HREF="http://httpd.apache.org/"
|
|
TARGET="_top"
|
|
>http://httpd.apache.org/</A
|
|
>.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-bzfiles"
|
|
>2.1.4. Bugzilla</A
|
|
></H3
|
|
><P
|
|
> <A
|
|
HREF="http://www.bugzilla.org/download/"
|
|
TARGET="_top"
|
|
>Download a Bugzilla tarball</A
|
|
>
|
|
(or check it out from CVS) and place
|
|
it in a suitable directory, accessible by the default web server user
|
|
(probably <SPAN
|
|
CLASS="QUOTE"
|
|
>"apache"</SPAN
|
|
> or <SPAN
|
|
CLASS="QUOTE"
|
|
>"www"</SPAN
|
|
>).
|
|
Good locations are either directly in the web server's document directories or
|
|
in <TT
|
|
CLASS="filename"
|
|
>/usr/local</TT
|
|
> with a symbolic link to the web server's
|
|
document directories or an alias in the web server's configuration.
|
|
</P
|
|
><DIV
|
|
CLASS="caution"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="caution"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/caution.gif"
|
|
HSPACE="5"
|
|
ALT="Caution"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>The default Bugzilla distribution is NOT designed to be placed
|
|
in a <TT
|
|
CLASS="filename"
|
|
>cgi-bin</TT
|
|
> directory. This
|
|
includes any directory which is configured using the
|
|
<CODE
|
|
CLASS="option"
|
|
>ScriptAlias</CODE
|
|
> directive of Apache.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
>Once all the files are in a web accessible directory, make that
|
|
directory writable by your web server's user. This is a temporary step
|
|
until you run the
|
|
<TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
>
|
|
script, which locks down your installation.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-perlmodules"
|
|
>2.1.5. Perl Modules</A
|
|
></H3
|
|
><P
|
|
>Bugzilla's installation process is based
|
|
on a script called <TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
>.
|
|
The first thing it checks is whether you have appropriate
|
|
versions of all the required
|
|
Perl modules. The aim of this section is to pass this check.
|
|
When it passes, proceed to <A
|
|
HREF="#configuration"
|
|
>Section 2.2</A
|
|
>.
|
|
</P
|
|
><P
|
|
> At this point, you need to <TT
|
|
CLASS="filename"
|
|
>su</TT
|
|
> to root. You should
|
|
remain as root until the end of the install. To check you have the
|
|
required modules, run:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
><SAMP
|
|
CLASS="prompt"
|
|
>bash#</SAMP
|
|
> ./checksetup.pl --check-modules</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> <TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> will print out a list of the
|
|
required and optional Perl modules, together with the versions
|
|
(if any) installed on your machine.
|
|
The list of required modules is reasonably long; however, you
|
|
may already have several of them installed.
|
|
</P
|
|
><P
|
|
> The preferred way of installing Perl modules is to use the
|
|
<TT
|
|
CLASS="filename"
|
|
>install-module.pl</TT
|
|
> script on Unix,
|
|
or PPM on Windows (see <A
|
|
HREF="#win32-perl-modules"
|
|
>Section 2.5.1.2</A
|
|
>). If for
|
|
some reason you need to install the Perl modules manually, see
|
|
<A
|
|
HREF="#install-perlmodules-manual"
|
|
>Appendix C</A
|
|
>. For instance, on Unix:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
><SAMP
|
|
CLASS="prompt"
|
|
>bash#</SAMP
|
|
> perl install-module.pl <modulename></PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="tip"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="tip"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Many people complain that Perl modules will not install for
|
|
them. Most times, the error messages complain that they are missing a
|
|
file in
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"@INC"</SPAN
|
|
>.
|
|
Virtually every time, this error is due to permissions being set too
|
|
restrictively for you to compile Perl modules or not having the
|
|
necessary Perl development libraries installed on your system.
|
|
Consult your local UNIX systems administrator for help solving these
|
|
permissions issues; if you
|
|
<EM
|
|
>are</EM
|
|
>
|
|
the local UNIX sysadmin, please consult the newsgroup/mailing list
|
|
for further assistance or hire someone to help you out.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>If you are using a package-based system, and attempting to install the
|
|
Perl modules from CPAN, you may need to install the "development" packages for
|
|
MySQL and GD before attempting to install the related Perl modules. The names of
|
|
these packages will vary depending on the specific distribution you are using,
|
|
but are often called <TT
|
|
CLASS="filename"
|
|
><packagename>-devel</TT
|
|
>.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> Here is a complete list of modules and their minimum versions.
|
|
Some modules have special installation notes, which follow.
|
|
</P
|
|
><P
|
|
>Required Perl modules:
|
|
<P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> CGI (3.21)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Date::Format (2.21)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> DateTime (0.28)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> DateTime::TimeZone (0.71)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> DBI (1.41)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <A
|
|
HREF="#install-modules-dbd-mysql"
|
|
>DBD::mysql</A
|
|
>
|
|
(4.00) if using MySQL
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> DBD::Pg (1.45) if using PostgreSQL
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> DBD::Oracle (1.19) if using Oracle
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Digest::SHA (any)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Email::Send (2.00)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Email::MIME (1.861)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Email::MIME::Encodings (1.313)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Email::MIME::Modifier (1.442)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <A
|
|
HREF="#install-modules-template"
|
|
>Template</A
|
|
>
|
|
(2.22)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> URI (any)
|
|
</P
|
|
></LI
|
|
></OL
|
|
>
|
|
|
|
Optional Perl modules:
|
|
<P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> <A
|
|
HREF="#install-modules-gd"
|
|
>GD</A
|
|
>
|
|
(1.20) for bug charting
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Template::Plugin::GD::Image
|
|
(any) for Graphical Reports
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <A
|
|
HREF="#install-modules-chart-lines"
|
|
>Chart::Lines</A
|
|
>
|
|
(2.1) for bug charting
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <A
|
|
HREF="#install-modules-gd-graph"
|
|
>GD::Graph</A
|
|
>
|
|
(any) for bug charting
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <A
|
|
HREF="#install-modules-gd-text"
|
|
>GD::Text</A
|
|
>
|
|
(any) for bug charting
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <A
|
|
HREF="#install-modules-xml-twig"
|
|
>XML::Twig</A
|
|
>
|
|
(any) for bug import/export
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> MIME::Parser (5.406) for bug import/export
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> LWP::UserAgent
|
|
(any) for Automatic Update Notifications
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <A
|
|
HREF="#install-modules-patchreader"
|
|
>PatchReader</A
|
|
>
|
|
(0.9.4) for pretty HTML view of patches
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Net::LDAP
|
|
(any) for LDAP Authentication
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Authen::SASL
|
|
(any) for SASL Authentication
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Authen::Radius
|
|
(any) for RADIUS Authentication
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <A
|
|
HREF="#install-modules-soap-lite"
|
|
>SOAP::Lite</A
|
|
>
|
|
(0.710.06) for the web service interface
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> JSON::RPC
|
|
(any) for the JSON-RPC interface
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Test::Taint
|
|
(any) for the web service interface
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> HTML::Parser
|
|
(3.40) for More HTML in Product/Group Descriptions
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> HTML::Scrubber
|
|
(any) for More HTML in Product/Group Descriptions
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Email::MIME::Attachment::Stripper
|
|
(any) for Inbound Email
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Email::Reply
|
|
(any) for Inbound Email
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> TheSchwartz
|
|
(any) for Mail Queueing
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Daemon::Generic
|
|
(any) for Mail Queueing
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> mod_perl2
|
|
(1.999022) for mod_perl
|
|
</P
|
|
></LI
|
|
></OL
|
|
>
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-modules-dbd-mysql"
|
|
>2.1.5.1. DBD::mysql</A
|
|
></H4
|
|
><P
|
|
>The installation process will ask you a few questions about the
|
|
desired compilation target and your MySQL installation. For most of the
|
|
questions the provided default will be adequate, but when asked if your
|
|
desired target is the MySQL or mSQL packages, you should
|
|
select the MySQL-related ones. Later you will be asked if you wish to
|
|
provide backwards compatibility with the older MySQL packages; you
|
|
should answer YES to this question. The default is NO.</P
|
|
><P
|
|
>A host of 'localhost' should be fine. A testing user of 'test',
|
|
with a null password, should have sufficient access to run
|
|
tests on the 'test' database which MySQL creates upon installation.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-modules-template"
|
|
>2.1.5.2. Template Toolkit (2.22)</A
|
|
></H4
|
|
><P
|
|
>When you install Template Toolkit, you'll get asked various
|
|
questions about features to enable. The defaults are fine, except
|
|
that it is recommended you use the high speed XS Stash of the Template
|
|
Toolkit, in order to achieve best performance.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-modules-gd"
|
|
>2.1.5.3. GD (1.20)</A
|
|
></H4
|
|
><P
|
|
>The GD module is only required if you want graphical reports.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>The Perl GD module requires some other libraries that may or
|
|
may not be installed on your system, including
|
|
<CODE
|
|
CLASS="classname"
|
|
>libpng</CODE
|
|
>
|
|
and
|
|
<CODE
|
|
CLASS="classname"
|
|
>libgd</CODE
|
|
>.
|
|
The full requirements are listed in the Perl GD module README.
|
|
If compiling GD fails, it's probably because you're
|
|
missing a required library.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="tip"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="tip"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>The version of the GD module you need is very closely tied
|
|
to the <CODE
|
|
CLASS="classname"
|
|
>libgd</CODE
|
|
> version installed on your system.
|
|
If you have a version 1.x of <CODE
|
|
CLASS="classname"
|
|
>libgd</CODE
|
|
> the 2.x
|
|
versions of the GD module won't work for you.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-modules-chart-lines"
|
|
>2.1.5.4. Chart::Lines (2.1)</A
|
|
></H4
|
|
><P
|
|
>The Chart::Lines module is only required if you want graphical
|
|
reports.
|
|
Note that earlier versions that 0.99c used GIFs, which are no longer
|
|
supported by the latest versions of GD.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-modules-gd-graph"
|
|
>2.1.5.5. GD::Graph (any)</A
|
|
></H4
|
|
><P
|
|
>The GD::Graph module is only required if you want graphical
|
|
reports.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-modules-gd-text"
|
|
>2.1.5.6. GD::Text (any)</A
|
|
></H4
|
|
><P
|
|
>The GD::Text module is only required if you want graphical
|
|
reports.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-modules-xml-twig"
|
|
>2.1.5.7. XML::Twig (any)</A
|
|
></H4
|
|
><P
|
|
>The XML::Twig module is only required if you want to import
|
|
XML bugs using the <TT
|
|
CLASS="filename"
|
|
>importxml.pl</TT
|
|
>
|
|
script. This is required to use Bugzilla's "move bugs" feature;
|
|
you may also want to use it for migrating from another bug database.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-modules-soap-lite"
|
|
>2.1.5.8. SOAP::Lite (0.710.06)</A
|
|
></H4
|
|
><P
|
|
>Installing SOAP::Lite enables your Bugzilla installation to be
|
|
accessible at a standardized Web Service interface (SOAP/XML-RPC)
|
|
by third-party applications via HTTP(S).
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-modules-patchreader"
|
|
>2.1.5.9. PatchReader (0.9.4)</A
|
|
></H4
|
|
><P
|
|
>The PatchReader module is only required if you want to use
|
|
Patch Viewer, a
|
|
Bugzilla feature to show code patches in your web browser in a more
|
|
readable form.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-MTA"
|
|
>2.1.6. Mail Transfer Agent (MTA)</A
|
|
></H3
|
|
><P
|
|
> Bugzilla is dependent on the availability of an e-mail system for its
|
|
user authentication and for other tasks.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> This is not entirely true. It is possible to completely disable
|
|
email sending, or to have Bugzilla store email messages in a
|
|
file instead of sending them. However, this is mainly intended
|
|
for testing, as disabling or diverting email on a production
|
|
machine would mean that users could miss important events (such
|
|
as bug changes or the creation of new accounts).
|
|
</P
|
|
><P
|
|
> For more information, see the <SPAN
|
|
CLASS="QUOTE"
|
|
>"mail_delivery_method"</SPAN
|
|
> parameter
|
|
in <A
|
|
HREF="#parameters"
|
|
>Section 3.1</A
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> On Linux, any Sendmail-compatible MTA (Mail Transfer Agent) will
|
|
suffice. Sendmail, Postfix, qmail and Exim are examples of common
|
|
MTAs. Sendmail is the original Unix MTA, but the others are easier to
|
|
configure, and therefore many people replace Sendmail with Postfix or
|
|
Exim. They are drop-in replacements, so Bugzilla will not
|
|
distinguish between them.
|
|
</P
|
|
><P
|
|
> If you are using Sendmail, version 8.7 or higher is required.
|
|
If you are using a Sendmail-compatible MTA, it must be congruent with
|
|
at least version 8.7 of Sendmail.
|
|
</P
|
|
><P
|
|
> Consult the manual for the specific MTA you choose for detailed
|
|
installation instructions. Each of these programs will have their own
|
|
configuration files where you must configure certain parameters to
|
|
ensure that the mail is delivered properly. They are implemented
|
|
as services, and you should ensure that the MTA is in the auto-start
|
|
list of services for the machine.
|
|
</P
|
|
><P
|
|
> If a simple mail sent with the command-line 'mail' program
|
|
succeeds, then Bugzilla should also be fine.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="using-mod_perl-with-bugzilla"
|
|
>2.1.7. Installing Bugzilla on mod_perl</A
|
|
></H3
|
|
><P
|
|
>It is now possible to run the Bugzilla software under <TT
|
|
CLASS="literal"
|
|
>mod_perl</TT
|
|
> on
|
|
Apache. <TT
|
|
CLASS="literal"
|
|
>mod_perl</TT
|
|
> has some additional requirements to that of running
|
|
Bugzilla under <TT
|
|
CLASS="literal"
|
|
>mod_cgi</TT
|
|
> (the standard and previous way).</P
|
|
><P
|
|
>Bugzilla requires <TT
|
|
CLASS="literal"
|
|
>mod_perl</TT
|
|
> to be installed, which can be
|
|
obtained from <A
|
|
HREF="http://perl.apache.org"
|
|
TARGET="_top"
|
|
>http://perl.apache.org</A
|
|
> - Bugzilla requires
|
|
version 1.999022 (AKA 2.0.0-RC5) to be installed.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="configuration"
|
|
>2.2. Configuration</A
|
|
></H2
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Poorly-configured MySQL and Bugzilla installations have
|
|
given attackers full access to systems in the past. Please take the
|
|
security parts of these guidelines seriously, even for Bugzilla
|
|
machines hidden away behind your firewall. Be certain to read
|
|
<A
|
|
HREF="#security"
|
|
>Chapter 4</A
|
|
> for some important security tips.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="localconfig"
|
|
>2.2.1. localconfig</A
|
|
></H3
|
|
><P
|
|
> You should now run <TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> again, this time
|
|
without the <TT
|
|
CLASS="literal"
|
|
>--check-modules</TT
|
|
> switch.
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
><SAMP
|
|
CLASS="prompt"
|
|
>bash#</SAMP
|
|
> ./checksetup.pl</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> This time, <TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> should tell you that all
|
|
the correct modules are installed and will display a message about, and
|
|
write out a file called, <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
>. This file
|
|
contains the default settings for a number of Bugzilla parameters.
|
|
</P
|
|
><P
|
|
> Load this file in your editor. The only two values you
|
|
<EM
|
|
>need</EM
|
|
> to change are $db_driver and $db_pass,
|
|
respectively the type of the database and the password for
|
|
the user you will create for your database. Pick a strong
|
|
password (for simplicity, it should not contain single quote
|
|
characters) and put it here. $db_driver can be either 'mysql',
|
|
'Pg' or 'oracle'.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> In Oracle, <TT
|
|
CLASS="literal"
|
|
>$db_name</TT
|
|
> should actually be
|
|
the SID name of your database (e.g. "XE" if you are using Oracle XE).
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> You may need to change the value of
|
|
<EM
|
|
>webservergroup</EM
|
|
> if your web server does not
|
|
run in the "apache" group. On Debian, for example, Apache runs in
|
|
the "www-data" group. If you are going to run Bugzilla on a
|
|
machine where you do not have root access (such as on a shared web
|
|
hosting account), you will need to leave
|
|
<EM
|
|
>webservergroup</EM
|
|
> empty, ignoring the warnings
|
|
that <TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> will subsequently display
|
|
every time it is run.
|
|
</P
|
|
><DIV
|
|
CLASS="caution"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="caution"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/caution.gif"
|
|
HSPACE="5"
|
|
ALT="Caution"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If you are using suexec, you should use your own primary group
|
|
for <EM
|
|
>webservergroup</EM
|
|
> rather than leaving it
|
|
empty, and see the additional directions in the suexec section
|
|
<A
|
|
HREF="#suexec"
|
|
>Section 2.6.6.1</A
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> The other options in the <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
> file
|
|
are documented by their accompanying comments. If you have a slightly
|
|
non-standard database setup, you may wish to change one or more of
|
|
the other "$db_*" parameters.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="database-engine"
|
|
>2.2.2. Database Server</A
|
|
></H3
|
|
><P
|
|
> This section deals with configuring your database server for use
|
|
with Bugzilla. Currently, MySQL (<A
|
|
HREF="#mysql"
|
|
>Section 2.2.2.2</A
|
|
>),
|
|
PostgreSQL (<A
|
|
HREF="#postgresql"
|
|
>Section 2.2.2.3</A
|
|
>) and Oracle (<A
|
|
HREF="#oracle"
|
|
>Section 2.2.2.4</A
|
|
>)
|
|
are available.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="database-schema"
|
|
>2.2.2.1. Bugzilla Database Schema</A
|
|
></H4
|
|
><P
|
|
> The Bugzilla database schema is available at
|
|
<A
|
|
HREF="http://www.ravenbrook.com/project/p4dti/tool/cgi/bugzilla-schema/"
|
|
TARGET="_top"
|
|
>Ravenbrook</A
|
|
>.
|
|
This very valuable tool can generate a written description of
|
|
the Bugzilla database schema for any version of Bugzilla. It
|
|
can also generate a diff between two versions to help someone
|
|
see what has changed.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="mysql"
|
|
>2.2.2.2. MySQL</A
|
|
></H4
|
|
><DIV
|
|
CLASS="caution"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="caution"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/caution.gif"
|
|
HSPACE="5"
|
|
ALT="Caution"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> MySQL's default configuration is insecure.
|
|
We highly recommend to run <TT
|
|
CLASS="filename"
|
|
>mysql_secure_installation</TT
|
|
>
|
|
on Linux or the MySQL installer on Windows, and follow the instructions.
|
|
Important points to note are:
|
|
<P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>Be sure that the root account has a secure password set.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Do not create an anonymous account, and if it exists, say "yes"
|
|
to remove it.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>If your web server and MySQL server are on the same machine,
|
|
you should disable the network access.</P
|
|
></LI
|
|
></OL
|
|
>
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="mysql-max-allowed-packet"
|
|
>2.2.2.2.1. Allow large attachments and many comments</A
|
|
></H5
|
|
><P
|
|
>By default, MySQL will only allow you to insert things
|
|
into the database that are smaller than 1MB. Attachments
|
|
may be larger than this. Also, Bugzilla combines all comments
|
|
on a single bug into one field for full-text searching, and the
|
|
combination of all comments on a single bug could in some cases
|
|
be larger than 1MB.</P
|
|
><P
|
|
>To change MySQL's default, you need to edit your MySQL
|
|
configuration file, which is usually <TT
|
|
CLASS="filename"
|
|
>/etc/my.cnf</TT
|
|
>
|
|
on Linux. We recommend that you allow at least 4MB packets by
|
|
adding the "max_allowed_packet" parameter to your MySQL
|
|
configuration in the "[mysqld]" section, like this:</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
>[mysqld]
|
|
# Allow packets up to 4MB
|
|
max_allowed_packet=4M
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN484"
|
|
>2.2.2.2.2. Allow small words in full-text indexes</A
|
|
></H5
|
|
><P
|
|
>By default, words must be at least four characters in length
|
|
in order to be indexed by MySQL's full-text indexes. This causes
|
|
a lot of Bugzilla specific words to be missed, including "cc",
|
|
"ftp" and "uri".</P
|
|
><P
|
|
>MySQL can be configured to index those words by setting the
|
|
ft_min_word_len param to the minimum size of the words to index.
|
|
This can be done by modifying the <TT
|
|
CLASS="filename"
|
|
>/etc/my.cnf</TT
|
|
>
|
|
according to the example below:</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> [mysqld]
|
|
# Allow small words in full-text indexes
|
|
ft_min_word_len=2</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>Rebuilding the indexes can be done based on documentation found at
|
|
<A
|
|
HREF="http://www.mysql.com/doc/en/Fulltext_Fine-tuning.html"
|
|
TARGET="_top"
|
|
>http://www.mysql.com/doc/en/Fulltext_Fine-tuning.html</A
|
|
>.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-setupdatabase-adduser"
|
|
>2.2.2.2.3. Add a user to MySQL</A
|
|
></H5
|
|
><P
|
|
> You need to add a new MySQL user for Bugzilla to use.
|
|
(It's not safe to have Bugzilla use the MySQL root account.)
|
|
The following instructions assume the defaults in
|
|
<TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
>; if you changed those,
|
|
you need to modify the SQL command appropriately. You will
|
|
need the <TT
|
|
CLASS="replaceable"
|
|
><I
|
|
>$db_pass</I
|
|
></TT
|
|
> password you
|
|
set in <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
> in
|
|
<A
|
|
HREF="#localconfig"
|
|
>Section 2.2.1</A
|
|
>.
|
|
</P
|
|
><P
|
|
> We use an SQL <B
|
|
CLASS="command"
|
|
>GRANT</B
|
|
> command to create
|
|
a <SPAN
|
|
CLASS="QUOTE"
|
|
>"bugs"</SPAN
|
|
> user. This also restricts the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"bugs"</SPAN
|
|
>user to operations within a database
|
|
called <SPAN
|
|
CLASS="QUOTE"
|
|
>"bugs"</SPAN
|
|
>, and only allows the account
|
|
to connect from <SPAN
|
|
CLASS="QUOTE"
|
|
>"localhost"</SPAN
|
|
>. Modify it to
|
|
reflect your setup if you will be connecting from another
|
|
machine or as a different user.
|
|
</P
|
|
><P
|
|
> Run the <TT
|
|
CLASS="filename"
|
|
>mysql</TT
|
|
> command-line client and enter:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> <SAMP
|
|
CLASS="prompt"
|
|
>mysql></SAMP
|
|
> GRANT SELECT, INSERT,
|
|
UPDATE, DELETE, INDEX, ALTER, CREATE, LOCK TABLES,
|
|
CREATE TEMPORARY TABLES, DROP, REFERENCES ON bugs.*
|
|
TO bugs@localhost IDENTIFIED BY '<TT
|
|
CLASS="replaceable"
|
|
><I
|
|
>$db_pass</I
|
|
></TT
|
|
>';
|
|
<SAMP
|
|
CLASS="prompt"
|
|
>mysql></SAMP
|
|
> FLUSH PRIVILEGES;
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN511"
|
|
>2.2.2.2.4. Permit attachments table to grow beyond 4GB</A
|
|
></H5
|
|
><P
|
|
> By default, MySQL will limit the size of a table to 4GB.
|
|
This limit is present even if the underlying filesystem
|
|
has no such limit. To set a higher limit, follow these
|
|
instructions.
|
|
</P
|
|
><P
|
|
> After you have completed the rest of the installation (or at least the
|
|
database setup parts), you should run the <TT
|
|
CLASS="filename"
|
|
>MySQL</TT
|
|
>
|
|
command-line client and enter the following, replacing <TT
|
|
CLASS="literal"
|
|
>$bugs_db</TT
|
|
>
|
|
with your Bugzilla database name (<EM
|
|
>bugs</EM
|
|
> by default):
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> <SAMP
|
|
CLASS="prompt"
|
|
>mysql></SAMP
|
|
> use <TT
|
|
CLASS="replaceable"
|
|
><I
|
|
>$bugs_db</I
|
|
></TT
|
|
>
|
|
<SAMP
|
|
CLASS="prompt"
|
|
>mysql></SAMP
|
|
> ALTER TABLE attachments
|
|
AVG_ROW_LENGTH=1000000, MAX_ROWS=20000;
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> The above command will change the limit to 20GB. Mysql will have
|
|
to make a temporary copy of your entire table to do this. Ideally,
|
|
you should do this when your attachments table is still small.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> This does not affect Big Files, attachments that are stored directly
|
|
on disk instead of in the database.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="postgresql"
|
|
>2.2.2.3. PostgreSQL</A
|
|
></H4
|
|
><DIV
|
|
CLASS="section"
|
|
><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN527"
|
|
>2.2.2.3.1. Add a User to PostgreSQL</A
|
|
></H5
|
|
><P
|
|
>You need to add a new user to PostgreSQL for the Bugzilla
|
|
application to use when accessing the database. The following instructions
|
|
assume the defaults in <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
>; if you
|
|
changed those, you need to modify the commands appropriately. You will
|
|
need the <TT
|
|
CLASS="replaceable"
|
|
><I
|
|
>$db_pass</I
|
|
></TT
|
|
> password you
|
|
set in <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
> in
|
|
<A
|
|
HREF="#localconfig"
|
|
>Section 2.2.1</A
|
|
>.</P
|
|
><P
|
|
>On most systems, to create the user in PostgreSQL, you will need to
|
|
login as the root user, and then</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> <SAMP
|
|
CLASS="prompt"
|
|
>bash#</SAMP
|
|
> su - postgres</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>As the postgres user, you then need to create a new user: </P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> <SAMP
|
|
CLASS="prompt"
|
|
>bash$</SAMP
|
|
> createuser -U postgres -dAP bugs</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>When asked for a password, provide the password which will be set as
|
|
<TT
|
|
CLASS="replaceable"
|
|
><I
|
|
>$db_pass</I
|
|
></TT
|
|
> in <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
>.
|
|
The created user will have the ability to create databases and will not be
|
|
able to create new users.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN543"
|
|
>2.2.2.3.2. Configure PostgreSQL</A
|
|
></H5
|
|
><P
|
|
>Now, you will need to edit <TT
|
|
CLASS="filename"
|
|
>pg_hba.conf</TT
|
|
> which is
|
|
usually located in <TT
|
|
CLASS="filename"
|
|
>/var/lib/pgsql/data/</TT
|
|
>. In this file,
|
|
you will need to add a new line to it as follows:</P
|
|
><P
|
|
> <SAMP
|
|
CLASS="computeroutput"
|
|
>host all bugs 127.0.0.1 255.255.255.255 md5</SAMP
|
|
>
|
|
</P
|
|
><P
|
|
>This means that for TCP/IP (host) connections, allow connections from
|
|
'127.0.0.1' to 'all' databases on this server from the 'bugs' user, and use
|
|
password authentication (md5) for that user.</P
|
|
><P
|
|
>Now, you will need to restart PostgreSQL, but you will need to fully
|
|
stop and start the server rather than just restarting due to the possibility
|
|
of a change to <TT
|
|
CLASS="filename"
|
|
>postgresql.conf</TT
|
|
>. After the server has
|
|
restarted, you will need to edit <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
>, finding
|
|
the <TT
|
|
CLASS="literal"
|
|
>$db_driver</TT
|
|
> variable and setting it to
|
|
<TT
|
|
CLASS="literal"
|
|
>Pg</TT
|
|
> and changing the password in <TT
|
|
CLASS="literal"
|
|
>$db_pass</TT
|
|
>
|
|
to the one you picked previously, while setting up the account.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="oracle"
|
|
>2.2.2.4. Oracle</A
|
|
></H4
|
|
><DIV
|
|
CLASS="section"
|
|
><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN559"
|
|
>2.2.2.4.1. Create a New Tablespace</A
|
|
></H5
|
|
><P
|
|
> You can use the existing tablespace or create a new one for Bugzilla.
|
|
To create a new tablespace, run the following command:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> CREATE TABLESPACE bugs
|
|
DATAFILE '<TT
|
|
CLASS="replaceable"
|
|
><I
|
|
>$path_to_datafile</I
|
|
></TT
|
|
>' SIZE 500M
|
|
AUTOEXTEND ON NEXT 30M MAXSIZE UNLIMITED
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> Here, the name of the tablespace is 'bugs', but you can
|
|
choose another name. <TT
|
|
CLASS="replaceable"
|
|
><I
|
|
>$path_to_datafile</I
|
|
></TT
|
|
> is
|
|
the path to the file containing your database, for instance
|
|
<TT
|
|
CLASS="filename"
|
|
>/u01/oradata/bugzilla.dbf</TT
|
|
>.
|
|
The initial size of the database file is set in this example to 500 Mb,
|
|
with an increment of 30 Mb everytime we reach the size limit of the file.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN567"
|
|
>2.2.2.4.2. Add a User to Oracle</A
|
|
></H5
|
|
><P
|
|
> The user name and password must match what you set in
|
|
<TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
> (<TT
|
|
CLASS="literal"
|
|
>$db_user</TT
|
|
>
|
|
and <TT
|
|
CLASS="literal"
|
|
>$db_pass</TT
|
|
>, respectively). Here, we assume that
|
|
the user name is 'bugs' and the tablespace name is the same
|
|
as above.
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> CREATE USER bugs
|
|
IDENTIFIED BY "<TT
|
|
CLASS="replaceable"
|
|
><I
|
|
>$db_pass</I
|
|
></TT
|
|
>"
|
|
DEFAULT TABLESPACE bugs
|
|
TEMPORARY TABLESPACE TEMP
|
|
PROFILE DEFAULT;
|
|
-- GRANT/REVOKE ROLE PRIVILEGES
|
|
GRANT CONNECT TO bugs;
|
|
GRANT RESOURCE TO bugs;
|
|
-- GRANT/REVOKE SYSTEM PRIVILEGES
|
|
GRANT UNLIMITED TABLESPACE TO bugs;
|
|
GRANT EXECUTE ON CTXSYS.CTX_DDL TO bugs;
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN575"
|
|
>2.2.2.4.3. Configure the Web Server</A
|
|
></H5
|
|
><P
|
|
> If you use Apache, append these lines to <TT
|
|
CLASS="filename"
|
|
>httpd.conf</TT
|
|
>
|
|
to set ORACLE_HOME and LD_LIBRARY_PATH. For instance:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> SetEnv ORACLE_HOME /u01/app/oracle/product/10.2.0/
|
|
SetEnv LD_LIBRARY_PATH /u01/app/oracle/product/10.2.0/lib/
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> When this is done, restart your web server.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN581"
|
|
>2.2.3. checksetup.pl</A
|
|
></H3
|
|
><P
|
|
> Next, rerun <TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
>. It reconfirms
|
|
that all the modules are present, and notices the altered
|
|
localconfig file, which it assumes you have edited to your
|
|
satisfaction. It compiles the UI templates,
|
|
connects to the database using the 'bugs'
|
|
user you created and the password you defined, and creates the
|
|
'bugs' database and the tables therein.
|
|
</P
|
|
><P
|
|
> After that, it asks for details of an administrator account. Bugzilla
|
|
can have multiple administrators - you can create more later - but
|
|
it needs one to start off with.
|
|
Enter the email address of an administrator, his or her full name,
|
|
and a suitable Bugzilla password.
|
|
</P
|
|
><P
|
|
> <TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> will then finish. You may rerun
|
|
<TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> at any time if you wish.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="http"
|
|
>2.2.4. Web server</A
|
|
></H3
|
|
><P
|
|
> Configure your web server according to the instructions in the
|
|
appropriate section. (If it makes a difference in your choice,
|
|
the Bugzilla Team recommends Apache.) To check whether your web server
|
|
is correctly configured, try to access <TT
|
|
CLASS="filename"
|
|
>testagent.cgi</TT
|
|
>
|
|
from your web server. If "OK" is displayed, then your configuration
|
|
is successful. Regardless of which web server
|
|
you are using, however, ensure that sensitive information is
|
|
not remotely available by properly applying the access controls in
|
|
<A
|
|
HREF="#security-webserver-access"
|
|
>Section 4.2.1</A
|
|
>. You can run
|
|
<TT
|
|
CLASS="filename"
|
|
>testserver.pl</TT
|
|
> to check if your web server serves
|
|
Bugzilla files as expected.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="http-apache"
|
|
>2.2.4.1. Bugzilla using Apache</A
|
|
></H4
|
|
><P
|
|
>You have two options for running Bugzilla under Apache -
|
|
<A
|
|
HREF="#http-apache-mod_cgi"
|
|
>mod_cgi</A
|
|
> (the default) and
|
|
<A
|
|
HREF="#http-apache-mod_perl"
|
|
>mod_perl</A
|
|
> (new in Bugzilla
|
|
2.23)
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="http-apache-mod_cgi"
|
|
>2.2.4.1.1. Apache <SPAN
|
|
CLASS="productname"
|
|
>httpd</SPAN
|
|
> with mod_cgi</A
|
|
></H5
|
|
><P
|
|
> To configure your Apache web server to work with Bugzilla while using
|
|
mod_cgi, do the following:
|
|
</P
|
|
><DIV
|
|
CLASS="procedure"
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
> Load <TT
|
|
CLASS="filename"
|
|
>httpd.conf</TT
|
|
> in your editor.
|
|
In Fedora and Red Hat Linux, this file is found in
|
|
<TT
|
|
CLASS="filename"
|
|
>/etc/httpd/conf</TT
|
|
>.
|
|
</P
|
|
></LI
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
> Apache uses <SAMP
|
|
CLASS="computeroutput"
|
|
><Directory></SAMP
|
|
>
|
|
directives to permit fine-grained permission setting. Add the
|
|
following lines to a directive that applies to the location
|
|
of your Bugzilla installation. (If such a section does not
|
|
exist, you'll want to add one.) In this example, Bugzilla has
|
|
been installed at
|
|
<TT
|
|
CLASS="filename"
|
|
>/var/www/html/bugzilla</TT
|
|
>.
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> <Directory /var/www/html/bugzilla>
|
|
AddHandler cgi-script .cgi
|
|
Options +Indexes +ExecCGI
|
|
DirectoryIndex index.cgi
|
|
AllowOverride Limit
|
|
</Directory>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> These instructions: allow apache to run .cgi files found
|
|
within the bugzilla directory; instructs the server to look
|
|
for a file called <TT
|
|
CLASS="filename"
|
|
>index.cgi</TT
|
|
> if someone
|
|
only types the directory name into the browser; and allows
|
|
Bugzilla's <TT
|
|
CLASS="filename"
|
|
>.htaccess</TT
|
|
> files to override
|
|
global permissions.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> It is possible to make these changes globally, or to the
|
|
directive controlling Bugzilla's parent directory (e.g.
|
|
<SAMP
|
|
CLASS="computeroutput"
|
|
><Directory /var/www/html/></SAMP
|
|
>).
|
|
Such changes would also apply to the Bugzilla directory...
|
|
but they would also apply to many other places where they
|
|
may or may not be appropriate. In most cases, including
|
|
this one, it is better to be as restrictive as possible
|
|
when granting extra access.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> On Windows, you may have to also add the
|
|
<SAMP
|
|
CLASS="computeroutput"
|
|
>ScriptInterpreterSource Registry-Strict</SAMP
|
|
>
|
|
line, see <A
|
|
HREF="#win32-http"
|
|
>Windows specific notes</A
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></LI
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
> <TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> can set tighter permissions
|
|
on Bugzilla's files and directories if it knows what group the
|
|
web server runs as. Find the <SAMP
|
|
CLASS="computeroutput"
|
|
>Group</SAMP
|
|
>
|
|
line in <TT
|
|
CLASS="filename"
|
|
>httpd.conf</TT
|
|
>, place the value found
|
|
there in the <TT
|
|
CLASS="replaceable"
|
|
><I
|
|
>$webservergroup</I
|
|
></TT
|
|
> variable
|
|
in <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
>, then rerun
|
|
<TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
>.
|
|
</P
|
|
></LI
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
> Optional: If Bugzilla does not actually reside in the webspace
|
|
directory, but instead has been symbolically linked there, you
|
|
will need to add the following to the
|
|
<SAMP
|
|
CLASS="computeroutput"
|
|
>Options</SAMP
|
|
> line of the Bugzilla
|
|
<SAMP
|
|
CLASS="computeroutput"
|
|
><Directory></SAMP
|
|
> directive
|
|
(the same one as in the step above):
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> +FollowSymLinks
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> Without this directive, Apache will not follow symbolic links
|
|
to places outside its own directory structure, and you will be
|
|
unable to run Bugzilla.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="http-apache-mod_perl"
|
|
>2.2.4.1.2. Apache <SPAN
|
|
CLASS="productname"
|
|
>httpd</SPAN
|
|
> with mod_perl</A
|
|
></H5
|
|
><P
|
|
>Some configuration is required to make Bugzilla work with Apache
|
|
and mod_perl</P
|
|
><DIV
|
|
CLASS="procedure"
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
> Load <TT
|
|
CLASS="filename"
|
|
>httpd.conf</TT
|
|
> in your editor.
|
|
In Fedora and Red Hat Linux, this file is found in
|
|
<TT
|
|
CLASS="filename"
|
|
>/etc/httpd/conf</TT
|
|
>.
|
|
</P
|
|
></LI
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
>Add the following information to your httpd.conf file, substituting
|
|
where appropriate with your own local paths.</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>This should be used instead of the <Directory> block
|
|
shown above. This should also be above any other <TT
|
|
CLASS="literal"
|
|
>mod_perl</TT
|
|
>
|
|
directives within the <TT
|
|
CLASS="filename"
|
|
>httpd.conf</TT
|
|
> and must be specified
|
|
in the order as below.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>You should also ensure that you have disabled <TT
|
|
CLASS="literal"
|
|
>KeepAlive</TT
|
|
>
|
|
support in your Apache install when utilizing Bugzilla under mod_perl</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> PerlSwitches -I/var/www/html/bugzilla -I/var/www/html/bugzilla/lib -w -T
|
|
PerlConfigRequire /var/www/html/bugzilla/mod_perl.pl
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></LI
|
|
><LI
|
|
CLASS="step"
|
|
><P
|
|
> <TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> can set tighter permissions
|
|
on Bugzilla's files and directories if it knows what group the
|
|
web server runs as. Find the <SAMP
|
|
CLASS="computeroutput"
|
|
>Group</SAMP
|
|
>
|
|
line in <TT
|
|
CLASS="filename"
|
|
>httpd.conf</TT
|
|
>, place the value found
|
|
there in the <TT
|
|
CLASS="replaceable"
|
|
><I
|
|
>$webservergroup</I
|
|
></TT
|
|
> variable
|
|
in <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
>, then rerun
|
|
<TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
>.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><P
|
|
>On restarting Apache, Bugzilla should now be running within the
|
|
mod_perl environment. Please ensure you have run checksetup.pl to set
|
|
permissions before you restart Apache.</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Please bear the following points in mind when looking at using
|
|
Bugzilla under mod_perl:
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> mod_perl support in Bugzilla can take up a HUGE amount of RAM. You could be
|
|
looking at 30MB per httpd child, easily. Basically, you just need a lot of RAM.
|
|
The more RAM you can get, the better. mod_perl is basically trading RAM for
|
|
speed. At least 2GB total system RAM is recommended for running Bugzilla under
|
|
mod_perl.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Under mod_perl, you have to restart Apache if you make any manual change to
|
|
any Bugzilla file. You can't just reload--you have to actually
|
|
<EM
|
|
>restart</EM
|
|
> the server (as in make sure it stops and starts
|
|
again). You <EM
|
|
>can</EM
|
|
> change localconfig and the params file
|
|
manually, if you want, because those are re-read every time you load a page.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> You must run in Apache's Prefork MPM (this is the default). The Worker MPM
|
|
may not work--we haven't tested Bugzilla's mod_perl support under threads.
|
|
(And, in fact, we're fairly sure it <EM
|
|
>won't</EM
|
|
> work.)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Bugzilla generally expects to be the only mod_perl application running on
|
|
your entire server. It may or may not work if there are other applications also
|
|
running under mod_perl. It does try its best to play nice with other mod_perl
|
|
applications, but it still may have conflicts.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> It is recommended that you have one Bugzilla instance running under mod_perl
|
|
on your server. Bugzilla has not been tested with more than one instance running.
|
|
</P
|
|
></LI
|
|
></UL
|
|
>
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="http-iis"
|
|
>2.2.4.2. Microsoft <SPAN
|
|
CLASS="productname"
|
|
>Internet Information Services</SPAN
|
|
></A
|
|
></H4
|
|
><P
|
|
> If you are running Bugzilla on Windows and choose to use
|
|
Microsoft's <SPAN
|
|
CLASS="productname"
|
|
>Internet Information Services</SPAN
|
|
>
|
|
or <SPAN
|
|
CLASS="productname"
|
|
>Personal Web Server</SPAN
|
|
> you will need
|
|
to perform a number of other configuration steps as explained below.
|
|
You may also want to refer to the following Microsoft Knowledge
|
|
Base articles:
|
|
<A
|
|
HREF="http://support.microsoft.com/default.aspx?scid=kb;en-us;245225"
|
|
TARGET="_top"
|
|
>245225</A
|
|
>
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"HOW TO: Configure and Test a PERL Script with IIS 4.0,
|
|
5.0, and 5.1"</SPAN
|
|
> (for <SPAN
|
|
CLASS="productname"
|
|
>Internet Information
|
|
Services</SPAN
|
|
>) and
|
|
<A
|
|
HREF="http://support.microsoft.com/default.aspx?scid=kb;en-us;231998"
|
|
TARGET="_top"
|
|
>231998</A
|
|
>
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"HOW TO: FP2000: How to Use Perl with Microsoft Personal Web
|
|
Server on Windows 95/98"</SPAN
|
|
> (for <SPAN
|
|
CLASS="productname"
|
|
>Personal Web
|
|
Server</SPAN
|
|
>).
|
|
</P
|
|
><P
|
|
> You will need to create a virtual directory for the Bugzilla
|
|
install. Put the Bugzilla files in a directory that is named
|
|
something <EM
|
|
>other</EM
|
|
> than what you want your
|
|
end-users accessing. That is, if you want your users to access
|
|
your Bugzilla installation through
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"http://<yourdomainname>/Bugzilla"</SPAN
|
|
>, then do
|
|
<EM
|
|
>not</EM
|
|
> put your Bugzilla files in a directory
|
|
named <SPAN
|
|
CLASS="QUOTE"
|
|
>"Bugzilla"</SPAN
|
|
>. Instead, place them in a different
|
|
location, and then use the IIS Administration tool to create a
|
|
Virtual Directory named "Bugzilla" that acts as an alias for the
|
|
actual location of the files. When creating that virtual directory,
|
|
make sure you add the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Execute (such as ISAPI applications or
|
|
CGI)"</SPAN
|
|
> access permission.
|
|
</P
|
|
><P
|
|
> You will also need to tell IIS how to handle Bugzilla's
|
|
.cgi files. Using the IIS Administration tool again, open up
|
|
the properties for the new virtual directory and select the
|
|
Configuration option to access the Script Mappings. Create an
|
|
entry mapping .cgi to:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> <full path to perl.exe >\perl.exe -x<full path to Bugzilla> -wT "%s" %s
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> For example:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> The ActiveState install may have already created an entry for
|
|
.pl files that is limited to <SPAN
|
|
CLASS="QUOTE"
|
|
>"GET,HEAD,POST"</SPAN
|
|
>. If
|
|
so, this mapping should be <EM
|
|
>removed</EM
|
|
> as
|
|
Bugzilla's .pl files are not designed to be run via a web server.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> IIS will also need to know that the index.cgi should be treated
|
|
as a default document. On the Documents tab page of the virtual
|
|
directory properties, you need to add index.cgi as a default
|
|
document type. If you wish, you may remove the other default
|
|
document types for this particular virtual directory, since Bugzilla
|
|
doesn't use any of them.
|
|
</P
|
|
><P
|
|
> Also, and this can't be stressed enough, make sure that files
|
|
such as <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
> and your
|
|
<TT
|
|
CLASS="filename"
|
|
>data</TT
|
|
> directory are
|
|
secured as described in <A
|
|
HREF="#security-webserver-access"
|
|
>Section 4.2.1</A
|
|
>.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-config-bugzilla"
|
|
>2.2.5. Bugzilla</A
|
|
></H3
|
|
><P
|
|
> Your Bugzilla should now be working. Access
|
|
<TT
|
|
CLASS="filename"
|
|
>http://<your-bugzilla-server>/</TT
|
|
> -
|
|
you should see the Bugzilla
|
|
front page. If not, consult the Troubleshooting section,
|
|
<A
|
|
HREF="#troubleshooting"
|
|
>Appendix A</A
|
|
>.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> The URL above may be incorrect if you installed Bugzilla into a
|
|
subdirectory or used a symbolic link from your web site root to
|
|
the Bugzilla directory.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> Log in with the administrator account you defined in the last
|
|
<TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> run. You should go through
|
|
the Parameters page and see if there are any you wish to change.
|
|
They key parameters are documented in <A
|
|
HREF="#parameters"
|
|
>Section 3.1</A
|
|
>;
|
|
you should certainly alter
|
|
<B
|
|
CLASS="command"
|
|
>maintainer</B
|
|
> and <B
|
|
CLASS="command"
|
|
>urlbase</B
|
|
>;
|
|
you may also want to alter
|
|
<B
|
|
CLASS="command"
|
|
>cookiepath</B
|
|
> or <B
|
|
CLASS="command"
|
|
>requirelogin</B
|
|
>.
|
|
</P
|
|
><P
|
|
> Bugzilla has several optional features which require extra
|
|
configuration. You can read about those in
|
|
<A
|
|
HREF="#extraconfig"
|
|
>Section 2.3</A
|
|
>.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="extraconfig"
|
|
>2.3. Optional Additional Configuration</A
|
|
></H2
|
|
><P
|
|
> Bugzilla has a number of optional features. This section describes how
|
|
to configure or enable them.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN732"
|
|
>2.3.1. Bug Graphs</A
|
|
></H3
|
|
><P
|
|
>If you have installed the necessary Perl modules you
|
|
can start collecting statistics for the nifty Bugzilla
|
|
graphs.</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
><SAMP
|
|
CLASS="prompt"
|
|
>bash#</SAMP
|
|
> <B
|
|
CLASS="command"
|
|
>crontab -e</B
|
|
></PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> This should bring up the crontab file in your editor.
|
|
Add a cron entry like this to run
|
|
<TT
|
|
CLASS="filename"
|
|
>collectstats.pl</TT
|
|
>
|
|
daily at 5 after midnight:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>5 0 * * * cd <your-bugzilla-directory> ; ./collectstats.pl</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> After two days have passed you'll be able to view bug graphs from
|
|
the Reports page.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> 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
|
|
<A
|
|
HREF="http://www.nncron.ru/"
|
|
TARGET="_top"
|
|
>nncron</A
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="installation-whining-cron"
|
|
>2.3.2. The Whining Cron</A
|
|
></H3
|
|
><P
|
|
>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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>55 0 * * * cd <your-bugzilla-directory> ; ./whineatnews.pl</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> 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
|
|
<A
|
|
HREF="http://www.nncron.ru/"
|
|
TARGET="_top"
|
|
>nncron</A
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="installation-whining"
|
|
>2.3.3. Whining</A
|
|
></H3
|
|
><P
|
|
> 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 <A
|
|
HREF="#whining"
|
|
>Section 5.13</A
|
|
>, but for it to work a Perl script must be
|
|
executed at regular intervals.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>*/15 * * * * cd <your-bugzilla-directory> ; ./whine.pl</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> 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.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> 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
|
|
<A
|
|
HREF="http://www.nncron.ru/"
|
|
TARGET="_top"
|
|
>nncron</A
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="apache-addtype"
|
|
>2.3.4. Serving Alternate Formats with the right MIME type</A
|
|
></H3
|
|
><P
|
|
> Some Bugzilla pages have alternate formats, other than just plain
|
|
<ACRONYM
|
|
CLASS="acronym"
|
|
>HTML</ACRONYM
|
|
>. In particular, a few Bugzilla pages can
|
|
output their contents as either <ACRONYM
|
|
CLASS="acronym"
|
|
>XUL</ACRONYM
|
|
> (a special
|
|
Mozilla format, that looks like a program <ACRONYM
|
|
CLASS="acronym"
|
|
>GUI</ACRONYM
|
|
>)
|
|
or <ACRONYM
|
|
CLASS="acronym"
|
|
>RDF</ACRONYM
|
|
> (a type of structured <ACRONYM
|
|
CLASS="acronym"
|
|
>XML</ACRONYM
|
|
>
|
|
that can be read by various programs).
|
|
</P
|
|
><P
|
|
> In order for your users to see these pages correctly, Apache must
|
|
send them with the right <ACRONYM
|
|
CLASS="acronym"
|
|
>MIME</ACRONYM
|
|
> type. To do this,
|
|
add the following lines to your Apache configuration, either in the
|
|
<SAMP
|
|
CLASS="computeroutput"
|
|
><VirtualHost></SAMP
|
|
> section for your
|
|
Bugzilla, or in the <SAMP
|
|
CLASS="computeroutput"
|
|
><Directory></SAMP
|
|
>
|
|
section for your Bugzilla:
|
|
</P
|
|
><P
|
|
> <TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
>AddType application/vnd.mozilla.xul+xml .xul
|
|
AddType application/rdf+xml .rdf</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="multiple-bz-dbs"
|
|
>2.4. Multiple Bugzilla databases with a single installation</A
|
|
></H2
|
|
><P
|
|
>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
|
|
<TT
|
|
CLASS="filename"
|
|
>localconfig.<PROJECT></TT
|
|
> in the same location as
|
|
the default one (<TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
>). It also checks for
|
|
customized templates in a directory named
|
|
<TT
|
|
CLASS="filename"
|
|
><PROJECT></TT
|
|
> in the same location as the
|
|
default one (<TT
|
|
CLASS="filename"
|
|
>template/<langcode></TT
|
|
>). By default
|
|
this is <TT
|
|
CLASS="filename"
|
|
>template/en/default</TT
|
|
> so PROJECT's templates
|
|
would be located at <TT
|
|
CLASS="filename"
|
|
>template/en/PROJECT</TT
|
|
>.</P
|
|
><P
|
|
>To set up an alternate installation, just export PROJECT=foo before
|
|
running <B
|
|
CLASS="command"
|
|
>checksetup.pl</B
|
|
> for the first time. It will
|
|
result in a file called <TT
|
|
CLASS="filename"
|
|
>localconfig.foo</TT
|
|
> instead of
|
|
<TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
>. Edit this file as described above, with
|
|
reference to a new database, and re-run <B
|
|
CLASS="command"
|
|
>checksetup.pl</B
|
|
>
|
|
to populate it. That's all.</P
|
|
><P
|
|
>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.
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> <VirtualHost 212.85.153.228:80>
|
|
ServerName foo.bar.baz
|
|
SetEnv PROJECT foo
|
|
Alias /bugzilla /var/www/bugzilla
|
|
</VirtualHost>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
</P
|
|
><P
|
|
>Don't forget to also export this variable before accessing Bugzilla
|
|
by other means, such as cron tasks for instance.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="os-specific"
|
|
>2.5. OS-Specific Installation Notes</A
|
|
></H2
|
|
><P
|
|
>Many aspects of the Bugzilla installation can be affected by the
|
|
operating system you choose to install it on. Sometimes it can be made
|
|
easier and others more difficult. This section will attempt to help you
|
|
understand both the difficulties of running on specific operating systems
|
|
and the utilities available to make it easier.
|
|
</P
|
|
><P
|
|
>If you have anything to add or notes for an operating system not
|
|
covered, please file a bug in <A
|
|
HREF="https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&component=Documentation"
|
|
TARGET="_top"
|
|
>Bugzilla Documentation</A
|
|
>.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="os-win32"
|
|
>2.5.1. Microsoft Windows</A
|
|
></H3
|
|
><P
|
|
> Making Bugzilla work on Windows is more difficult than making it
|
|
work on Unix. For that reason, we still recommend doing so on a Unix
|
|
based system such as GNU/Linux. That said, if you do want to get
|
|
Bugzilla running on Windows, you will need to make the following
|
|
adjustments. A detailed step-by-step
|
|
<A
|
|
HREF="https://wiki.mozilla.org/Bugzilla:Win32Install"
|
|
TARGET="_top"
|
|
> installation guide for Windows</A
|
|
> is also available
|
|
if you need more help with your installation.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="win32-perl"
|
|
>2.5.1.1. Win32 Perl</A
|
|
></H4
|
|
><P
|
|
> Perl for Windows can be obtained from
|
|
<A
|
|
HREF="http://www.activestate.com/"
|
|
TARGET="_top"
|
|
>ActiveState</A
|
|
>.
|
|
You should be able to find a compiled binary at <A
|
|
HREF="http://aspn.activestate.com/ASPN/Downloads/ActivePerl/"
|
|
TARGET="_top"
|
|
>http://aspn.activestate.com/ASPN/Downloads/ActivePerl/</A
|
|
>.
|
|
The following instructions assume that you are using version
|
|
5.8.1 of ActiveState.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> These instructions are for 32-bit versions of Windows. If you are
|
|
using a 64-bit version of Windows, you will need to install 32-bit
|
|
Perl in order to install the 32-bit modules as described below.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="win32-perl-modules"
|
|
>2.5.1.2. Perl Modules on Win32</A
|
|
></H4
|
|
><P
|
|
> Bugzilla on Windows requires the same perl modules found in
|
|
<A
|
|
HREF="#install-perlmodules"
|
|
>Section 2.1.5</A
|
|
>. The main difference is that
|
|
windows uses <A
|
|
HREF="#gloss-ppm"
|
|
><I
|
|
CLASS="glossterm"
|
|
>PPM</I
|
|
></A
|
|
> instead
|
|
of CPAN. ActiveState provides a GUI to manage Perl modules. We highly
|
|
recommend that you use it. If you prefer to use ppm from the
|
|
command-line, type:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> C:\perl> <B
|
|
CLASS="command"
|
|
>ppm install <module name></B
|
|
>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> The best source for the Windows PPM modules needed for Bugzilla
|
|
is probably the theory58S website, which you can add to your list
|
|
of repositories as follows (for Perl 5.8.x):
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> <B
|
|
CLASS="command"
|
|
>ppm repo add theory58S http://theoryx5.uwinnipeg.ca/ppms/</B
|
|
>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> If you are using Perl 5.10.x, you cannot use the same PPM modules as Perl
|
|
5.8.x as they are incompatible. In this case, you should add the following
|
|
repository:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> <B
|
|
CLASS="command"
|
|
>ppm repo add theory58S http://cpan.uwinnipeg.ca/PPMPackages/10xx/</B
|
|
>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> In versions prior to 5.8.8 build 819 of PPM the command is
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> <B
|
|
CLASS="command"
|
|
>ppm repository add theory58S http://theoryx5.uwinnipeg.ca/ppms/</B
|
|
>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> The PPM repository stores modules in 'packages' that may have
|
|
a slightly different name than the module. If retrieving these
|
|
modules from there, you will need to pay attention to the information
|
|
provided when you run <B
|
|
CLASS="command"
|
|
>checksetup.pl</B
|
|
> as it will
|
|
tell you what package you'll need to install.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="tip"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="tip"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If you are behind a corporate firewall, you will need to let the
|
|
ActiveState PPM utility know how to get through it to access
|
|
the repositories by setting the HTTP_proxy system environmental
|
|
variable. For more information on setting that variable, see
|
|
the ActiveState documentation.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="win32-http"
|
|
>2.5.1.3. Serving the web pages</A
|
|
></H4
|
|
><P
|
|
> As is the case on Unix based systems, any web server should
|
|
be able to handle Bugzilla; however, the Bugzilla Team still
|
|
recommends Apache whenever asked. No matter what web server
|
|
you choose, be sure to pay attention to the security notes
|
|
in <A
|
|
HREF="#security-webserver-access"
|
|
>Section 4.2.1</A
|
|
>. More
|
|
information on configuring specific web servers can be found
|
|
in <A
|
|
HREF="#http"
|
|
>Section 2.2.4</A
|
|
>.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> The web server looks at <TT
|
|
CLASS="filename"
|
|
>/usr/bin/perl</TT
|
|
> to
|
|
call Perl. If you are using Apache on windows, you can set the
|
|
<A
|
|
HREF="http://httpd.apache.org/docs-2.0/mod/core.html#scriptinterpretersource"
|
|
TARGET="_top"
|
|
>ScriptInterpreterSource</A
|
|
>
|
|
directive in your Apache config file to make it look at the
|
|
right place: insert the line
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>ScriptInterpreterSource Registry-Strict</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
into your <TT
|
|
CLASS="filename"
|
|
>httpd.conf</TT
|
|
> file, and create the key
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>HKEY_CLASSES_ROOT\.cgi\Shell\ExecCGI\Command</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
with <CODE
|
|
CLASS="option"
|
|
>C:\Perl\bin\perl.exe -T</CODE
|
|
> as value (adapt to your
|
|
path if needed) in the registry. When this is done, restart Apache.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="win32-email"
|
|
>2.5.1.4. Sending Email</A
|
|
></H4
|
|
><P
|
|
> To enable Bugzilla to send email on Windows, the server running the
|
|
Bugzilla code must be able to connect to, or act as, an SMTP server.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="os-macosx"
|
|
>2.5.2. <SPAN
|
|
CLASS="productname"
|
|
>Mac OS X</SPAN
|
|
></A
|
|
></H3
|
|
><P
|
|
>Making Bugzilla work on Mac OS X requires the following
|
|
adjustments.</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="macosx-sendmail"
|
|
>2.5.2.1. Sendmail</A
|
|
></H4
|
|
><P
|
|
>In Mac OS X 10.3 and later,
|
|
<A
|
|
HREF="http://www.postfix.org/"
|
|
TARGET="_top"
|
|
>Postfix</A
|
|
>
|
|
is used as the built-in email server. Postfix provides an executable
|
|
that mimics sendmail enough to fool Bugzilla, as long as Bugzilla can
|
|
find it.</P
|
|
><P
|
|
>As of version 2.20, Bugzilla will be able to find the fake
|
|
sendmail executable without any assistance. However, you will have
|
|
to turn on the sendmailnow parameter before you do anything that would
|
|
result in email being sent. For more information, see the description
|
|
of the sendmailnow parameter in <A
|
|
HREF="#parameters"
|
|
>Section 3.1</A
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="macosx-libraries"
|
|
>2.5.2.2. Libraries & Perl Modules on Mac OS X</A
|
|
></H4
|
|
><P
|
|
>Apple does not include the GD library with Mac OS X. Bugzilla
|
|
needs this for bug graphs.</P
|
|
><P
|
|
>You can use DarwinPorts (<A
|
|
HREF="http://darwinports.com/"
|
|
TARGET="_top"
|
|
>http://darwinports.com/</A
|
|
>)
|
|
or Fink (<A
|
|
HREF="http://sourceforge.net/projects/fink/"
|
|
TARGET="_top"
|
|
>http://sourceforge.net/projects/fink/</A
|
|
>), both
|
|
of which are similar in nature to the CPAN installer, but install
|
|
common unix programs.</P
|
|
><P
|
|
>Follow the instructions for setting up DarwinPorts or Fink.
|
|
Once you have one installed, you'll want to use it to install the
|
|
<TT
|
|
CLASS="filename"
|
|
>gd2</TT
|
|
> package.
|
|
</P
|
|
><P
|
|
>Fink will prompt you for a number of dependencies, type 'y' and hit
|
|
enter to install all of the dependencies and then watch it work. You will
|
|
then be able to use <A
|
|
HREF="#gloss-cpan"
|
|
><I
|
|
CLASS="glossterm"
|
|
>CPAN</I
|
|
></A
|
|
> to
|
|
install the GD Perl module.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>To prevent creating conflicts with the software that Apple
|
|
installs by default, Fink creates its own directory tree at
|
|
<TT
|
|
CLASS="filename"
|
|
>/sw</TT
|
|
> where it installs most of
|
|
the software that it installs. This means your libraries and headers
|
|
will be at <TT
|
|
CLASS="filename"
|
|
>/sw/lib</TT
|
|
> and
|
|
<TT
|
|
CLASS="filename"
|
|
>/sw/include</TT
|
|
> instead of
|
|
<TT
|
|
CLASS="filename"
|
|
>/usr/lib</TT
|
|
> and
|
|
<TT
|
|
CLASS="filename"
|
|
>/usr/include</TT
|
|
>. When the
|
|
Perl module config script asks where your <TT
|
|
CLASS="filename"
|
|
>libgd</TT
|
|
>
|
|
is, be sure to tell it
|
|
<TT
|
|
CLASS="filename"
|
|
>/sw/lib</TT
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
>Also available via DarwinPorts and Fink is
|
|
<TT
|
|
CLASS="filename"
|
|
>expat</TT
|
|
>. After installing the expat package, you
|
|
will be able to install XML::Parser using CPAN. If you use fink, there
|
|
is one caveat. Unlike recent versions of
|
|
the GD module, XML::Parser doesn't prompt for the location of the
|
|
required libraries. When using CPAN, you will need to use the following
|
|
command sequence:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> # perl -MCPAN -e'look XML::Parser' <A
|
|
NAME="macosx-look"
|
|
><IMG
|
|
SRC="../images/callouts/1.gif"
|
|
HSPACE="0"
|
|
VSPACE="0"
|
|
BORDER="0"
|
|
ALT="(1)"></A
|
|
>
|
|
# perl Makefile.PL EXPATLIBPATH=/sw/lib EXPATINCPATH=/sw/include
|
|
# make; make test; make install <A
|
|
NAME="macosx-make"
|
|
><IMG
|
|
SRC="../images/callouts/2.gif"
|
|
HSPACE="0"
|
|
VSPACE="0"
|
|
BORDER="0"
|
|
ALT="(2)"></A
|
|
>
|
|
# exit <A
|
|
NAME="macosx-exit"
|
|
><IMG
|
|
SRC="../images/callouts/3.gif"
|
|
HSPACE="0"
|
|
VSPACE="0"
|
|
BORDER="0"
|
|
ALT="(3)"></A
|
|
>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="calloutlist"
|
|
><DL
|
|
COMPACT="COMPACT"
|
|
><DT
|
|
><A
|
|
HREF="#macosx-look"
|
|
><IMG
|
|
SRC="../images/callouts/1.gif"
|
|
HSPACE="0"
|
|
VSPACE="0"
|
|
BORDER="0"
|
|
ALT="(1)"></A
|
|
><A
|
|
HREF="#macosx-exit"
|
|
><IMG
|
|
SRC="../images/callouts/3.gif"
|
|
HSPACE="0"
|
|
VSPACE="0"
|
|
BORDER="0"
|
|
ALT="(3)"></A
|
|
></DT
|
|
><DD
|
|
>The look command will download the module and spawn a
|
|
new shell with the extracted files as the current working directory.
|
|
The exit command will return you to your original shell.
|
|
</DD
|
|
><DT
|
|
><A
|
|
HREF="#macosx-make"
|
|
><IMG
|
|
SRC="../images/callouts/2.gif"
|
|
HSPACE="0"
|
|
VSPACE="0"
|
|
BORDER="0"
|
|
ALT="(2)"></A
|
|
></DT
|
|
><DD
|
|
>You should watch the output from these make commands,
|
|
especially <SPAN
|
|
CLASS="QUOTE"
|
|
>"make test"</SPAN
|
|
> as errors may prevent
|
|
XML::Parser from functioning correctly with Bugzilla.
|
|
</DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="os-linux"
|
|
>2.5.3. Linux Distributions</A
|
|
></H3
|
|
><P
|
|
>Many Linux distributions include Bugzilla and its
|
|
dependencies in their native package management systems.
|
|
Installing Bugzilla with root access on any Linux system
|
|
should be as simple as finding the Bugzilla package in the
|
|
package management application and installing it using the
|
|
normal command syntax. Several distributions also perform
|
|
the proper web server configuration automatically on installation.
|
|
</P
|
|
><P
|
|
>Please consult the documentation of your Linux
|
|
distribution for instructions on how to install packages,
|
|
or for specific instructions on installing Bugzilla with
|
|
native package management tools. There is also a
|
|
<A
|
|
HREF="http://wiki.mozilla.org/Bugzilla:Linux_Distro_Installation"
|
|
TARGET="_top"
|
|
> Bugzilla Wiki Page</A
|
|
> for distro-specific installation
|
|
notes.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="nonroot"
|
|
>2.6. UNIX (non-root) Installation Notes</A
|
|
></H2
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN897"
|
|
>2.6.1. Introduction</A
|
|
></H3
|
|
><P
|
|
>If you are running a *NIX OS as non-root, either due
|
|
to lack of access (web hosts, for example) or for security
|
|
reasons, this will detail how to install Bugzilla on such
|
|
a setup. It is recommended that you read through the
|
|
<A
|
|
HREF="#installation"
|
|
>Section 2.1</A
|
|
>
|
|
first to get an idea on the installation steps required.
|
|
(These notes will reference to steps in that guide.)</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN901"
|
|
>2.6.2. MySQL</A
|
|
></H3
|
|
><P
|
|
>You may have MySQL installed as root. If you're
|
|
setting up an account with a web host, a MySQL account
|
|
needs to be set up for you. From there, you can create
|
|
the bugs account, or use the account given to you.</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>You may have problems trying to set up
|
|
<B
|
|
CLASS="command"
|
|
>GRANT</B
|
|
> permissions to the database.
|
|
If you're using a web host, chances are that you have a
|
|
separate database which is already locked down (or one big
|
|
database with limited/no access to the other areas), but you
|
|
may want to ask your system administrator what the security
|
|
settings are set to, and/or run the <B
|
|
CLASS="command"
|
|
>GRANT</B
|
|
>
|
|
command for you.</P
|
|
><P
|
|
>Also, you will probably not be able to change the MySQL
|
|
root user password (for obvious reasons), so skip that
|
|
step.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN909"
|
|
>2.6.2.1. Running MySQL as Non-Root</A
|
|
></H4
|
|
><DIV
|
|
CLASS="section"
|
|
><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN911"
|
|
>2.6.2.1.1. The Custom Configuration Method</A
|
|
></H5
|
|
><P
|
|
>Create a file .my.cnf in your
|
|
home directory (using /home/foo in this example)
|
|
as follows....</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> [mysqld]
|
|
datadir=/home/foo/mymysql
|
|
socket=/home/foo/mymysql/thesock
|
|
port=8081
|
|
|
|
[mysql]
|
|
socket=/home/foo/mymysql/thesock
|
|
port=8081
|
|
|
|
[mysql.server]
|
|
user=mysql
|
|
basedir=/var/lib
|
|
|
|
[safe_mysqld]
|
|
err-log=/home/foo/mymysql/the.log
|
|
pid-file=/home/foo/mymysql/the.pid
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN915"
|
|
>2.6.2.1.2. The Custom Built Method</A
|
|
></H5
|
|
><P
|
|
>You can install MySQL as a not-root, if you really need to.
|
|
Build it with PREFIX set to <TT
|
|
CLASS="filename"
|
|
>/home/foo/mysql</TT
|
|
>,
|
|
or use pre-installed executables, specifying that you want
|
|
to put all of the data files in <TT
|
|
CLASS="filename"
|
|
>/home/foo/mysql/data</TT
|
|
>.
|
|
If there is another MySQL server running on the system that you
|
|
do not own, use the -P option to specify a TCP port that is not
|
|
in use.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN920"
|
|
>2.6.2.1.3. Starting the Server</A
|
|
></H5
|
|
><P
|
|
>After your mysqld program is built and any .my.cnf file is
|
|
in place, you must initialize the databases (ONCE).</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> <SAMP
|
|
CLASS="prompt"
|
|
>bash$</SAMP
|
|
>
|
|
<B
|
|
CLASS="command"
|
|
>mysql_install_db</B
|
|
>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>Then start the daemon with</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> <SAMP
|
|
CLASS="prompt"
|
|
>bash$</SAMP
|
|
>
|
|
<B
|
|
CLASS="command"
|
|
>safe_mysql &</B
|
|
>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>After you start mysqld the first time, you then connect to
|
|
it as "root" and <B
|
|
CLASS="command"
|
|
>GRANT</B
|
|
> permissions to other
|
|
users. (Again, the MySQL root account has nothing to do with
|
|
the *NIX root account.)</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>You will need to start the daemons yourself. You can either
|
|
ask your system administrator to add them to system startup files, or
|
|
add a crontab entry that runs a script to check on these daemons
|
|
and restart them if needed.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Do NOT run daemons or other services on a server without first
|
|
consulting your system administrator! Daemons use up system resources
|
|
and running one may be in violation of your terms of service for any
|
|
machine on which you are a user!</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN936"
|
|
>2.6.3. Perl</A
|
|
></H3
|
|
><P
|
|
> On the extremely rare chance that you don't have Perl on
|
|
the machine, you will have to build the sources
|
|
yourself. The following commands should get your system
|
|
installed with your own personal version of Perl:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> <SAMP
|
|
CLASS="prompt"
|
|
>bash$</SAMP
|
|
>
|
|
<B
|
|
CLASS="command"
|
|
>wget http://perl.org/CPAN/src/stable.tar.gz</B
|
|
>
|
|
<SAMP
|
|
CLASS="prompt"
|
|
>bash$</SAMP
|
|
>
|
|
<B
|
|
CLASS="command"
|
|
>tar zvxf stable.tar.gz</B
|
|
>
|
|
<SAMP
|
|
CLASS="prompt"
|
|
>bash$</SAMP
|
|
>
|
|
<B
|
|
CLASS="command"
|
|
>cd perl-5.8.1</B
|
|
> (or whatever the version of Perl is called)
|
|
<SAMP
|
|
CLASS="prompt"
|
|
>bash$</SAMP
|
|
>
|
|
<B
|
|
CLASS="command"
|
|
>sh Configure -de -Dprefix=/home/foo/perl</B
|
|
>
|
|
<SAMP
|
|
CLASS="prompt"
|
|
>bash$</SAMP
|
|
>
|
|
<B
|
|
CLASS="command"
|
|
>make && make test && make install</B
|
|
>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> Once you have Perl installed into a directory (probably
|
|
in <TT
|
|
CLASS="filename"
|
|
>~/perl/bin</TT
|
|
>), you will need to
|
|
install the Perl Modules, described below.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="install-perlmodules-nonroot"
|
|
>2.6.4. Perl Modules</A
|
|
></H3
|
|
><P
|
|
> Installing the Perl modules as a non-root user is accomplished by
|
|
running the <TT
|
|
CLASS="filename"
|
|
>install-module.pl</TT
|
|
>
|
|
script. For more details on this script, see
|
|
<A
|
|
HREF="api/install-module.html"
|
|
TARGET="_top"
|
|
><TT
|
|
CLASS="filename"
|
|
>install-module.pl</TT
|
|
>
|
|
documentation</A
|
|
>
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN958"
|
|
>2.6.5. HTTP Server</A
|
|
></H3
|
|
><P
|
|
>Ideally, this also needs to be installed as root and
|
|
run under a special web server account. As long as
|
|
the web server will allow the running of *.cgi files outside of a
|
|
cgi-bin, and a way of denying web access to certain files (such as a
|
|
.htaccess file), you should be good in this department.</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN961"
|
|
>2.6.5.1. Running Apache as Non-Root</A
|
|
></H4
|
|
><P
|
|
>You can run Apache as a non-root user, but the port will need
|
|
to be set to one above 1024. If you type <B
|
|
CLASS="command"
|
|
>httpd -V</B
|
|
>,
|
|
you will get a list of the variables that your system copy of httpd
|
|
uses. One of those, namely HTTPD_ROOT, tells you where that
|
|
installation looks for its config information.</P
|
|
><P
|
|
>From there, you can copy the config files to your own home
|
|
directory to start editing. When you edit those and then use the -d
|
|
option to override the HTTPD_ROOT compiled into the web server, you
|
|
get control of your own customized web server.</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>You will need to start the daemons yourself. You can either
|
|
ask your system administrator to add them to system startup files, or
|
|
add a crontab entry that runs a script to check on these daemons
|
|
and restart them if needed.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Do NOT run daemons or other services on a server without first
|
|
consulting your system administrator! Daemons use up system resources
|
|
and running one may be in violation of your terms of service for any
|
|
machine on which you are a user!</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN970"
|
|
>2.6.6. Bugzilla</A
|
|
></H3
|
|
><P
|
|
> When you run <B
|
|
CLASS="command"
|
|
>./checksetup.pl</B
|
|
> to create
|
|
the <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
> file, it will list the Perl
|
|
modules it finds. If one is missing, go back and double-check the
|
|
module installation from <A
|
|
HREF="#install-perlmodules-nonroot"
|
|
>Section 2.6.4</A
|
|
>,
|
|
then delete the <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
> file and try again.
|
|
</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>One option in <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
> you
|
|
might have problems with is the web server group. If you can't
|
|
successfully browse to the <TT
|
|
CLASS="filename"
|
|
>index.cgi</TT
|
|
> (like
|
|
a Forbidden error), you may have to relax your permissions,
|
|
and blank out the web server group. Of course, this may pose
|
|
as a security risk. Having a properly jailed shell and/or
|
|
limited access to shell accounts may lessen the security risk,
|
|
but use at your own risk.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="suexec"
|
|
>2.6.6.1. suexec or shared hosting</A
|
|
></H4
|
|
><P
|
|
>If you are running on a system that uses suexec (most shared
|
|
hosting environments do this), you will need to set the
|
|
<EM
|
|
>webservergroup</EM
|
|
> value in <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
>
|
|
to match <EM
|
|
>your</EM
|
|
> primary group, rather than the one
|
|
the web server runs under. You will need to run the following
|
|
shell commands after running <B
|
|
CLASS="command"
|
|
>./checksetup.pl</B
|
|
>,
|
|
every time you run it (or modify <TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
>
|
|
to do them for you via the system() command).
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> for i in docs graphs images js skins; do find $i -type d -exec chmod o+rx {} \; ; done
|
|
for i in jpg gif css js png html rdf xul; do find . -name \*.$i -exec chmod o+r {} \; ; done
|
|
find . -name .htaccess -exec chmod o+r {} \;
|
|
chmod o+x . data data/webdot</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
Pay particular attention to the number of semicolons and dots.
|
|
They are all important. A future version of Bugzilla will
|
|
hopefully be able to do this for you out of the box.</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="upgrade"
|
|
>2.7. Upgrading to New Releases</A
|
|
></H2
|
|
><P
|
|
>Upgrading to new Bugzilla releases is very simple. There is
|
|
a script included with Bugzilla that will automatically
|
|
do all of the database migration for you.</P
|
|
><P
|
|
>The following sections explain how to upgrade from one
|
|
version of Bugzilla to another. Whether you are upgrading
|
|
from one bug-fix version to another (such as 3.0.1 to 3.0.2)
|
|
or from one major version to another (such as from 3.0 to 3.2),
|
|
the instructions are always the same.</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Any examples in the following sections are written as though the
|
|
user were updating to version 2.22.1, but the procedures are the
|
|
same no matter what version you're updating to. Also, in the
|
|
examples, the user's Bugzilla installation is found at
|
|
<TT
|
|
CLASS="filename"
|
|
>/var/www/html/bugzilla</TT
|
|
>. If that is not the
|
|
same as the location of your Bugzilla installation, simply
|
|
substitute the proper paths where appropriate.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="upgrade-before"
|
|
>2.7.1. Before You Upgrade</A
|
|
></H3
|
|
><P
|
|
>Before you start your upgrade, there are a few important
|
|
steps to take:</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> Read the <A
|
|
HREF="http://www.bugzilla.org/releases/"
|
|
TARGET="_top"
|
|
>Release
|
|
Notes</A
|
|
> of the version you're upgrading to,
|
|
particularly the "Notes for Upgraders" section.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> View the Sanity Check (<A
|
|
HREF="#sanitycheck"
|
|
>Section 3.16</A
|
|
>) page
|
|
on your installation before upgrading. Attempt to fix all warnings
|
|
that the page produces before you go any further, or you may
|
|
experience problems during your upgrade.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Shut down your Bugzilla installation by putting some HTML or
|
|
text in the shutdownhtml parameter
|
|
(see <A
|
|
HREF="#parameters"
|
|
>Section 3.1</A
|
|
>).
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Make a backup of the Bugzilla database.
|
|
<EM
|
|
>THIS IS VERY IMPORTANT</EM
|
|
>. If
|
|
anything goes wrong during the upgrade, your installation
|
|
can be corrupted beyond recovery. Having a backup keeps you safe.
|
|
</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Upgrading is a one-way process. You cannot "downgrade" an
|
|
upgraded Bugzilla. If you wish to revert to the old Bugzilla
|
|
version for any reason, you will have to restore your database
|
|
from this backup.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
>Here are some sample commands you could use to backup
|
|
your database, depending on what database system you're
|
|
using. You may have to modify these commands for your
|
|
particular setup.</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
>MySQL:</DT
|
|
><DD
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>mysqldump --opt -u bugs -p bugs > bugs.sql</B
|
|
>
|
|
</P
|
|
></DD
|
|
><DT
|
|
>PostgreSQL:</DT
|
|
><DD
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>pg_dump --no-privileges --no-owner -h localhost -U bugs
|
|
> bugs.sql</B
|
|
>
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="upgrade-files"
|
|
>2.7.2. Getting The New Bugzilla</A
|
|
></H3
|
|
><P
|
|
>There are three ways to get the new version of Bugzilla.
|
|
We'll list them here briefly and then explain them
|
|
more later.</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
>CVS (<A
|
|
HREF="#upgrade-cvs"
|
|
>Section 2.7.2.2</A
|
|
>)</DT
|
|
><DD
|
|
><P
|
|
> If have <B
|
|
CLASS="command"
|
|
>cvs</B
|
|
> installed on your machine
|
|
and you have Internet access, this is the easiest way to
|
|
upgrade, particularly if you have made modifications
|
|
to the code or templates of Bugzilla.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Download the tarball (<A
|
|
HREF="#upgrade-tarball"
|
|
>Section 2.7.2.3</A
|
|
>)</DT
|
|
><DD
|
|
><P
|
|
> This is a very simple way to upgrade, and good if you
|
|
haven't made many (or any) modifications to the code or
|
|
templates of your Bugzilla.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Patches (<A
|
|
HREF="#upgrade-patches"
|
|
>Section 2.7.2.4</A
|
|
>)</DT
|
|
><DD
|
|
><P
|
|
> If you have made modifications to your Bugzilla, and
|
|
you don't have Internet access or you don't want to use
|
|
cvs, then this is the best way to upgrade.
|
|
</P
|
|
><P
|
|
> You can only do minor upgrades (such as 3.0 to 3.0.1 or
|
|
3.0.1 to 3.0.2) with patches.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="upgrade-modified"
|
|
>2.7.2.1. If you have modified your Bugzilla</A
|
|
></H4
|
|
><P
|
|
> If you have modified the code or templates of your Bugzilla,
|
|
then upgrading requires a bit more thought and effort.
|
|
A discussion of the various methods of updating compared with
|
|
degree and methods of local customization can be found in
|
|
<A
|
|
HREF="#template-method"
|
|
>Section 6.3.2</A
|
|
>.
|
|
</P
|
|
><P
|
|
> The larger the jump you are trying to make, the more difficult it
|
|
is going to be to upgrade if you have made local customizations.
|
|
Upgrading from 3.0 to 3.0.1 should be fairly painless even if
|
|
you are heavily customized, but going from 2.18 to 3.0 is going
|
|
to mean a fair bit of work re-writing your local changes to use
|
|
the new files, logic, templates, etc. If you have done no local
|
|
changes at all, however, then upgrading should be approximately
|
|
the same amount of work regardless of how long it has been since
|
|
your version was released.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="upgrade-cvs"
|
|
>2.7.2.2. Upgrading using CVS</A
|
|
></H4
|
|
><P
|
|
> This requires that you have cvs installed (most Unix machines do),
|
|
and requires that you are able to access cvs-mirror.mozilla.org
|
|
on port 2401, which may not be an option if you are behind a
|
|
highly restrictive firewall or don't have Internet access.
|
|
</P
|
|
><P
|
|
> The following shows the sequence of commands needed to update a
|
|
Bugzilla installation via CVS, and a typical series of results.
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> bash$ <B
|
|
CLASS="command"
|
|
>cd /var/www/html/bugzilla</B
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>cvs login</B
|
|
>
|
|
Logging in to :pserver:anonymous@cvs-mirror.mozilla.org:2401/cvsroot
|
|
CVS password: <EM
|
|
>('anonymous', or just leave it blank)</EM
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>cvs -q update -r BUGZILLA-2_22_1 -dP</B
|
|
>
|
|
P checksetup.pl
|
|
P collectstats.pl
|
|
P docs/rel_notes.txt
|
|
P template/en/default/list/quips.html.tmpl
|
|
<EM
|
|
>(etc.)</EM
|
|
>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="caution"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="caution"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/caution.gif"
|
|
HSPACE="5"
|
|
ALT="Caution"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If a line in the output from <B
|
|
CLASS="command"
|
|
>cvs update</B
|
|
> begins
|
|
with a <SAMP
|
|
CLASS="computeroutput"
|
|
>C</SAMP
|
|
>, then that represents a
|
|
file with local changes that CVS was unable to properly merge. You
|
|
need to resolve these conflicts manually before Bugzilla (or at
|
|
least the portion using that file) will be usable.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="upgrade-tarball"
|
|
>2.7.2.3. Upgrading using the tarball</A
|
|
></H4
|
|
><P
|
|
> If you are unable (or unwilling) to use CVS, another option that's
|
|
always available is to obtain the latest tarball from the <A
|
|
HREF="http://www.bugzilla.org/download/"
|
|
TARGET="_top"
|
|
>Download Page</A
|
|
> and
|
|
create a new Bugzilla installation from that.
|
|
</P
|
|
><P
|
|
> This sequence of commands shows how to get the tarball from the
|
|
command-line; it is also possible to download it from the site
|
|
directly in a web browser. If you go that route, save the file
|
|
to the <TT
|
|
CLASS="filename"
|
|
>/var/www/html</TT
|
|
>
|
|
directory (or its equivalent, if you use something else) and
|
|
omit the first three lines of the example.
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> bash$ <B
|
|
CLASS="command"
|
|
>cd /var/www/html</B
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-2.22.1.tar.gz</B
|
|
>
|
|
<EM
|
|
>(Output omitted)</EM
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>tar xzvf bugzilla-2.22.1.tar.gz</B
|
|
>
|
|
bugzilla-2.22.1/
|
|
bugzilla-2.22.1/.cvsignore
|
|
<EM
|
|
>(Output truncated)</EM
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>cd bugzilla-2.22.1</B
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>cp ../bugzilla/localconfig* .</B
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>cp -r ../bugzilla/data .</B
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>cd ..</B
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>mv bugzilla bugzilla.old</B
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>mv bugzilla-2.22.1 bugzilla</B
|
|
>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> The <B
|
|
CLASS="command"
|
|
>cp</B
|
|
> commands both end with periods which
|
|
is a very important detail--it means that the destination
|
|
directory is the current working directory.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> This upgrade method will give you a clean install of Bugzilla.
|
|
That's fine if you don't have any local customizations that you
|
|
want to maintain. If you do have customizations, then you will
|
|
need to reapply them by hand to the appropriate files.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="upgrade-patches"
|
|
>2.7.2.4. Upgrading using patches</A
|
|
></H4
|
|
><P
|
|
> A patch is a collection of all the bug fixes that have been made
|
|
since the last bug-fix release.
|
|
</P
|
|
><P
|
|
> If you are doing a bug-fix upgrade—that is, one where only the
|
|
last number of the revision changes, such as from 2.22 to
|
|
2.22.1—then you have the option of obtaining and applying a
|
|
patch file from the <A
|
|
HREF="http://www.bugzilla.org/download/"
|
|
TARGET="_top"
|
|
>Download Page</A
|
|
>.
|
|
</P
|
|
><P
|
|
> As above, this example starts with obtaining the file via the
|
|
command line. If you have already downloaded it, you can omit the
|
|
first two commands.
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> bash$ <B
|
|
CLASS="command"
|
|
>cd /var/www/html/bugzilla</B
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-2.22-to-2.22.1.diff.gz</B
|
|
>
|
|
<EM
|
|
>(Output omitted)</EM
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>gunzip bugzilla-2.22-to-2.22.1.diff.gz</B
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>patch -p1 < bugzilla-2.22-to-2.22.1.diff</B
|
|
>
|
|
patching file checksetup.pl
|
|
patching file collectstats.pl
|
|
<EM
|
|
>(etc.)</EM
|
|
>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Be aware that upgrading from a patch file does not change the
|
|
entries in your <TT
|
|
CLASS="filename"
|
|
>CVS</TT
|
|
> directory.
|
|
This could make it more difficult to upgrade using CVS
|
|
(<A
|
|
HREF="#upgrade-cvs"
|
|
>Section 2.7.2.2</A
|
|
>) in the future.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="upgrade-completion"
|
|
>2.7.3. Completing Your Upgrade</A
|
|
></H3
|
|
><P
|
|
> Now that you have the new Bugzilla code, there are a few final
|
|
steps to complete your upgrade.
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> If your new Bugzilla installation is in a different
|
|
directory or on a different machine than your old Bugzilla
|
|
installation, make sure that you have copied the
|
|
<TT
|
|
CLASS="filename"
|
|
>data</TT
|
|
> directory and the
|
|
<TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
> file from your old Bugzilla
|
|
installation. (If you followed the tarball instructions
|
|
above, this has already happened.)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> If this is a major update, check that the configuration
|
|
(<A
|
|
HREF="#configuration"
|
|
>Section 2.2</A
|
|
>) for your new Bugzilla is
|
|
up-to-date. Sometimes the configuration requirements change
|
|
between major versions.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> If you didn't do it as part of the above configuration step,
|
|
now you need to run <B
|
|
CLASS="command"
|
|
>checksetup.pl</B
|
|
>, which
|
|
will do everything required to convert your existing database
|
|
and settings for the new version:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> bash$ <B
|
|
CLASS="command"
|
|
>cd /var/www/html/bugzilla</B
|
|
>
|
|
bash$ <B
|
|
CLASS="command"
|
|
>./checksetup.pl</B
|
|
>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> The period at the beginning of the command
|
|
<B
|
|
CLASS="command"
|
|
>./checksetup.pl</B
|
|
> is important and can not
|
|
be omitted.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="caution"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="caution"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/caution.gif"
|
|
HSPACE="5"
|
|
ALT="Caution"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If this is a major upgrade (say, 2.22 to 3.0 or similar),
|
|
running <B
|
|
CLASS="command"
|
|
>checksetup.pl</B
|
|
> on a large
|
|
installation (75,000 or more bugs) can take a long time,
|
|
possibly several hours.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Clear any HTML or text that you put into the shutdownhtml
|
|
parameter, to re-activate Bugzilla.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> View the Sanity Check (<A
|
|
HREF="#sanitycheck"
|
|
>Section 3.16</A
|
|
>) page in your
|
|
upgraded Bugzilla.
|
|
</P
|
|
><P
|
|
> It is recommended that, if possible, you fix any problems
|
|
you see, immediately. Failure to do this may mean that Bugzilla
|
|
will not work correctly. Be aware that if the sanity check page
|
|
contains more errors after an upgrade, it doesn't necessarily
|
|
mean there are more errors in your database than there were
|
|
before, as additional tests are added to the sanity check over
|
|
time, and it is possible that those errors weren't being
|
|
checked for in the old version.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="upgrade-notifications"
|
|
>2.7.4. Automatic Notifications of New Releases</A
|
|
></H3
|
|
><P
|
|
> Bugzilla 3.0 introduced the ability to automatically notify
|
|
administrators when new releases are available, based on the
|
|
<TT
|
|
CLASS="literal"
|
|
>upgrade_notification</TT
|
|
> parameter, see
|
|
<A
|
|
HREF="#parameters"
|
|
>Section 3.1</A
|
|
>. Administrators will see these
|
|
notifications when they access the <TT
|
|
CLASS="filename"
|
|
>index.cgi</TT
|
|
>
|
|
page, i.e. generally when logging in. Bugzilla will check once per
|
|
day for new releases, unless the parameter is set to
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"disabled"</SPAN
|
|
>. If you are behind a proxy, you may have to set
|
|
the <TT
|
|
CLASS="literal"
|
|
>proxy_url</TT
|
|
> parameter accordingly. If the proxy
|
|
requires authentication, use the
|
|
<TT
|
|
CLASS="literal"
|
|
>http://user:pass@proxy_url/</TT
|
|
> syntax.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="chapter"
|
|
><HR><H1
|
|
><A
|
|
NAME="administration"
|
|
></A
|
|
>Chapter 3. Administering Bugzilla</H1
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="parameters"
|
|
>3.1. Bugzilla Configuration</A
|
|
></H2
|
|
><P
|
|
> Bugzilla is configured by changing various parameters, accessed
|
|
from the "Parameters" link in the Administration page (the
|
|
Administration page can be found by clicking the "Administration"
|
|
link in the footer). The parameters are divided into several categories,
|
|
accessed via the menu on the left. Following is a description of the
|
|
different categories and important parameters within those categories.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-requiredsettings"
|
|
>3.1.1. Required Settings</A
|
|
></H3
|
|
><P
|
|
> The core required parameters for any Bugzilla installation are set
|
|
here. These parameters must be set before a new Bugzilla installation
|
|
can be used. Administrators should review this list before
|
|
deploying a new Bugzilla installation.
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
>maintainer</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Email address of the person
|
|
responsible for maintaining this Bugzilla installation.
|
|
The address need not be that of a valid Bugzilla account.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>urlbase</DT
|
|
><DD
|
|
><P
|
|
> Defines the fully qualified domain name and web
|
|
server path to this Bugzilla installation.
|
|
</P
|
|
><P
|
|
> For example, if the Bugzilla query page is
|
|
<TT
|
|
CLASS="filename"
|
|
>http://www.foo.com/bugzilla/query.cgi</TT
|
|
>,
|
|
the <SPAN
|
|
CLASS="QUOTE"
|
|
>"urlbase"</SPAN
|
|
> should be set
|
|
to <TT
|
|
CLASS="filename"
|
|
>http://www.foo.com/bugzilla/</TT
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>docs_urlbase</DT
|
|
><DD
|
|
><P
|
|
> Defines path to the Bugzilla documentation. This can be a fully
|
|
qualified domain name, or a path relative to "urlbase".
|
|
</P
|
|
><P
|
|
> For example, if the "Bugzilla Configuration" page
|
|
of the documentation is
|
|
<TT
|
|
CLASS="filename"
|
|
>http://www.foo.com/bugzilla/docs/html/parameters.html</TT
|
|
>,
|
|
set the <SPAN
|
|
CLASS="QUOTE"
|
|
>"docs_urlbase"</SPAN
|
|
>
|
|
to <TT
|
|
CLASS="filename"
|
|
>http://www.foo.com/bugzilla/docs/html/</TT
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>sslbase</DT
|
|
><DD
|
|
><P
|
|
> Defines the fully qualified domain name and web
|
|
server path for HTTPS (SSL) connections to this Bugzilla installation.
|
|
</P
|
|
><P
|
|
> For example, if the Bugzilla main page is
|
|
<TT
|
|
CLASS="filename"
|
|
>https://www.foo.com/bugzilla/index.cgi</TT
|
|
>,
|
|
the <SPAN
|
|
CLASS="QUOTE"
|
|
>"sslbase"</SPAN
|
|
> should be set
|
|
to <TT
|
|
CLASS="filename"
|
|
>https://www.foo.com/bugzilla/</TT
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>ssl_redirect</DT
|
|
><DD
|
|
><P
|
|
> If enabled, Bugzilla will force HTTPS (SSL) connections, by
|
|
automatically redirecting any users who try to use a non-SSL
|
|
connection.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>cookiedomain</DT
|
|
><DD
|
|
><P
|
|
> Defines the domain for Bugzilla cookies. This is typically left blank.
|
|
If there are multiple hostnames that point to the same webserver, which
|
|
require the same cookie, then this parameter can be utilized. For
|
|
example, If your website is at
|
|
<TT
|
|
CLASS="filename"
|
|
>https://www.foo.com/</TT
|
|
>, setting this to
|
|
<TT
|
|
CLASS="filename"
|
|
>.foo.com/</TT
|
|
> will also allow
|
|
<TT
|
|
CLASS="filename"
|
|
>bar.foo.com/</TT
|
|
> to access Bugzilla cookies.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>cookiepath</DT
|
|
><DD
|
|
><P
|
|
> Defines a path, relative to the web server root, that Bugzilla
|
|
cookies will be restricted to. For example, if the
|
|
<B
|
|
CLASS="command"
|
|
>urlbase</B
|
|
> is set to
|
|
<TT
|
|
CLASS="filename"
|
|
>http://www.foo.com/bugzilla/</TT
|
|
>, the
|
|
<B
|
|
CLASS="command"
|
|
>cookiepath</B
|
|
> should be set to
|
|
<TT
|
|
CLASS="filename"
|
|
>/bugzilla/</TT
|
|
>. Setting it to "/" will allow all sites
|
|
served by this web server or virtual host to read Bugzilla cookies.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>utf8</DT
|
|
><DD
|
|
><P
|
|
> Determines whether to use UTF-8 (Unicode) encoding for all text in
|
|
Bugzilla. New installations should set this to true to avoid character
|
|
encoding problems. Existing databases should set this to true only
|
|
after the data has been converted from existing legacy character
|
|
encoding to UTF-8, using the
|
|
<TT
|
|
CLASS="filename"
|
|
>contrib/recode.pl</TT
|
|
> script.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If you turn this parameter from "off" to "on", you must re-run
|
|
<TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> immediately afterward.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DD
|
|
><DT
|
|
>shutdownhtml</DT
|
|
><DD
|
|
><P
|
|
> If there is any text in this field, this Bugzilla installation will
|
|
be completely disabled and this text will appear instead of all
|
|
Bugzilla pages for all users, including Admins. Used in the event
|
|
of site maintenance or outage situations.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Although regular log-in capability is disabled while
|
|
<B
|
|
CLASS="command"
|
|
>shutdownhtml</B
|
|
>
|
|
is enabled, safeguards are in place to protect the unfortunate
|
|
admin who loses connection to Bugzilla. Should this happen to you,
|
|
go directly to the <TT
|
|
CLASS="filename"
|
|
>editparams.cgi</TT
|
|
> (by typing
|
|
the URL in manually, if necessary). Doing this will prompt you to
|
|
log in, and your name/password will be accepted here (but nowhere
|
|
else).
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DD
|
|
><DT
|
|
>announcehtml</DT
|
|
><DD
|
|
><P
|
|
> Any text in this field will be displayed at the top of every HTML
|
|
page in this Bugzilla installation. The text is not wrapped in any
|
|
tags. For best results, wrap the text in a <SPAN
|
|
CLASS="QUOTE"
|
|
>"<div>"</SPAN
|
|
>
|
|
tag. Any style attributes from the CSS can be applied. For example,
|
|
to make the text green inside of a red box, add <SPAN
|
|
CLASS="QUOTE"
|
|
>"id=message"</SPAN
|
|
>
|
|
to the <SPAN
|
|
CLASS="QUOTE"
|
|
>"<div>"</SPAN
|
|
> tag.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>proxy_url</DT
|
|
><DD
|
|
><P
|
|
> If this Bugzilla installation is behind a proxy, enter the proxy
|
|
information here to enable Bugzilla to access the Internet. Bugzilla
|
|
requires Internet access to utilize the
|
|
<B
|
|
CLASS="command"
|
|
>upgrade_notification</B
|
|
> parameter (below). If the
|
|
proxy requires authentication, use the syntax:
|
|
<TT
|
|
CLASS="filename"
|
|
>http://user:pass@proxy_url/</TT
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>upgrade_notification</DT
|
|
><DD
|
|
><P
|
|
> Enable or disable a notification on the homepage of this Bugzilla
|
|
installation when a newer version of Bugzilla is available. This
|
|
notification is only visible to administrators. Choose "disabled",
|
|
to turn off the notification. Otherwise, choose which version of
|
|
Bugzilla you want to be notified about: "development_snapshot" is the
|
|
latest release on the trunk; "latest_stable_release" is the most
|
|
recent release available on the most recent stable branch;
|
|
"stable_branch_release" the most recent release on the branch
|
|
this installation is based on.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-admin-policies"
|
|
>3.1.2. Administrative Policies</A
|
|
></H3
|
|
><P
|
|
> This page contains parameters for basic administrative functions.
|
|
Options include whether to allow the deletion of bugs and users,
|
|
and whether to allow users to change their email address.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-user-authentication"
|
|
>3.1.3. User Authentication</A
|
|
></H3
|
|
><P
|
|
> This page contains the settings that control how this Bugzilla
|
|
installation will do its authentication. Choose what authentication
|
|
mechanism to use (the Bugzilla database, or an external source such
|
|
as LDAP), and set basic behavioral parameters. For example, choose
|
|
whether to require users to login to browse bugs, the management
|
|
of authentication cookies, and the regular expression used to
|
|
validate email addresses. Some parameters are highlighted below.
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
>emailregexp</DT
|
|
><DD
|
|
><P
|
|
> Defines the regular expression used to validate email addresses
|
|
used for login names. The default attempts to match fully
|
|
qualified email addresses (i.e. 'user@example.com'). Some
|
|
Bugzilla installations allow only local user names (i.e 'user'
|
|
instead of 'user@example.com'). In that case, the
|
|
<B
|
|
CLASS="command"
|
|
>emailsuffix</B
|
|
> parameter should be used to define
|
|
the email domain.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>emailsuffix</DT
|
|
><DD
|
|
><P
|
|
> This string is appended to login names when actually sending
|
|
email to a user. For example,
|
|
If <B
|
|
CLASS="command"
|
|
>emailregexp</B
|
|
> has been set to allow
|
|
local usernames,
|
|
then this parameter would contain the email domain for all users
|
|
(i.e. '@example.com').
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-attachments"
|
|
>3.1.4. Attachments</A
|
|
></H3
|
|
><P
|
|
> This page allows for setting restrictions and other parameters
|
|
regarding attachments to bugs. For example, control size limitations
|
|
and whether to allow pointing to external files via a URI.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-bug-change-policies"
|
|
>3.1.5. Bug Change Policies</A
|
|
></H3
|
|
><P
|
|
> Set policy on default behavior for bug change events. For example,
|
|
choose which status to set a bug to when it is marked as a duplicate,
|
|
and choose whether to allow bug reporters to set the priority or
|
|
target milestone. Also allows for configuration of what changes
|
|
should require the user to make a comment, described below.
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
>commenton*</DT
|
|
><DD
|
|
><P
|
|
> All these fields allow you to dictate what changes can pass
|
|
without comment, and which must have a comment from the
|
|
person who changed them. Often, administrators will allow
|
|
users to add themselves to the CC list, accept bugs, or
|
|
change the Status Whiteboard without adding a comment as to
|
|
their reasons for the change, yet require that most other
|
|
changes come with an explanation.
|
|
</P
|
|
><P
|
|
> Set the "commenton" options according to your site policy. It
|
|
is a wise idea to require comments when users resolve, reassign, or
|
|
reopen bugs at the very least.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> It is generally far better to require a developer comment
|
|
when resolving bugs than not. Few things are more annoying to bug
|
|
database users than having a developer mark a bug "fixed" without
|
|
any comment as to what the fix was (or even that it was truly
|
|
fixed!)
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DD
|
|
><DT
|
|
>noresolveonopenblockers</DT
|
|
><DD
|
|
><P
|
|
> This option will prevent users from resolving bugs as FIXED if
|
|
they have unresolved dependencies. Only the FIXED resolution
|
|
is affected. Users will be still able to resolve bugs to
|
|
resolutions other than FIXED if they have unresolved dependent
|
|
bugs.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-bugfields"
|
|
>3.1.6. Bug Fields</A
|
|
></H3
|
|
><P
|
|
> The parameters in this section determine the default settings of
|
|
several Bugzilla fields for new bugs, and also control whether
|
|
certain fields are used. For example, choose whether to use the
|
|
"target milestone" field or the "status whiteboard" field.
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
>useqacontact</DT
|
|
><DD
|
|
><P
|
|
> This allows you to define an email address for each component,
|
|
in addition to that of the default assignee, who will be sent
|
|
carbon copies of incoming bugs.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>usestatuswhiteboard</DT
|
|
><DD
|
|
><P
|
|
> This defines whether you wish to have a free-form, overwritable field
|
|
associated with each bug. The advantage of the Status Whiteboard is
|
|
that it can be deleted or modified with ease, and provides an
|
|
easily-searchable field for indexing some bugs that have some trait
|
|
in common.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-bugmoving"
|
|
>3.1.7. Bug Moving</A
|
|
></H3
|
|
><P
|
|
> This page controls whether this Bugzilla installation allows certain
|
|
users to move bugs to an external database. If bug moving is enabled,
|
|
there are a number of parameters that control bug moving behaviors.
|
|
For example, choose which users are allowed to move bugs, the location
|
|
of the external database, and the default product and component that
|
|
bugs moved <EM
|
|
>from</EM
|
|
> other bug databases to this
|
|
Bugzilla installation are assigned to.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-dependency-graphs"
|
|
>3.1.8. Dependency Graphs</A
|
|
></H3
|
|
><P
|
|
> This page has one parameter that sets the location of a Web Dot
|
|
server, or of the Web Dot binary on the local system, that is used
|
|
to generate dependency graphs. Web Dot is a CGI program that creates
|
|
images from <TT
|
|
CLASS="filename"
|
|
>.dot</TT
|
|
> graphic description files. If
|
|
no Web Dot server or binary is specified, then dependency graphs will
|
|
be disabled.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-group-security"
|
|
>3.1.9. Group Security</A
|
|
></H3
|
|
><P
|
|
> Bugzilla allows for the creation of different groups, with the
|
|
ability to restrict the visibility of bugs in a group to a set of
|
|
specific users. Specific products can also be associated with
|
|
groups, and users restricted to only see products in their groups.
|
|
Several parameters are described in more detail below. Most of the
|
|
configuration of groups and their relationship to products is done
|
|
on the "Groups" and "Product" pages of the "Administration" area.
|
|
The options on this page control global default behavior.
|
|
For more information on Groups and Group Security, see
|
|
<A
|
|
HREF="#groups"
|
|
>Section 3.15</A
|
|
>
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
>makeproductgroups</DT
|
|
><DD
|
|
><P
|
|
> Determines whether or not to automatically create groups
|
|
when new products are created. If this is on, the groups will be
|
|
used for querying bugs.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>usevisibilitygroups</DT
|
|
><DD
|
|
><P
|
|
> If selected, user visibility will be restricted to members of
|
|
groups, as selected in the group configuration settings.
|
|
Each user-defined group can be allowed to see members of selected
|
|
other groups.
|
|
For details on configuring groups (including the visibility
|
|
restrictions) see <A
|
|
HREF="#edit-groups"
|
|
>Section 3.15.2</A
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>querysharegroup</DT
|
|
><DD
|
|
><P
|
|
> The name of the group of users who are allowed to share saved
|
|
searches with one another. For more information on using
|
|
saved searches, see <A
|
|
HREF="#savedsearches"
|
|
>Saved Searches</A
|
|
>.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="bzldap"
|
|
>3.1.10. LDAP Authentication</A
|
|
></H3
|
|
><P
|
|
>LDAP authentication is a module for Bugzilla's plugin
|
|
authentication architecture. This page contains all the parameters
|
|
necessary to configure Bugzilla for use with LDAP authentication.
|
|
</P
|
|
><P
|
|
> The existing authentication
|
|
scheme for Bugzilla uses email addresses as the primary user ID, and a
|
|
password to authenticate that user. All places within Bugzilla that
|
|
require a user ID (e.g assigning a bug) use the email
|
|
address. The LDAP authentication builds on top of this scheme, rather
|
|
than replacing it. The initial log-in is done with a username and
|
|
password for the LDAP directory. Bugzilla tries to bind to LDAP using
|
|
those credentials and, if successful, tries to map this account to a
|
|
Bugzilla account. If an LDAP mail attribute is defined, the value of this
|
|
attribute is used, otherwise the "emailsuffix" parameter is appended to LDAP
|
|
username to form a full email address. If an account for this address
|
|
already exists in the Bugzilla installation, it will log in to that account.
|
|
If no account for that email address exists, one is created at the time
|
|
of login. (In this case, Bugzilla will attempt to use the "displayName"
|
|
or "cn" attribute to determine the user's full name.) After
|
|
authentication, all other user-related tasks are still handled by email
|
|
address, not LDAP username. For example, bugs are still assigned by
|
|
email address and users are still queried by email address.
|
|
</P
|
|
><DIV
|
|
CLASS="caution"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="caution"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/caution.gif"
|
|
HSPACE="5"
|
|
ALT="Caution"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Because the Bugzilla account is not created until the first time
|
|
a user logs in, a user who has not yet logged is unknown to Bugzilla.
|
|
This means they cannot be used as an assignee or QA contact (default or
|
|
otherwise), added to any CC list, or any other such operation. One
|
|
possible workaround is the <TT
|
|
CLASS="filename"
|
|
>bugzilla_ldapsync.rb</TT
|
|
>
|
|
script in the
|
|
<A
|
|
HREF="#gloss-contrib"
|
|
><I
|
|
CLASS="glossterm"
|
|
> <TT
|
|
CLASS="filename"
|
|
>contrib</TT
|
|
></I
|
|
></A
|
|
>
|
|
directory. Another possible solution is fixing
|
|
<A
|
|
HREF="https://bugzilla.mozilla.org/show_bug.cgi?id=201069"
|
|
TARGET="_top"
|
|
>bug
|
|
201069</A
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
>Parameters required to use LDAP Authentication:</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="param-user_verify_class_for_ldap"
|
|
></A
|
|
>user_verify_class</DT
|
|
><DD
|
|
><P
|
|
>If you want to list <SPAN
|
|
CLASS="QUOTE"
|
|
>"LDAP"</SPAN
|
|
> here,
|
|
make sure to have set up the other parameters listed below.
|
|
Unless you have other (working) authentication methods listed as
|
|
well, you may otherwise not be able to log back in to Bugzilla once
|
|
you log out.
|
|
If this happens to you, you will need to manually edit
|
|
<TT
|
|
CLASS="filename"
|
|
>data/params</TT
|
|
> and set user_verify_class to
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"DB"</SPAN
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="param-LDAPserver"
|
|
></A
|
|
>LDAPserver</DT
|
|
><DD
|
|
><P
|
|
>This parameter should be set to the name (and optionally the
|
|
port) of your LDAP server. If no port is specified, it assumes
|
|
the default LDAP port of 389.
|
|
</P
|
|
><P
|
|
>For example: <SPAN
|
|
CLASS="QUOTE"
|
|
>"ldap.company.com"</SPAN
|
|
>
|
|
or <SPAN
|
|
CLASS="QUOTE"
|
|
>"ldap.company.com:3268"</SPAN
|
|
>
|
|
</P
|
|
><P
|
|
>You can also specify a LDAP URI, so as to use other
|
|
protocols, such as LDAPS or LDAPI. If port was not specified in
|
|
the URI, the default is either 389 or 636 for 'LDAP' and 'LDAPS'
|
|
schemes respectively.
|
|
</P
|
|
><DIV
|
|
CLASS="tip"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="tip"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> In order to use SSL with LDAP, specify a URI with "ldaps://".
|
|
This will force the use of SSL over port 636.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
>For example, normal LDAP:
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"ldap://ldap.company.com"</SPAN
|
|
>, LDAP over SSL:
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"ldaps://ldap.company.com"</SPAN
|
|
> or LDAP over a UNIX
|
|
domain socket <SPAN
|
|
CLASS="QUOTE"
|
|
>"ldapi://%2fvar%2flib%2fldap_sock"</SPAN
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="param-LDAPbinddn"
|
|
></A
|
|
>LDAPbinddn [Optional]</DT
|
|
><DD
|
|
><P
|
|
>Some LDAP servers will not allow an anonymous bind to search
|
|
the directory. If this is the case with your configuration you
|
|
should set the LDAPbinddn parameter to the user account Bugzilla
|
|
should use instead of the anonymous bind.
|
|
</P
|
|
><P
|
|
>Ex. <SPAN
|
|
CLASS="QUOTE"
|
|
>"cn=default,cn=user:password"</SPAN
|
|
></P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="param-LDAPBaseDN"
|
|
></A
|
|
>LDAPBaseDN</DT
|
|
><DD
|
|
><P
|
|
>The LDAPBaseDN parameter should be set to the location in
|
|
your LDAP tree that you would like to search for email addresses.
|
|
Your uids should be unique under the DN specified here.
|
|
</P
|
|
><P
|
|
>Ex. <SPAN
|
|
CLASS="QUOTE"
|
|
>"ou=People,o=Company"</SPAN
|
|
></P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="param-LDAPuidattribute"
|
|
></A
|
|
>LDAPuidattribute</DT
|
|
><DD
|
|
><P
|
|
>The LDAPuidattribute parameter should be set to the attribute
|
|
which contains the unique UID of your users. The value retrieved
|
|
from this attribute will be used when attempting to bind as the
|
|
user to confirm their password.
|
|
</P
|
|
><P
|
|
>Ex. <SPAN
|
|
CLASS="QUOTE"
|
|
>"uid"</SPAN
|
|
></P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="param-LDAPmailattribute"
|
|
></A
|
|
>LDAPmailattribute</DT
|
|
><DD
|
|
><P
|
|
>The LDAPmailattribute parameter should be the name of the
|
|
attribute which contains the email address your users will enter
|
|
into the Bugzilla login boxes.
|
|
</P
|
|
><P
|
|
>Ex. <SPAN
|
|
CLASS="QUOTE"
|
|
>"mail"</SPAN
|
|
></P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="bzradius"
|
|
>3.1.11. RADIUS Authentication</A
|
|
></H3
|
|
><P
|
|
> RADIUS authentication is a module for Bugzilla's plugin
|
|
authentication architecture. This page contains all the parameters
|
|
necessary for configuring Bugzilla to use RADIUS authentication.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Most caveats that apply to LDAP authentication apply to RADIUS
|
|
authentication as well. See <A
|
|
HREF="#bzldap"
|
|
>Section 3.1.10</A
|
|
> for details.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
>Parameters required to use RADIUS Authentication:</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="param-user_verify_class_for_radius"
|
|
></A
|
|
>user_verify_class</DT
|
|
><DD
|
|
><P
|
|
>If you want to list <SPAN
|
|
CLASS="QUOTE"
|
|
>"RADIUS"</SPAN
|
|
> here,
|
|
make sure to have set up the other parameters listed below.
|
|
Unless you have other (working) authentication methods listed as
|
|
well, you may otherwise not be able to log back in to Bugzilla once
|
|
you log out.
|
|
If this happens to you, you will need to manually edit
|
|
<TT
|
|
CLASS="filename"
|
|
>data/params</TT
|
|
> and set user_verify_class to
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"DB"</SPAN
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="param-RADIUS_server"
|
|
></A
|
|
>RADIUS_server</DT
|
|
><DD
|
|
><P
|
|
>This parameter should be set to the name (and optionally the
|
|
port) of your RADIUS server.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="param-RADIUS_secret"
|
|
></A
|
|
>RADIUS_secret</DT
|
|
><DD
|
|
><P
|
|
>This parameter should be set to the RADIUS server's secret.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="param-RADIUS_email_suffix"
|
|
></A
|
|
>RADIUS_email_suffix</DT
|
|
><DD
|
|
><P
|
|
>Bugzilla needs an e-mail address for each user account.
|
|
Therefore, it needs to determine the e-mail address corresponding
|
|
to a RADIUS user.
|
|
Bugzilla offers only a simple way to do this: it can concatenate
|
|
a suffix to the RADIUS user name to convert it into an e-mail
|
|
address.
|
|
You can specify this suffix in the RADIUS_email_suffix parameter.
|
|
</P
|
|
><P
|
|
>If this simple solution does not work for you, you'll
|
|
probably need to modify
|
|
<TT
|
|
CLASS="filename"
|
|
>Bugzilla/Auth/Verify/RADIUS.pm</TT
|
|
> to match your
|
|
requirements.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-email"
|
|
>3.1.12. Email</A
|
|
></H3
|
|
><P
|
|
> This page contains all of the parameters for configuring how
|
|
Bugzilla deals with the email notifications it sends. See below
|
|
for a summary of important options.
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
>mail_delivery_method</DT
|
|
><DD
|
|
><P
|
|
> This is used to specify how email is sent, or if it is sent at
|
|
all. There are several options included for different MTAs,
|
|
along with two additional options that disable email sending.
|
|
"Test" does not send mail, but instead saves it in
|
|
<TT
|
|
CLASS="filename"
|
|
>data/mailer.testfile</TT
|
|
> for later review.
|
|
"None" disables email sending entirely.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>mailfrom</DT
|
|
><DD
|
|
><P
|
|
> This is the email address that will appear in the "From" field
|
|
of all emails sent by this Bugzilla installation. Some email
|
|
servers require mail to be from a valid email address, therefore
|
|
it is recommended to choose a valid email address here.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>sendmailnow</DT
|
|
><DD
|
|
><P
|
|
> When Bugzilla is using Sendmail older than 8.12, turning this option
|
|
off will improve performance by not waiting for Sendmail to actually
|
|
send mail. If Sendmail 8.12 or later is being used, there is
|
|
nothing to gain by turning this off. If another MTA is being used,
|
|
such as Postfix, then this option *must* be turned on (even if you
|
|
are using the fake sendmail executable that Postfix provides).
|
|
</P
|
|
></DD
|
|
><DT
|
|
>whinedays</DT
|
|
><DD
|
|
><P
|
|
> Set this to the number of days you want to let bugs go
|
|
in the NEW or REOPENED state before notifying people they have
|
|
untouched new bugs. If you do not plan to use this feature, simply
|
|
do not set up the whining cron job described in the installation
|
|
instructions, or set this value to "0" (never whine).
|
|
</P
|
|
></DD
|
|
><DT
|
|
>globalwatcher</DT
|
|
><DD
|
|
><P
|
|
> This allows you to define specific users who will
|
|
receive notification each time a new bug in entered, or when
|
|
an existing bug changes, according to the normal groupset
|
|
permissions. It may be useful for sending notifications to a
|
|
mailing-list, for instance.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-patchviewer"
|
|
>3.1.13. Patch Viewer</A
|
|
></H3
|
|
><P
|
|
> This page contains configuration parameters for the CVS server,
|
|
Bonsai server and LXR server that Bugzilla will use to enable the
|
|
features of the Patch Viewer. Bonsai is a tool that enables queries
|
|
to a CVS tree. LXR is a tool that can cross reference and index source
|
|
code.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-querydefaults"
|
|
>3.1.14. Query Defaults</A
|
|
></H3
|
|
><P
|
|
> This page controls the default behavior of Bugzilla in regards to
|
|
several aspects of querying bugs. Options include what the default
|
|
query options are, what the "My Bugs" page returns, whether users
|
|
can freely add bugs to the quip list, and how many duplicate bugs are
|
|
needed to add a bug to the "most frequently reported" list.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="param-shadowdatabase"
|
|
>3.1.15. Shadow Database</A
|
|
></H3
|
|
><P
|
|
> This page controls whether a shadow database is used, and all the
|
|
parameters associated with the shadow database. Versions of Bugzilla
|
|
prior to 3.2 used the MyISAM table type, which supports
|
|
only table-level write locking. With MyISAM, any time someone is making a change to
|
|
a bug, the entire table is locked until the write operation is complete.
|
|
Locking for write also blocks reads until the write is complete.
|
|
</P
|
|
><P
|
|
> The <SPAN
|
|
CLASS="QUOTE"
|
|
>"shadowdb"</SPAN
|
|
> parameter was designed to get around
|
|
this limitation. While only a single user is allowed to write to
|
|
a table at a time, reads can continue unimpeded on a read-only
|
|
shadow copy of the database.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> As of version 3.2, Bugzilla no longer uses the MyISAM table type.
|
|
Instead, InnoDB is used, which can do transaction-based locking.
|
|
Therefore, the limitations the Shadow Database feature was designed
|
|
to workaround no longer exist.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="admin-usermatching"
|
|
>3.1.16. User Matching</A
|
|
></H3
|
|
><P
|
|
> The settings on this page control how users are selected and queried
|
|
when adding a user to a bug. For example, users need to be selected
|
|
when choosing who the bug is assigned to, adding to the CC list or
|
|
selecting a QA contact. With the "usemenuforusers" parameter, it is
|
|
possible to configure Bugzilla to
|
|
display a list of users in the fields instead of an empty text field.
|
|
This should only be used in Bugzilla installations with a small number
|
|
of users. If users are selected via a text box, this page also
|
|
contains parameters for how user names can be queried and matched
|
|
when entered.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="useradmin"
|
|
>3.2. User Administration</A
|
|
></H2
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="defaultuser"
|
|
>3.2.1. Creating the Default User</A
|
|
></H3
|
|
><P
|
|
>When you first run checksetup.pl after installing Bugzilla, it
|
|
will prompt you for the administrative username (email address) and
|
|
password for this "super user". If for some reason you delete
|
|
the "super user" account, re-running checksetup.pl will again prompt
|
|
you for this username and password.</P
|
|
><DIV
|
|
CLASS="tip"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="tip"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>If you wish to add more administrative users, add them to
|
|
the "admin" group and, optionally, edit the tweakparams, editusers,
|
|
creategroups, editcomponents, and editkeywords groups to add the
|
|
entire admin group to those groups (which is the case by default).
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="manageusers"
|
|
>3.2.2. Managing Other Users</A
|
|
></H3
|
|
><DIV
|
|
CLASS="section"
|
|
><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="user-account-search"
|
|
>3.2.2.1. Searching for existing users</A
|
|
></H4
|
|
><P
|
|
> If you have <SPAN
|
|
CLASS="QUOTE"
|
|
>"editusers"</SPAN
|
|
> privileges or if you are allowed
|
|
to grant privileges for some groups, the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Users"</SPAN
|
|
> link
|
|
will appear in the Administration page.
|
|
</P
|
|
><P
|
|
> The first screen is a search form to search for existing user
|
|
accounts. You can run searches based either on the user ID, real
|
|
name or login name (i.e. the email address, or just the first part
|
|
of the email address if the "emailsuffix" parameter is set).
|
|
The search can be conducted
|
|
in different ways using the listbox to the right of the text entry
|
|
box. You can match by case-insensitive substring (the default),
|
|
regular expression, a <EM
|
|
>reverse</EM
|
|
> regular expression
|
|
match (which finds every user name which does NOT match the regular
|
|
expression), or the exact string if you know exactly who you are
|
|
looking for. The search can be restricted to users who are in a
|
|
specific group. By default, the restriction is turned off.
|
|
</P
|
|
><P
|
|
> The search returns a list of
|
|
users matching your criteria. User properties can be edited by clicking
|
|
the login name. The Account History of a user can be viewed by clicking
|
|
the "View" link in the Account History column. The Account History
|
|
displays changes that have been made to the user account, the time of
|
|
the change and the user who made the change. For example, the Account
|
|
History page will display details of when a user was added or removed
|
|
from a group.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="createnewusers"
|
|
>3.2.2.2. Creating new users</A
|
|
></H4
|
|
><DIV
|
|
CLASS="section"
|
|
><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="self-registration"
|
|
>3.2.2.2.1. Self-registration</A
|
|
></H5
|
|
><P
|
|
> By default, users can create their own user accounts by clicking the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"New Account"</SPAN
|
|
> link at the bottom of each page (assuming
|
|
they aren't logged in as someone else already). If you want to disable
|
|
this self-registration, or if you want to restrict who can create his
|
|
own user account, you have to edit the <SPAN
|
|
CLASS="QUOTE"
|
|
>"createemailregexp"</SPAN
|
|
>
|
|
parameter in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Configuration"</SPAN
|
|
> page, see
|
|
<A
|
|
HREF="#parameters"
|
|
>Section 3.1</A
|
|
>.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="user-account-creation"
|
|
>3.2.2.2.2. Accounts created by an administrator</A
|
|
></H5
|
|
><P
|
|
> Users with <SPAN
|
|
CLASS="QUOTE"
|
|
>"editusers"</SPAN
|
|
> privileges, such as administrators,
|
|
can create user accounts for other users:
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>After logging in, click the "Users" link at the footer of
|
|
the query page, and then click "Add a new user".</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Fill out the form presented. This page is self-explanatory.
|
|
When done, click "Submit".</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Adding a user this way will <EM
|
|
>not</EM
|
|
>
|
|
send an email informing them of their username and password.
|
|
While useful for creating dummy accounts (watchers which
|
|
shuttle mail to another system, for instance, or email
|
|
addresses which are a mailing list), in general it is
|
|
preferable to log out and use the <SPAN
|
|
CLASS="QUOTE"
|
|
>"New Account"</SPAN
|
|
>
|
|
button to create users, as it will pre-populate all the
|
|
required fields and also notify the user of her account name
|
|
and password.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="modifyusers"
|
|
>3.2.2.3. Modifying Users</A
|
|
></H4
|
|
><P
|
|
>Once you have found your user, you can change the following
|
|
fields:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Login Name</EM
|
|
>:
|
|
This is generally the user's full email address. However, if you
|
|
have are using the <SPAN
|
|
CLASS="QUOTE"
|
|
>"emailsuffix"</SPAN
|
|
> parameter, this may
|
|
just be the user's login name. Note that users can now change their
|
|
login names themselves (to any valid email address).
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Real Name</EM
|
|
>: The user's real name. Note that
|
|
Bugzilla does not require this to create an account.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Password</EM
|
|
>:
|
|
You can change the user's password here. Users can automatically
|
|
request a new password, so you shouldn't need to do this often.
|
|
If you want to disable an account, see Disable Text below.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Bugmail Disabled</EM
|
|
>:
|
|
Mark this checkbox to disable bugmail and whinemail completely
|
|
for this account. This checkbox replaces the data/nomail file
|
|
which existed in older versions of Bugzilla.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Disable Text</EM
|
|
>:
|
|
If you type anything in this box, including just a space, the
|
|
user is prevented from logging in, or making any changes to
|
|
bugs via the web interface.
|
|
The HTML you type in this box is presented to the user when
|
|
they attempt to perform these actions, and should explain
|
|
why the account was disabled.
|
|
</P
|
|
><P
|
|
> Users with disabled accounts will continue to receive
|
|
mail from Bugzilla; furthermore, they will not be able
|
|
to log in themselves to change their own preferences and
|
|
stop it. If you want an account (disabled or active) to
|
|
stop receiving mail, simply check the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Bugmail Disabled"</SPAN
|
|
> checkbox above.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Even users whose accounts have been disabled can still
|
|
submit bugs via the e-mail gateway, if one exists.
|
|
The e-mail gateway should <EM
|
|
>not</EM
|
|
> be
|
|
enabled for secure installations of Bugzilla.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Don't disable all the administrator accounts!
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
><groupname></EM
|
|
>:
|
|
If you have created some groups, e.g. "securitysensitive", then
|
|
checkboxes will appear here to allow you to add users to, or
|
|
remove them from, these groups.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>canconfirm</EM
|
|
>:
|
|
This field is only used if you have enabled the "unconfirmed"
|
|
status. If you enable this for a user,
|
|
that user can then move bugs from "Unconfirmed" to a "Confirmed"
|
|
status (e.g.: "New" status).</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>creategroups</EM
|
|
>:
|
|
This option will allow a user to create and destroy groups in
|
|
Bugzilla.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>editbugs</EM
|
|
>:
|
|
Unless a user has this bit set, they can only edit those bugs
|
|
for which they are the assignee or the reporter. Even if this
|
|
option is unchecked, users can still add comments to bugs.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>editcomponents</EM
|
|
>:
|
|
This flag allows a user to create new products and components,
|
|
as well as modify and destroy those that have no bugs associated
|
|
with them. If a product or component has bugs associated with it,
|
|
those bugs must be moved to a different product or component
|
|
before Bugzilla will allow them to be destroyed.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>editkeywords</EM
|
|
>:
|
|
If you use Bugzilla's keyword functionality, enabling this
|
|
feature allows a user to create and destroy keywords. As always,
|
|
the keywords for existing bugs containing the keyword the user
|
|
wishes to destroy must be changed before Bugzilla will allow it
|
|
to die.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>editusers</EM
|
|
>:
|
|
This flag allows a user to do what you're doing right now: edit
|
|
other users. This will allow those with the right to do so to
|
|
remove administrator privileges from other users or grant them to
|
|
themselves. Enable with care.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>tweakparams</EM
|
|
>:
|
|
This flag allows a user to change Bugzilla's Params
|
|
(using <TT
|
|
CLASS="filename"
|
|
>editparams.cgi</TT
|
|
>.)</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>
|
|
<EM
|
|
><productname></EM
|
|
>:
|
|
This allows an administrator to specify the products
|
|
in which a user can see bugs. If you turn on the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"makeproductgroups"</SPAN
|
|
> parameter in
|
|
the Group Security Panel in the Parameters page,
|
|
then Bugzilla creates one group per product (at the time you create
|
|
the product), and this group has exactly the same name as the
|
|
product itself. Note that for products that already exist when
|
|
the parameter is turned on, the corresponding group will not be
|
|
created. The user must still have the <SPAN
|
|
CLASS="QUOTE"
|
|
>"editbugs"</SPAN
|
|
>
|
|
privilege to edit bugs in these products.</P
|
|
></LI
|
|
></UL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="user-account-deletion"
|
|
>3.2.2.4. Deleting Users</A
|
|
></H4
|
|
><P
|
|
> If the <SPAN
|
|
CLASS="QUOTE"
|
|
>"allowuserdeletion"</SPAN
|
|
> parameter is turned on, see
|
|
<A
|
|
HREF="#parameters"
|
|
>Section 3.1</A
|
|
>, then you can also delete user accounts.
|
|
Note that this is most of the time not the best thing to do. If only
|
|
a warning in a yellow box is displayed, then the deletion is safe.
|
|
If a warning is also displayed in a red box, then you should NOT try
|
|
to delete the user account, else you will get referential integrity
|
|
problems in your database, which can lead to unexpected behavior,
|
|
such as bugs not appearing in bug lists anymore, or data displaying
|
|
incorrectly. You have been warned!
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="impersonatingusers"
|
|
>3.2.2.5. Impersonating Users</A
|
|
></H4
|
|
><P
|
|
> There may be times when an administrator would like to do something as
|
|
another user. The <B
|
|
CLASS="command"
|
|
>sudo</B
|
|
> feature may be used to do
|
|
this.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> To use the sudo feature, you must be in the
|
|
<EM
|
|
>bz_sudoers</EM
|
|
> group. By default, all
|
|
administrators are in this group.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> If you have access to this feature, you may start a session by
|
|
going to the Edit Users page, Searching for a user and clicking on
|
|
their login. You should see a link below their login name titled
|
|
"Impersonate this user". Click on the link. This will take you
|
|
to a page where you will see a description of the feature and
|
|
instructions for using it. After reading the text, simply
|
|
enter the login of the user you would like to impersonate, provide
|
|
a short message explaining why you are doing this, and press the
|
|
button.</P
|
|
><P
|
|
> As long as you are using this feature, everything you do will be done
|
|
as if you were logged in as the user you are impersonating.</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> The user you are impersonating will not be told about what you are
|
|
doing. If you do anything that results in mail being sent, that
|
|
mail will appear to be from the user you are impersonating. You
|
|
should be extremely careful while using this feature.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="classifications"
|
|
>3.3. Classifications</A
|
|
></H2
|
|
><P
|
|
>Classifications tend to be used in order to group several related
|
|
products into one distinct entity.</P
|
|
><P
|
|
>The classifications layer is disabled by default; it can be turned
|
|
on or off using the useclassification parameter,
|
|
in the <EM
|
|
>Bug Fields</EM
|
|
> section of the edit parameters screen.</P
|
|
><P
|
|
>Access to the administration of classifications is controlled using
|
|
the <EM
|
|
>editclassifications</EM
|
|
> system group, which defines
|
|
a privilege for creating, destroying, and editing classifications.</P
|
|
><P
|
|
>When activated, classifications will introduce an additional
|
|
step when filling bugs (dedicated to classification selection), and they
|
|
will also appear in the advanced search form.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="products"
|
|
>3.4. Products</A
|
|
></H2
|
|
><P
|
|
> <A
|
|
HREF="#gloss-product"
|
|
><I
|
|
CLASS="glossterm"
|
|
> Products</I
|
|
></A
|
|
> typically represent real-world
|
|
shipping products. Products can be given
|
|
<A
|
|
HREF="#classifications"
|
|
>Classifications</A
|
|
>.
|
|
For example, if a company makes computer games,
|
|
they could have a classification of "Games", and a separate
|
|
product for each game. This company might also have a
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Common"</SPAN
|
|
> product for units of technology used
|
|
in multiple games, and perhaps a few special products that
|
|
represent items that are not actually shipping products
|
|
(for example, "Website", or "Administration").
|
|
</P
|
|
><P
|
|
> Many of Bugzilla's settings are configurable on a per-product
|
|
basis. The number of <SPAN
|
|
CLASS="QUOTE"
|
|
>"votes"</SPAN
|
|
> available to
|
|
users is set per-product, as is the number of votes
|
|
required to move a bug automatically from the UNCONFIRMED
|
|
status to the NEW status.
|
|
</P
|
|
><P
|
|
> When creating or editing products the following options are
|
|
available:
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
>Product</DT
|
|
><DD
|
|
><P
|
|
>
|
|
The name of the product
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Description</DT
|
|
><DD
|
|
><P
|
|
>
|
|
A brief description of the product
|
|
</P
|
|
></DD
|
|
><DT
|
|
>URL describing milestones for this product</DT
|
|
><DD
|
|
><P
|
|
>
|
|
If there is reference URL, provide it here
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Default milestone</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Select the default milestone for this product.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Closed for bug entry</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Select this box to prevent new bugs from being
|
|
entered against this product.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Maximum votes per person</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Maximum votes a user is allowed to give for this
|
|
product
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Maximum votes a person can put on a single bug</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Maximum votes a user is allowed to give for this
|
|
product in a single bug
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Confirmation threshold</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Number of votes needed to automatically remove any
|
|
bug against this product from the UNCONFIRMED state
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Version</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Specify which version of the product bugs will be
|
|
entered against.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Create chart datasets for this product</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Select to make chart datasets available for this product.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><P
|
|
> When editing a product there is also a link to edit Group Access Controls,
|
|
see <A
|
|
HREF="#product-group-controls"
|
|
>Section 3.4.4</A
|
|
>.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="create-product"
|
|
>3.4.1. Creating New Products</A
|
|
></H3
|
|
><P
|
|
> To create a new product:
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>
|
|
Select <SPAN
|
|
CLASS="QUOTE"
|
|
>"Administration"</SPAN
|
|
> from the footer and then
|
|
choose <SPAN
|
|
CLASS="QUOTE"
|
|
>"Products"</SPAN
|
|
> from the main administration page.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Select the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Add"</SPAN
|
|
> link in the bottom right.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Enter the name of the product and a description. The
|
|
Description field may contain HTML.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> When the product is created, Bugzilla will give a message
|
|
stating that a component must be created before any bugs can
|
|
be entered against the new product. Follow the link to create
|
|
a new component. See <A
|
|
HREF="#components"
|
|
>Components</A
|
|
> for more
|
|
information.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="edit-products"
|
|
>3.4.2. Editing Products</A
|
|
></H3
|
|
><P
|
|
> To edit an existing product, click the "Products" link from the
|
|
"Administration" page. If the 'useclassification' parameter is
|
|
turned on, a table of existing classifications is displayed,
|
|
including an "Unclassified" category. The table indicates how many products
|
|
are in each classification. Click on the classification name to see its
|
|
products. If the 'useclassification' parameter is not in use, the table
|
|
lists all products directly. The product table summarizes the information
|
|
about the product defined
|
|
when the product was created. Click on the product name to edit these
|
|
properties, and to access links to other product attributes such as the
|
|
product's components, versions, milestones, and group access controls.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="comps-vers-miles-products"
|
|
>3.4.3. Adding or Editing Components, Versions and Target Milestones</A
|
|
></H3
|
|
><P
|
|
> To edit existing, or add new, Components, Versions or Target Milestones
|
|
to a Product, select the "Edit Components", "Edit Versions" or "Edit
|
|
Milestones" links from the "Edit Product" page. A table of existing
|
|
Components, Versions or Milestones is displayed. Click on a item name
|
|
to edit the properties of that item. Below the table is a link to add
|
|
a new Component, Version or Milestone.
|
|
</P
|
|
><P
|
|
> For more information on components, see <A
|
|
HREF="#components"
|
|
>Components</A
|
|
>.
|
|
</P
|
|
><P
|
|
> For more information on versions, see <A
|
|
HREF="#versions"
|
|
>Section 3.6</A
|
|
>.
|
|
</P
|
|
><P
|
|
> For more information on milestones, see <A
|
|
HREF="#milestones"
|
|
>Section 3.7</A
|
|
>.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="product-group-controls"
|
|
>3.4.4. Assigning Group Controls to Products</A
|
|
></H3
|
|
><P
|
|
>
|
|
On the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Edit Product"</SPAN
|
|
> page, there is a link called
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Edit Group Access Controls"</SPAN
|
|
>. The settings on this page
|
|
control the relationship of the groups to the product being edited.
|
|
</P
|
|
><P
|
|
> Group Access Controls are an important aspect of using groups for
|
|
isolating products and restricting access to bugs filed against those
|
|
products. For more information on groups, including how to create, edit
|
|
add users to, and alter permission of, see <A
|
|
HREF="#groups"
|
|
>Section 3.15</A
|
|
>.
|
|
</P
|
|
><P
|
|
> After selecting the "Edit Group Access Controls" link from the "Edit
|
|
Product" page, a table containing all user-defined groups for this
|
|
Bugzilla installation is displayed. The system groups that are created
|
|
when Bugzilla is installed are not applicable to Group Access Controls.
|
|
Below is description of what each of these fields means.
|
|
</P
|
|
><P
|
|
> Groups may be applicable (e.g bugs in this product can be associated
|
|
with this group) , default (e.g. bugs in this product are in this group
|
|
by default), and mandatory (e.g. bugs in this product must be associated
|
|
with this group) for each product. Groups can also control access
|
|
to bugs for a given product, or be used to make bugs for a product
|
|
totally read-only unless the group restrictions are met. The best way to
|
|
understand these relationships is by example. See
|
|
<A
|
|
HREF="#group-control-examples"
|
|
>Section 3.4.4.1</A
|
|
> for examples of
|
|
product and group relationships.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Products and Groups are not limited to a one-to-one relationship.
|
|
Multiple groups can be associated with the same product, and groups
|
|
can be associated with more than one product.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> If any group has <EM
|
|
>Entry</EM
|
|
> selected, then the
|
|
product will restrict bug entry to only those users
|
|
who are members of <EM
|
|
>all</EM
|
|
> the groups with
|
|
<EM
|
|
>Entry</EM
|
|
> selected.
|
|
</P
|
|
><P
|
|
> If any group has <EM
|
|
>Canedit</EM
|
|
> selected,
|
|
then the product will be read-only for any users
|
|
who are not members of <EM
|
|
>all</EM
|
|
> of the groups with
|
|
<EM
|
|
>Canedit</EM
|
|
> selected. <EM
|
|
>Only</EM
|
|
> users who
|
|
are members of all the <EM
|
|
>Canedit</EM
|
|
> groups
|
|
will be able to edit bugs for this product. This is an additional
|
|
restriction that enables finer-grained control over products rather
|
|
than just all-or-nothing access levels.
|
|
</P
|
|
><P
|
|
> The following settings let you
|
|
choose privileges on a <EM
|
|
>per-product basis</EM
|
|
>.
|
|
This is a convenient way to give privileges to
|
|
some users for some products only, without having
|
|
to give them global privileges which would affect
|
|
all products.
|
|
</P
|
|
><P
|
|
> Any group having <EM
|
|
>editcomponents</EM
|
|
>
|
|
selected allows users who are in this group to edit all
|
|
aspects of this product, including components, milestones
|
|
and versions.
|
|
</P
|
|
><P
|
|
> Any group having <EM
|
|
>canconfirm</EM
|
|
> selected
|
|
allows users who are in this group to confirm bugs
|
|
in this product.
|
|
</P
|
|
><P
|
|
> Any group having <EM
|
|
>editbugs</EM
|
|
> selected allows
|
|
users who are in this group to edit all fields of
|
|
bugs in this product.
|
|
</P
|
|
><P
|
|
> The <EM
|
|
>MemberControl</EM
|
|
> and
|
|
<EM
|
|
>OtherControl</EM
|
|
> are used in tandem to determine which
|
|
bugs will be placed in this group. The only allowable combinations of
|
|
these two parameters are listed in a table on the "Edit Group Access Controls"
|
|
page. Consult this table for details on how these fields can be used.
|
|
Examples of different uses are described below.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="group-control-examples"
|
|
>3.4.4.1. Common Applications of Group Controls</A
|
|
></H4
|
|
><P
|
|
> The use of groups is best explained by providing examples that illustrate
|
|
configurations for common use cases. The examples follow a common syntax:
|
|
<EM
|
|
>Group: Entry, MemberControl, OtherControl, CanEdit,
|
|
EditComponents, CanConfirm, EditBugs</EM
|
|
>. Where "Group" is the name
|
|
of the group being edited for this product. The other fields all
|
|
correspond to the table on the "Edit Group Access Controls" page. If any
|
|
of these options are not listed, it means they are not checked.
|
|
</P
|
|
><P
|
|
> Basic Product/Group Restriction
|
|
</P
|
|
><P
|
|
> Suppose there is a product called "Bar". The
|
|
"Bar" product can only have bugs entered against it by users in the
|
|
group "Foo". Additionally, bugs filed against product "Bar" must stay
|
|
restricted to users to "Foo" at all times. Furthermore, only members
|
|
of group "Foo" can edit bugs filed against product "Bar", even if other
|
|
users could see the bug. This arrangement would achieved by the
|
|
following:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> Product Bar:
|
|
foo: ENTRY, MANDATORY/MANDATORY, CANEDIT
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> Perhaps such strict restrictions are not needed for product "Bar". A
|
|
more lenient way to configure product "Bar" and group "Foo" would be:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> Product Bar:
|
|
foo: ENTRY, SHOWN/SHOWN, EDITCOMPONENTS, CANCONFIRM, EDITBUGS
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> The above indicates that for product "Bar", members of group "Foo" can
|
|
enter bugs. Any one with permission to edit a bug against product "Bar"
|
|
can put the bug
|
|
in group "Foo", even if they themselves are not in "Foo". Anyone in group
|
|
"Foo" can edit all aspects of the components of product "Bar", can confirm
|
|
bugs against product "Bar", and can edit all fields of any bug against
|
|
product "Bar".
|
|
</P
|
|
><P
|
|
> General User Access With Security Group
|
|
</P
|
|
><P
|
|
> To permit any user to file bugs against "Product A",
|
|
and to permit any user to submit those bugs into a
|
|
group called "Security":
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>
|
|
Product A:
|
|
security: SHOWN/SHOWN
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> General User Access With A Security Product
|
|
</P
|
|
><P
|
|
> To permit any user to file bugs against product called "Security"
|
|
while keeping those bugs from becoming visible to anyone
|
|
outside the group "SecurityWorkers" (unless a member of the
|
|
"SecurityWorkers" group removes that restriction):
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>
|
|
Product Security:
|
|
securityworkers: DEFAULT/MANDATORY
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> Product Isolation With a Common Group
|
|
</P
|
|
><P
|
|
> To permit users of "Product A" to access the bugs for
|
|
"Product A", users of "Product B" to access the bugs for
|
|
"Product B", and support staff, who are members of the "Support
|
|
Group" to access both, three groups are needed:
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>Support Group: Contains members of the support staff.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>AccessA Group: Contains users of product A and the Support group.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>AccessB Group: Contains users of product B and the Support group.</P
|
|
></LI
|
|
></OL
|
|
><P
|
|
> Once these three groups are defined, the product group controls
|
|
can be set to:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> Product A:
|
|
AccessA: ENTRY, MANDATORY/MANDATORY
|
|
Product B:
|
|
AccessB: ENTRY, MANDATORY/MANDATORY
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> Perhaps the "Support Group" wants more control. For example,
|
|
the "Support Group" could be permitted to make bugs inaccessible to
|
|
users of both groups "AccessA" and "AccessB".
|
|
Then, the "Support Group" could be permitted to publish
|
|
bugs relevant to all users in a third product (let's call it
|
|
"Product Common") that is read-only
|
|
to anyone outside the "Support Group". In this way the "Support Group"
|
|
could control bugs that should be seen by both groups.
|
|
That configuration would be:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> Product A:
|
|
AccessA: ENTRY, MANDATORY/MANDATORY
|
|
Support: SHOWN/NA
|
|
Product B:
|
|
AccessB: ENTRY, MANDATORY/MANDATORY
|
|
Support: SHOWN/NA
|
|
Product Common:
|
|
Support: ENTRY, DEFAULT/MANDATORY, CANEDIT
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> Make a Product Read Only
|
|
</P
|
|
><P
|
|
> Sometimes a product is retired and should no longer have
|
|
new bugs filed against it (for example, an older version of a software
|
|
product that is no longer supported). A product can be made read-only
|
|
by creating a group called "readonly" and adding products to the
|
|
group as needed:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> Product A:
|
|
ReadOnly: ENTRY, NA/NA, CANEDIT
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> For more information on Groups outside of how they relate to products
|
|
see <A
|
|
HREF="#groups"
|
|
>Section 3.15</A
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="components"
|
|
>3.5. Components</A
|
|
></H2
|
|
><P
|
|
>Components are subsections of a Product. E.g. the computer game
|
|
you are designing may have a "UI"
|
|
component, an "API" component, a "Sound System" component, and a
|
|
"Plugins" component, each overseen by a different programmer. It
|
|
often makes sense to divide Components in Bugzilla according to the
|
|
natural divisions of responsibility within your Product or
|
|
company.</P
|
|
><P
|
|
> Each component has a default assignee and (if you turned it on in the parameters),
|
|
a QA Contact. The default assignee should be the primary person who fixes bugs in
|
|
that component. The QA Contact should be the person who will ensure
|
|
these bugs are completely fixed. The Assignee, QA Contact, and Reporter
|
|
will get email when new bugs are created in this Component and when
|
|
these bugs change. Default Assignee and Default QA Contact fields only
|
|
dictate the
|
|
<EM
|
|
>default assignments</EM
|
|
>;
|
|
these can be changed on bug submission, or at any later point in
|
|
a bug's life.</P
|
|
><P
|
|
>To create a new Component:</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>Select the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Edit components"</SPAN
|
|
> link
|
|
from the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Edit product"</SPAN
|
|
> page</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Select the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Add"</SPAN
|
|
> link in the bottom right.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Fill out the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Component"</SPAN
|
|
> field, a
|
|
short <SPAN
|
|
CLASS="QUOTE"
|
|
>"Description"</SPAN
|
|
>, the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Default Assignee"</SPAN
|
|
>, <SPAN
|
|
CLASS="QUOTE"
|
|
>"Default CC List"</SPAN
|
|
>
|
|
and <SPAN
|
|
CLASS="QUOTE"
|
|
>"Default QA Contact"</SPAN
|
|
> (if enabled).
|
|
The <SPAN
|
|
CLASS="QUOTE"
|
|
>"Component Description"</SPAN
|
|
> field may contain a
|
|
limited subset of HTML tags. The <SPAN
|
|
CLASS="QUOTE"
|
|
>"Default Assignee"</SPAN
|
|
>
|
|
field must be a login name already existing in the Bugzilla database.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="versions"
|
|
>3.6. Versions</A
|
|
></H2
|
|
><P
|
|
>Versions are the revisions of the product, such as "Flinders
|
|
3.1", "Flinders 95", and "Flinders 2000". Version is not a multi-select
|
|
field; the usual practice is to select the earliest version known to have
|
|
the bug.
|
|
</P
|
|
><P
|
|
>To create and edit Versions:</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>From the "Edit product" screen, select "Edit Versions"</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>You will notice that the product already has the default
|
|
version "undefined". Click the "Add" link in the bottom right.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Enter the name of the Version. This field takes text only.
|
|
Then click the "Add" button.</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="milestones"
|
|
>3.7. Milestones</A
|
|
></H2
|
|
><P
|
|
>Milestones are "targets" that you plan to get a bug fixed by. For
|
|
example, you have a bug that you plan to fix for your 3.0 release, it
|
|
would be assigned the milestone of 3.0.</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Milestone options will only appear for a Product if you turned
|
|
on the "usetargetmilestone" parameter in the "Bug Fields" tab of the
|
|
"Parameters" page.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
>To create new Milestones, set Default Milestones, and set
|
|
Milestone URL:</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>Select "Edit milestones" from the "Edit product" page.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Select "Add" in the bottom right corner.
|
|
text</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Enter the name of the Milestone in the "Milestone" field. You
|
|
can optionally set the "sortkey", which is a positive or negative
|
|
number (-32768 to 32767) that defines where in the list this particular
|
|
milestone appears. This is because milestones often do not
|
|
occur in alphanumeric order For example, "Future" might be
|
|
after "Release 1.2". Select "Add".</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>From the Edit product screen, you can enter the URL of a
|
|
page which gives information about your milestones and what
|
|
they mean. </P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-overview"
|
|
>3.8. Flags</A
|
|
></H2
|
|
><P
|
|
> Flags are a way to attach a specific status to a bug or attachment,
|
|
either <SPAN
|
|
CLASS="QUOTE"
|
|
>"+"</SPAN
|
|
> or <SPAN
|
|
CLASS="QUOTE"
|
|
>"-"</SPAN
|
|
>. The meaning of these symbols depends on the text
|
|
the flag itself, but contextually they could mean pass/fail,
|
|
accept/reject, approved/denied, or even a simple yes/no. If your site
|
|
allows requestable flags, then users may set a flag to <SPAN
|
|
CLASS="QUOTE"
|
|
>"?"</SPAN
|
|
> as a
|
|
request to another user that they look at the bug/attachment, and set
|
|
the flag to its correct status.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-simpleexample"
|
|
>3.8.1. A Simple Example</A
|
|
></H3
|
|
><P
|
|
> A developer might want to ask their manager,
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Should we fix this bug before we release version 2.0?"</SPAN
|
|
>
|
|
They might want to do this for a <EM
|
|
>lot</EM
|
|
> of bugs,
|
|
so it would be nice to streamline the process...
|
|
</P
|
|
><P
|
|
> In Bugzilla, it would work this way:
|
|
<P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> The Bugzilla administrator creates a flag type called
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"blocking2.0"</SPAN
|
|
> that shows up on all bugs in
|
|
your product.
|
|
</P
|
|
><P
|
|
> It shows up on the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Show Bug"</SPAN
|
|
> screen
|
|
as the text <SPAN
|
|
CLASS="QUOTE"
|
|
>"blocking2.0"</SPAN
|
|
> with a drop-down box next
|
|
to it. The drop-down box contains four values: an empty space,
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"?"</SPAN
|
|
>, <SPAN
|
|
CLASS="QUOTE"
|
|
>"-"</SPAN
|
|
>, and <SPAN
|
|
CLASS="QUOTE"
|
|
>"+"</SPAN
|
|
>.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The developer sets the flag to <SPAN
|
|
CLASS="QUOTE"
|
|
>"?"</SPAN
|
|
>.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> The manager sees the <SAMP
|
|
CLASS="computeroutput"
|
|
>blocking2.0</SAMP
|
|
>
|
|
flag with a <SPAN
|
|
CLASS="QUOTE"
|
|
>"?"</SPAN
|
|
> value.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> If the manager thinks the feature should go into the product
|
|
before version 2.0 can be released, he sets the flag to
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"+"</SPAN
|
|
>. Otherwise, he sets it to <SPAN
|
|
CLASS="QUOTE"
|
|
>"-"</SPAN
|
|
>.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Now, every Bugzilla user who looks at the bug knows whether or
|
|
not the bug needs to be fixed before release of version 2.0.
|
|
</P
|
|
></LI
|
|
></OL
|
|
>
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-about"
|
|
>3.8.2. About Flags</A
|
|
></H3
|
|
><DIV
|
|
CLASS="section"
|
|
><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="flag-values"
|
|
>3.8.2.1. Values</A
|
|
></H4
|
|
><P
|
|
> Flags can have three values:
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
><SAMP
|
|
CLASS="computeroutput"
|
|
>?</SAMP
|
|
></DT
|
|
><DD
|
|
><P
|
|
> A user is requesting that a status be set. (Think of it as 'A question is being asked'.)
|
|
</P
|
|
></DD
|
|
><DT
|
|
><SAMP
|
|
CLASS="computeroutput"
|
|
>-</SAMP
|
|
></DT
|
|
><DD
|
|
><P
|
|
> The status has been set negatively. (The question has been answered <SPAN
|
|
CLASS="QUOTE"
|
|
>"no"</SPAN
|
|
>.)
|
|
</P
|
|
></DD
|
|
><DT
|
|
><SAMP
|
|
CLASS="computeroutput"
|
|
>+</SAMP
|
|
></DT
|
|
><DD
|
|
><P
|
|
> The status has been set positively.
|
|
(The question has been answered <SPAN
|
|
CLASS="QUOTE"
|
|
>"yes"</SPAN
|
|
>.)
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
</P
|
|
><P
|
|
> Actually, there's a fourth value a flag can have --
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"unset"</SPAN
|
|
> -- which shows up as a blank space. This
|
|
just means that nobody has expressed an opinion (or asked
|
|
someone else to express an opinion) about this bug or attachment.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="flag-askto"
|
|
>3.8.3. Using flag requests</A
|
|
></H3
|
|
><P
|
|
> If a flag has been defined as 'requestable', and a user has enough privileges
|
|
to request it (see below), the user can set the flag's status to <SPAN
|
|
CLASS="QUOTE"
|
|
>"?"</SPAN
|
|
>.
|
|
This status indicates that someone (a.k.a. <SPAN
|
|
CLASS="QUOTE"
|
|
>"the requester"</SPAN
|
|
>) is asking
|
|
someone else to set the flag to either <SPAN
|
|
CLASS="QUOTE"
|
|
>"+"</SPAN
|
|
> or <SPAN
|
|
CLASS="QUOTE"
|
|
>"-"</SPAN
|
|
>.
|
|
</P
|
|
><P
|
|
> If a flag has been defined as 'specifically requestable',
|
|
a text box will appear next to the flag into which the requester may
|
|
enter a Bugzilla username. That named person (a.k.a. <SPAN
|
|
CLASS="QUOTE"
|
|
>"the requestee"</SPAN
|
|
>)
|
|
will receive an email notifying them of the request, and pointing them
|
|
to the bug/attachment in question.
|
|
</P
|
|
><P
|
|
> If a flag has <EM
|
|
>not</EM
|
|
> been defined as 'specifically requestable',
|
|
then no such text-box will appear. A request to set this flag cannot be made of
|
|
any specific individual, but must be asked <SPAN
|
|
CLASS="QUOTE"
|
|
>"to the wind"</SPAN
|
|
>.
|
|
A requester may <SPAN
|
|
CLASS="QUOTE"
|
|
>"ask the wind"</SPAN
|
|
> on any flag simply by leaving the text-box blank.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="flag-types"
|
|
>3.8.4. Two Types of Flags</A
|
|
></H3
|
|
><P
|
|
> Flags can go in two places: on an attachment, or on a bug.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="flag-type-attachment"
|
|
>3.8.4.1. Attachment Flags</A
|
|
></H4
|
|
><P
|
|
> Attachment flags are used to ask a question about a specific
|
|
attachment on a bug.
|
|
</P
|
|
><P
|
|
> Many Bugzilla installations use this to
|
|
request that one developer <SPAN
|
|
CLASS="QUOTE"
|
|
>"review"</SPAN
|
|
> another
|
|
developer's code before they check it in. They attach the code to
|
|
a bug report, and then set a flag on that attachment called
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"review"</SPAN
|
|
> to
|
|
<SAMP
|
|
CLASS="computeroutput"
|
|
>review?boss@domain.com</SAMP
|
|
>.
|
|
boss@domain.com is then notified by email that
|
|
he has to check out that attachment and approve it or deny it.
|
|
</P
|
|
><P
|
|
> For a Bugzilla user, attachment flags show up in three places:
|
|
<P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> On the list of attachments in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Show Bug"</SPAN
|
|
>
|
|
screen, you can see the current state of any flags that
|
|
have been set to ?, +, or -. You can see who asked about
|
|
the flag (the requester), and who is being asked (the
|
|
requestee).
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> When you <SPAN
|
|
CLASS="QUOTE"
|
|
>"Edit"</SPAN
|
|
> an attachment, you can
|
|
see any settable flag, along with any flags that have
|
|
already been set. This <SPAN
|
|
CLASS="QUOTE"
|
|
>"Edit Attachment"</SPAN
|
|
>
|
|
screen is where you set flags to ?, -, +, or unset them.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Requests are listed in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Request Queue"</SPAN
|
|
>, which
|
|
is accessible from the <SPAN
|
|
CLASS="QUOTE"
|
|
>"My Requests"</SPAN
|
|
> link (if you are
|
|
logged in) or <SPAN
|
|
CLASS="QUOTE"
|
|
>"Requests"</SPAN
|
|
> link (if you are logged out)
|
|
visible in the footer of all pages.
|
|
</P
|
|
></LI
|
|
></OL
|
|
>
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="flag-type-bug"
|
|
>3.8.4.2. Bug Flags</A
|
|
></H4
|
|
><P
|
|
> Bug flags are used to set a status on the bug itself. You can
|
|
see Bug Flags in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Show Bug"</SPAN
|
|
> and <SPAN
|
|
CLASS="QUOTE"
|
|
>"Requests"</SPAN
|
|
>
|
|
screens, as described above.
|
|
</P
|
|
><P
|
|
> Only users with enough privileges (see below) may set flags on bugs.
|
|
This doesn't necessarily include the assignee, reporter, or users with the
|
|
<SAMP
|
|
CLASS="computeroutput"
|
|
>editbugs</SAMP
|
|
> permission.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-admin"
|
|
>3.8.5. Administering Flags</A
|
|
></H3
|
|
><P
|
|
> If you have the <SPAN
|
|
CLASS="QUOTE"
|
|
>"editcomponents"</SPAN
|
|
> permission, you can
|
|
edit Flag Types from the main administration page. Clicking the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Flags"</SPAN
|
|
> link will bring you to the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Administer
|
|
Flag Types"</SPAN
|
|
> page. Here, you can select whether you want
|
|
to create (or edit) a Bug flag, or an Attachment flag.
|
|
</P
|
|
><P
|
|
> No matter which you choose, the interface is the same, so we'll
|
|
just go over it once.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-edit"
|
|
>3.8.5.1. Editing a Flag</A
|
|
></H4
|
|
><P
|
|
> To edit a flag's properties, just click on the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Edit"</SPAN
|
|
>
|
|
link next to the flag's description. That will take you to the same
|
|
form as described below (<A
|
|
HREF="#flags-create"
|
|
>Section 3.8.5.2</A
|
|
>).
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-create"
|
|
>3.8.5.2. Creating a Flag</A
|
|
></H4
|
|
><P
|
|
> When you click on the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Create a Flag Type for..."</SPAN
|
|
>
|
|
link, you will be presented with a form. Here is what the fields in
|
|
the form mean:
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-create-field-name"
|
|
>3.8.5.2.1. Name</A
|
|
></H5
|
|
><P
|
|
> This is the name of the flag. This will be displayed
|
|
to Bugzilla users who are looking at or setting the flag.
|
|
The name may contain any valid Unicode characters except commas
|
|
and spaces.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-create-field-description"
|
|
>3.8.5.2.2. Description</A
|
|
></H5
|
|
><P
|
|
> The description describes the flag in more detail. It is visible
|
|
in a tooltip when hovering over a flag either in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Show Bug"</SPAN
|
|
>
|
|
or <SPAN
|
|
CLASS="QUOTE"
|
|
>"Edit Attachment"</SPAN
|
|
> pages. This field can be as
|
|
long as you like, and can contain any character you want.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-create-field-category"
|
|
>3.8.5.2.3. Category</A
|
|
></H5
|
|
><P
|
|
> Default behaviour for a newly-created flag is to appear on
|
|
products and all components, which is why <SPAN
|
|
CLASS="QUOTE"
|
|
>"__Any__:__Any__"</SPAN
|
|
>
|
|
is already entered in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Inclusions"</SPAN
|
|
> box.
|
|
If this is not your desired behaviour, you must either set some
|
|
exclusions (for products on which you don't want the flag to appear),
|
|
or you must remove <SPAN
|
|
CLASS="QUOTE"
|
|
>"__Any__:__Any__"</SPAN
|
|
> from the Inclusions box
|
|
and define products/components specifically for this flag.
|
|
</P
|
|
><P
|
|
> To create an Inclusion, select a Product from the top drop-down box.
|
|
You may also select a specific component from the bottom drop-down box.
|
|
(Setting <SPAN
|
|
CLASS="QUOTE"
|
|
>"__Any__"</SPAN
|
|
> for Product translates to,
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"all the products in this Bugzilla"</SPAN
|
|
>.
|
|
Selecting <SPAN
|
|
CLASS="QUOTE"
|
|
>"__Any__"</SPAN
|
|
> in the Component field means
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"all components in the selected product."</SPAN
|
|
>)
|
|
Selections made, press <SPAN
|
|
CLASS="QUOTE"
|
|
>"Include"</SPAN
|
|
>, and your
|
|
Product/Component pairing will show up in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Inclusions"</SPAN
|
|
> box on the right.
|
|
</P
|
|
><P
|
|
> To create an Exclusion, the process is the same; select a Product from the
|
|
top drop-down box, select a specific component if you want one, and press
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Exclude"</SPAN
|
|
>. The Product/Component pairing will show up in the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Exclusions"</SPAN
|
|
> box on the right.
|
|
</P
|
|
><P
|
|
> This flag <EM
|
|
>will</EM
|
|
> and <EM
|
|
>can</EM
|
|
> be set for any
|
|
products/components that appearing in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Inclusions"</SPAN
|
|
> box
|
|
(or which fall under the appropriate <SPAN
|
|
CLASS="QUOTE"
|
|
>"__Any__"</SPAN
|
|
>).
|
|
This flag <EM
|
|
>will not</EM
|
|
> appear (and therefore cannot be set) on
|
|
any products appearing in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Exclusions"</SPAN
|
|
> box.
|
|
<EM
|
|
> IMPORTANT: Exclusions override inclusions.</EM
|
|
>
|
|
</P
|
|
><P
|
|
> You may select a Product without selecting a specific Component,
|
|
but you can't select a Component without a Product, or to select a
|
|
Component that does not belong to the named Product. If you do so,
|
|
Bugzilla will display an error message, even if all your products
|
|
have a component by that name.
|
|
</P
|
|
><P
|
|
><EM
|
|
>Example:</EM
|
|
> Let's say you have a product called
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Jet Plane"</SPAN
|
|
> that has thousands of components. You want
|
|
to be able to ask if a problem should be fixed in the next model of
|
|
plane you release. We'll call the flag <SPAN
|
|
CLASS="QUOTE"
|
|
>"fixInNext"</SPAN
|
|
>.
|
|
But, there's one component in <SPAN
|
|
CLASS="QUOTE"
|
|
>"Jet Plane,"</SPAN
|
|
>
|
|
called <SPAN
|
|
CLASS="QUOTE"
|
|
>"Pilot."</SPAN
|
|
> It doesn't make sense to release a
|
|
new pilot, so you don't want to have the flag show up in that component.
|
|
So, you include <SPAN
|
|
CLASS="QUOTE"
|
|
>"Jet Plane:__Any__"</SPAN
|
|
> and you exclude
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Jet Plane:Pilot"</SPAN
|
|
>.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-create-field-sortkey"
|
|
>3.8.5.2.4. Sort Key</A
|
|
></H5
|
|
><P
|
|
> Flags normally show up in alphabetical order. If you want them to
|
|
show up in a different order, you can use this key set the order on each flag.
|
|
Flags with a lower sort key will appear before flags with a higher
|
|
sort key. Flags that have the same sort key will be sorted alphabetically,
|
|
but they will still be after flags with a lower sort key, and before flags
|
|
with a higher sort key.
|
|
</P
|
|
><P
|
|
> <EM
|
|
>Example:</EM
|
|
> I have AFlag (Sort Key 100), BFlag (Sort Key 10),
|
|
CFlag (Sort Key 10), and DFlag (Sort Key 1). These show up in
|
|
the order: DFlag, BFlag, CFlag, AFlag.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-create-field-active"
|
|
>3.8.5.2.5. Active</A
|
|
></H5
|
|
><P
|
|
> Sometimes, you might want to keep old flag information in the
|
|
Bugzilla database, but stop users from setting any new flags of this type.
|
|
To do this, uncheck <SPAN
|
|
CLASS="QUOTE"
|
|
>"active"</SPAN
|
|
>. Deactivated
|
|
flags will still show up in the UI if they are ?, +, or -, but they
|
|
may only be cleared (unset), and cannot be changed to a new value.
|
|
Once a deactivated flag is cleared, it will completely disappear from a
|
|
bug/attachment, and cannot be set again.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-create-field-requestable"
|
|
>3.8.5.2.6. Requestable</A
|
|
></H5
|
|
><P
|
|
> New flags are, by default, <SPAN
|
|
CLASS="QUOTE"
|
|
>"requestable"</SPAN
|
|
>, meaning that they
|
|
offer users the <SPAN
|
|
CLASS="QUOTE"
|
|
>"?"</SPAN
|
|
> option, as well as <SPAN
|
|
CLASS="QUOTE"
|
|
>"+"</SPAN
|
|
>
|
|
and <SPAN
|
|
CLASS="QUOTE"
|
|
>"-"</SPAN
|
|
>.
|
|
To remove the ? option, uncheck <SPAN
|
|
CLASS="QUOTE"
|
|
>"requestable"</SPAN
|
|
>.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-create-field-specific"
|
|
>3.8.5.2.7. Specifically Requestable</A
|
|
></H5
|
|
><P
|
|
> By default this box is checked for new flags, meaning that users may make
|
|
flag requests of specific individuals. Unchecking this box will remove the
|
|
text box next to a flag; if it is still requestable, then requests may
|
|
only be made <SPAN
|
|
CLASS="QUOTE"
|
|
>"to the wind."</SPAN
|
|
> Removing this after specific
|
|
requests have been made will not remove those requests; that data will
|
|
stay in the database (though it will no longer appear to the user).
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-create-field-multiplicable"
|
|
>3.8.5.2.8. Multiplicable</A
|
|
></H5
|
|
><P
|
|
> Any flag with <SPAN
|
|
CLASS="QUOTE"
|
|
>"Multiplicable"</SPAN
|
|
> set (default for new flags is 'on')
|
|
may be set more than once. After being set once, an unset flag
|
|
of the same type will appear below it with <SPAN
|
|
CLASS="QUOTE"
|
|
>"addl."</SPAN
|
|
> (short for
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"additional"</SPAN
|
|
>) before the name. There is no limit to the number of
|
|
times a Multiplicable flags may be set on the same bug/attachment.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-create-field-cclist"
|
|
>3.8.5.2.9. CC List</A
|
|
></H5
|
|
><P
|
|
> If you want certain users to be notified every time this flag is
|
|
set to ?, -, +, or unset, add them here. This is a comma-separated
|
|
list of email addresses that need not be restricted to Bugzilla usernames.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-create-grant-group"
|
|
>3.8.5.2.10. Grant Group</A
|
|
></H5
|
|
><P
|
|
> When this field is set to some given group, only users in the group
|
|
can set the flag to <SPAN
|
|
CLASS="QUOTE"
|
|
>"+"</SPAN
|
|
> and <SPAN
|
|
CLASS="QUOTE"
|
|
>"-"</SPAN
|
|
>. This
|
|
field does not affect who can request or cancel the flag. For that,
|
|
see the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Request Group"</SPAN
|
|
> field below. If this field
|
|
is left blank, all users can set or delete this flag. This field is
|
|
useful for restricting which users can approve or reject requests.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H5
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-create-request-group"
|
|
>3.8.5.2.11. Request Group</A
|
|
></H5
|
|
><P
|
|
> When this field is set to some given group, only users in the group
|
|
can request or cancel this flag. Note that this field has no effect
|
|
if the <SPAN
|
|
CLASS="QUOTE"
|
|
>"grant group"</SPAN
|
|
> field is empty. You can set the
|
|
value of this field to a different group, but both fields have to be
|
|
set to a group for this field to have an effect.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags-delete"
|
|
>3.8.5.3. Deleting a Flag</A
|
|
></H4
|
|
><P
|
|
> When you are at the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Administer Flag Types"</SPAN
|
|
> screen,
|
|
you will be presented with a list of Bug flags and a list of Attachment
|
|
Flags.
|
|
</P
|
|
><P
|
|
> To delete a flag, click on the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Delete"</SPAN
|
|
> link next to
|
|
the flag description.
|
|
</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Once you delete a flag, it is <EM
|
|
>gone</EM
|
|
> from
|
|
your Bugzilla. All the data for that flag will be deleted.
|
|
Everywhere that flag was set, it will disappear,
|
|
and you cannot get that data back. If you want to keep flag data,
|
|
but don't want anybody to set any new flags or change current flags,
|
|
unset <SPAN
|
|
CLASS="QUOTE"
|
|
>"active"</SPAN
|
|
> in the flag Edit form.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="keywords"
|
|
>3.9. Keywords</A
|
|
></H2
|
|
><P
|
|
> The administrator can define keywords which can be used to tag and
|
|
categorise bugs. For example, the keyword "regression" is commonly used.
|
|
A company might have a policy stating all regressions
|
|
must be fixed by the next release - this keyword can make tracking those
|
|
bugs much easier.
|
|
</P
|
|
><P
|
|
> Keywords are global, rather than per-product. If the administrator changes
|
|
a keyword currently applied to any bugs, the keyword cache must be rebuilt
|
|
using the <A
|
|
HREF="#sanitycheck"
|
|
>Section 3.16</A
|
|
> script. Currently keywords can not
|
|
be marked obsolete to prevent future usage.
|
|
</P
|
|
><P
|
|
> Keywords can be created, edited or deleted by clicking the "Keywords"
|
|
link in the admin page. There are two fields for each keyword - the keyword
|
|
itself and a brief description. Once created, keywords can be selected
|
|
and applied to individual bugs in that bug's "Details" section.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="custom-fields"
|
|
>3.10. Custom Fields</A
|
|
></H2
|
|
><P
|
|
> The release of Bugzilla 3.0 added the ability to create Custom Fields.
|
|
Custom Fields are treated like any other field - they can be set in bugs
|
|
and used for search queries. Administrators should keep in mind that
|
|
adding too many fields can make the user interface more complicated and
|
|
harder to use. Custom Fields should be added only when necessary and with
|
|
careful consideration.
|
|
</P
|
|
><DIV
|
|
CLASS="tip"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="tip"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Before adding a Custom Field, make sure that Bugzilla can not already
|
|
do the desired behavior. Many Bugzilla options are not enabled by
|
|
default, and many times Administrators find that simply enabling
|
|
certain options that already exist is sufficient.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> Administrators can manage Custom Fields using the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Custom Fields"</SPAN
|
|
> link on the Administration page. The Custom
|
|
Fields administration page displays a list of Custom Fields, if any exist,
|
|
and a link to "Add a new custom field".
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="add-custom-fields"
|
|
>3.10.1. Adding Custom Fields</A
|
|
></H3
|
|
><P
|
|
> To add a new Custom Field, click the "Add a new custom field" link. This
|
|
page displays several options for the new field, described below.
|
|
</P
|
|
><P
|
|
> The following attributes must be set for each new custom field:
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Name:</EM
|
|
>
|
|
The name of the field in the database, used internally. This name
|
|
MUST begin with <SPAN
|
|
CLASS="QUOTE"
|
|
>"cf_"</SPAN
|
|
> to prevent confusion with
|
|
standard fields. If this string is omitted, it will
|
|
be automatically added to the name entered.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Description:</EM
|
|
>
|
|
A brief string which is used as the label for this Custom Field.
|
|
That is the string that users will see, and should be
|
|
short and explicit.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Type:</EM
|
|
>
|
|
The type of field to create. There are
|
|
several types available:
|
|
<P
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
><TBODY
|
|
><TR
|
|
><TD
|
|
> Large Text Box: A multiple line box for entering free text.
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> Free Text: A single line box for entering free text.
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> Multiple-Selection Box: A list box where multiple options
|
|
can be selected. After creating this field, it must be edited
|
|
to add the selection options. See
|
|
<A
|
|
HREF="#edit-values-list"
|
|
>Section 3.11.1</A
|
|
> for information about
|
|
editing legal values.
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> Drop Down: A list box where only one option can be selected.
|
|
After creating this field, it must be edited to add the
|
|
selection options. See
|
|
<A
|
|
HREF="#edit-values-list"
|
|
>Section 3.11.1</A
|
|
> for information about
|
|
editing legal values.
|
|
</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> Date/Time: A date field. This field appears with a
|
|
calendar widget for choosing the date.
|
|
</TD
|
|
></TR
|
|
></TBODY
|
|
></TABLE
|
|
><P
|
|
></P
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Sortkey:</EM
|
|
>
|
|
Integer that determines in which order Custom Fields are
|
|
displayed in the User Interface, especially when viewing a bug.
|
|
Fields with lower values are displayed first.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Can be set on bug creation:</EM
|
|
>
|
|
Boolean that determines whether this field can be set on
|
|
bug creation. If not selected, then a bug must be created
|
|
before this field can be set. See <A
|
|
HREF="#bugreports"
|
|
>Section 5.6</A
|
|
>
|
|
for information about filing bugs.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Displayed in bugmail for new bugs:</EM
|
|
>
|
|
Boolean that determines whether the value set on this field
|
|
should appear in bugmail when the bug is filed. This attribute
|
|
has no effect if the field cannot be set on bug creation.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Is obsolete:</EM
|
|
>
|
|
Boolean that determines whether this field should
|
|
be displayed at all. Obsolete Custom Fields are hidden.
|
|
</P
|
|
></LI
|
|
></UL
|
|
>
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="edit-custom-fields"
|
|
>3.10.2. Editing Custom Fields</A
|
|
></H3
|
|
><P
|
|
> As soon as a Custom Field is created, its name and type cannot be
|
|
changed. If this field is a drop down menu, its legal values can
|
|
be set as described in <A
|
|
HREF="#edit-values-list"
|
|
>Section 3.11.1</A
|
|
>. All
|
|
other attributes can be edited as described above.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="delete-custom-fields"
|
|
>3.10.3. Deleting Custom Fields</A
|
|
></H3
|
|
><P
|
|
> It is only possible to delete obsolete Custom Fields
|
|
if the field has never been used in the database.
|
|
To remove a field which already has content,
|
|
mark it as obsolete.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="edit-values"
|
|
>3.11. Legal Values</A
|
|
></H2
|
|
><P
|
|
> Since Bugzilla 2.20 RC1, legal values for Operating Systems, platforms,
|
|
bug priorities and severities can be edited from the User Interface
|
|
directly. This means that it is no longer required to manually edit
|
|
<TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
>. Starting with Bugzilla 2.23.3,
|
|
the list of valid resolutions can be customized from the same interface.
|
|
Since Bugzilla 3.1.1 the list of valid bug statuses can be customized
|
|
as well.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="edit-values-list"
|
|
>3.11.1. Viewing/Editing legal values</A
|
|
></H3
|
|
><P
|
|
> Editing legal values requires <SPAN
|
|
CLASS="QUOTE"
|
|
>"admin"</SPAN
|
|
> privileges.
|
|
Select "Legal Values" from the Administration page. A list of all
|
|
fields, both system fields and Custom Fields, for which legal values
|
|
can be edited appears. Click a field name to edit its legal values.
|
|
</P
|
|
><P
|
|
> There is no limit to how many values a field can have, but each value
|
|
must be unique to that field. The sortkey is important to display these
|
|
values in the desired order.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="edit-values-delete"
|
|
>3.11.2. Deleting legal values</A
|
|
></H3
|
|
><P
|
|
> Legal values from Custom Fields can be deleted, but only if the
|
|
following two conditions are respected:
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>The value is not used by default for the field.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>No bug is currently using this value.</P
|
|
></LI
|
|
></OL
|
|
><P
|
|
> If any of these conditions is not respected, the value cannot be deleted.
|
|
The only way to delete these values is to reassign bugs to another value
|
|
and to set another value as default for the field.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="bug_status_workflow"
|
|
>3.12. Bug Status Workflow</A
|
|
></H2
|
|
><P
|
|
> The bug status workflow is no longer hardcoded but can be freely customized
|
|
from the web interface. Only one bug status cannot be renamed nor deleted,
|
|
UNCONFIRMED, but the workflow involving it is free. The configuration
|
|
page displays all existing bug statuses twice, first on the left for bug
|
|
statuses we come from and on the top for bug statuses we move to.
|
|
If the checkbox is checked, then the transition between the two bug statuses
|
|
is legal, else it's forbidden independently of your privileges. The bug status
|
|
used for the "duplicate_or_move_bug_status" parameter must be part of the
|
|
workflow as that is the bug status which will be used when duplicating or
|
|
moving a bug, so it must be available from each bug status.
|
|
</P
|
|
><P
|
|
> When the workflow is set, the "View Current Triggers" link below the table
|
|
lets you set which transitions require a comment from the user.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="voting"
|
|
>3.13. Voting</A
|
|
></H2
|
|
><P
|
|
>Voting allows users to be given a pot of votes which they can allocate
|
|
to bugs, to indicate that they'd like them fixed.
|
|
This allows developers to gauge
|
|
user need for a particular enhancement or bugfix. By allowing bugs with
|
|
a certain number of votes to automatically move from "UNCONFIRMED" to
|
|
"NEW", users of the bug system can help high-priority bugs garner
|
|
attention so they don't sit for a long time awaiting triage.</P
|
|
><P
|
|
>To modify Voting settings:</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>Navigate to the "Edit product" screen for the Product you
|
|
wish to modify</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><EM
|
|
>Maximum Votes per person</EM
|
|
>:
|
|
Setting this field to "0" disables voting.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><EM
|
|
>Maximum Votes a person can put on a single
|
|
bug</EM
|
|
>:
|
|
It should probably be some number lower than the
|
|
"Maximum votes per person". Don't set this field to "0" if
|
|
"Maximum votes per person" is non-zero; that doesn't make
|
|
any sense.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><EM
|
|
>Number of votes a bug in this product needs to
|
|
automatically get out of the UNCONFIRMED state</EM
|
|
>:
|
|
Setting this field to "0" disables the automatic move of
|
|
bugs from UNCONFIRMED to NEW.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Once you have adjusted the values to your preference, click
|
|
"Update".</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="quips"
|
|
>3.14. Quips</A
|
|
></H2
|
|
><P
|
|
> Quips are small text messages that can be configured to appear
|
|
next to search results. A Bugzilla installation can have its own specific
|
|
quips. Whenever a quip needs to be displayed, a random selection
|
|
is made from the pool of already existing quips.
|
|
</P
|
|
><P
|
|
> Quips are controlled by the <EM
|
|
>enablequips</EM
|
|
> parameter.
|
|
It has several possible values: on, approved, frozen or off.
|
|
In order to enable quips approval you need to set this parameter
|
|
to "approved". In this way, users are free to submit quips for
|
|
addition but an administrator must explicitly approve them before
|
|
they are actually used.
|
|
</P
|
|
><P
|
|
> In order to see the user interface for the quips, it is enough to click
|
|
on a quip when it is displayed together with the search results. Or
|
|
it can be seen directly in the browser by visiting the quips.cgi URL
|
|
(prefixed with the usual web location of the Bugzilla installation).
|
|
Once the quip interface is displayed, it is enough to click the
|
|
"view and edit the whole quip list" in order to see the administration
|
|
page. A page with all the quips available in the database will
|
|
be displayed.
|
|
</P
|
|
><P
|
|
> Next to each tip there is a checkbox, under the
|
|
"Approved" column. Quips who have this checkbox checked are
|
|
already approved and will appear next to the search results.
|
|
The ones that have it unchecked are still preserved in the
|
|
database but they will not appear on search results pages.
|
|
User submitted quips have initially the checkbox unchecked.
|
|
</P
|
|
><P
|
|
> Also, there is a delete link next to each quip,
|
|
which can be used in order to permanently delete a quip.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="groups"
|
|
>3.15. Groups and Group Security</A
|
|
></H2
|
|
><P
|
|
> Groups allow for separating bugs into logical divisions.
|
|
Groups are typically used to
|
|
to isolate bugs that should only be seen by certain people. For
|
|
example, a company might create a different group for each one of its customers
|
|
or partners. Group permissions could be set so that each partner or customer would
|
|
only have access to their own bugs. Or, groups might be used to create
|
|
variable access controls for different departments within an organization.
|
|
Another common use of groups is to associate groups with products,
|
|
creating isolation and access control on a per-product basis.
|
|
</P
|
|
><P
|
|
> Groups and group behaviors are controlled in several places:
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> The group configuration page. To view or edit existing groups, or to
|
|
create new groups, access the "Groups" link from the "Administration"
|
|
page. This section of the manual deals primarily with the aspect of
|
|
group controls accessed on this page.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Global configuration parameters. Bugzilla has several parameters
|
|
that control the overall default group behavior and restriction
|
|
levels. For more information on the parameters that control
|
|
group behavior globally, see <A
|
|
HREF="#param-group-security"
|
|
>Section 3.1.9</A
|
|
>.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Product association with groups. Most of the functionality of groups
|
|
and group security is controlled at the product level. Some aspects
|
|
of group access controls for products are discussed in this section,
|
|
but for more detail see <A
|
|
HREF="#product-group-controls"
|
|
>Section 3.4.4</A
|
|
>.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Group access for users. See <A
|
|
HREF="#users-and-groups"
|
|
>Section 3.15.3</A
|
|
> for
|
|
details on how users are assigned group access.
|
|
</P
|
|
></LI
|
|
></OL
|
|
><P
|
|
> Group permissions are such that if a bug belongs to a group, only members
|
|
of that group can see the bug. If a bug is in more than one group, only
|
|
members of <EM
|
|
>all</EM
|
|
> the groups that the bug is in can see
|
|
the bug. For information on granting read-only access to certain people and
|
|
full edit access to others, see <A
|
|
HREF="#product-group-controls"
|
|
>Section 3.4.4</A
|
|
>.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> By default, bugs can also be seen by the Assignee, the Reporter, and
|
|
by everyone on the CC List, regardless of whether or not the bug would
|
|
typically be viewable by them. Visibility to the Reporter and CC List can
|
|
be overridden (on a per-bug basis) by bringing up the bug, finding the
|
|
section that starts with <SPAN
|
|
CLASS="QUOTE"
|
|
>"Users in the roles selected below..."</SPAN
|
|
>
|
|
and un-checking the box next to either 'Reporter' or 'CC List' (or both).
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="create-groups"
|
|
>3.15.1. Creating Groups</A
|
|
></H3
|
|
><P
|
|
> To create a new group, follow the steps below:
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> Select the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Administration"</SPAN
|
|
> link in the page footer,
|
|
and then select the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Groups"</SPAN
|
|
> link from the
|
|
Administration page.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> A table of all the existing groups is displayed. Below the table is a
|
|
description of all the fields. To create a new group, select the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Add Group"</SPAN
|
|
> link under the table of existing groups.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> There are five fields to fill out. These fields are documented below
|
|
the form. Choose a name and description for the group. Decide whether
|
|
this group should be used for bugs (in all likelihood this should be
|
|
selected). Optionally, choose a regular expression that will
|
|
automatically add any matching users to the group, and choose an
|
|
icon that will help identify user comments for the group. The regular
|
|
expression can be useful, for example, to automatically put all users
|
|
from the same company into one group (if the group is for a specific
|
|
customer or partner).
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If <SPAN
|
|
CLASS="QUOTE"
|
|
>"User RegExp"</SPAN
|
|
> is filled out, users whose email
|
|
addresses match the regular expression will automatically be
|
|
members of the group as long as their email addresses continue
|
|
to match the regular expression. If their email address changes
|
|
and no longer matches the regular expression, they will be removed
|
|
from the group. Versions 2.16 and older of Bugzilla did not automatically
|
|
remove users who's email addresses no longer matched the RegExp.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If specifying a domain in the regular expression, end
|
|
the regexp with a "$". Otherwise, when granting access to
|
|
"@mycompany\.com", access will also be granted to
|
|
'badperson@mycompany.com.cracker.net'. Use the syntax,
|
|
'@mycompany\.com$' for the regular expression.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></LI
|
|
><LI
|
|
><P
|
|
> After the new group is created, it can be edited for additional options.
|
|
The "Edit Group" page allows for specifying other groups that should be included
|
|
in this group and which groups should be permitted to add and delete
|
|
users from this group. For more details, see <A
|
|
HREF="#edit-groups"
|
|
>Section 3.15.2</A
|
|
>.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="edit-groups"
|
|
>3.15.2. Editing Groups and Assigning Group Permissions</A
|
|
></H3
|
|
><P
|
|
> To access the "Edit Groups" page, select the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Administration"</SPAN
|
|
> link in the page footer,
|
|
and then select the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Groups"</SPAN
|
|
> link from the Administration page.
|
|
A table of all the existing groups is displayed. Click on a group name
|
|
you wish to edit or control permissions for.
|
|
</P
|
|
><P
|
|
> The "Edit Groups" page contains the same five fields present when
|
|
creating a new group. Below that are two additional sections, "Group
|
|
Permissions," and "Mass Remove". The "Mass Remove" option simply removes
|
|
all users from the group who match the regular expression entered. The
|
|
"Group Permissions" section requires further explanation.
|
|
</P
|
|
><P
|
|
> The "Group Permissions" section on the "Edit Groups" page contains four sets
|
|
of permissions that control the relationship of this group to other
|
|
groups. If the 'usevisibilitygroups' parameter is in use (see
|
|
<A
|
|
HREF="#parameters"
|
|
>Section 3.1</A
|
|
>) two additional sets of permissions are displayed.
|
|
Each set consists of two select boxes. On the left, a select box
|
|
with a list of all existing groups. On the right, a select box listing
|
|
all groups currently selected for this permission setting (this box will
|
|
be empty for new groups). The way these controls allow groups to relate
|
|
to one another is called <EM
|
|
>inheritance</EM
|
|
>.
|
|
Each of the six permissions is described below.
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
><EM
|
|
>Groups That Are a Member of This Group</EM
|
|
></DT
|
|
><DD
|
|
><P
|
|
>
|
|
Members of any groups selected here will automatically have
|
|
membership in this group. In other words, members of any selected
|
|
group will inherit membership in this group.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><EM
|
|
>Groups That This Group Is a Member Of</EM
|
|
></DT
|
|
><DD
|
|
><P
|
|
> Members of this group will inherit membership to any group
|
|
selected here. For example, suppose the group being edited is
|
|
an Admin group. If there are two products (Product1 and Product2)
|
|
and each product has its
|
|
own group (Group1 and Group2), and the Admin group
|
|
should have access to both products,
|
|
simply select both Group1 and Group2 here.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><EM
|
|
>Groups That Can Grant Membership in This Group</EM
|
|
></DT
|
|
><DD
|
|
><P
|
|
> The members of any group selected here will be able add users
|
|
to this group, even if they themselves are not in this group.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><EM
|
|
>Groups That This Group Can Grant Membership In</EM
|
|
></DT
|
|
><DD
|
|
><P
|
|
> Members of this group can add users to any group selected here,
|
|
even if they themselves are not in the selected groups.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><EM
|
|
>Groups That Can See This Group</EM
|
|
></DT
|
|
><DD
|
|
><P
|
|
> Members of any selected group can see the users in this group.
|
|
This setting is only visible if the 'usevisibilitygroups' parameter
|
|
is enabled on the Bugzilla Configuration page. See
|
|
<A
|
|
HREF="#parameters"
|
|
>Section 3.1</A
|
|
> for information on configuring Bugzilla.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><EM
|
|
>Groups That This Group Can See</EM
|
|
></DT
|
|
><DD
|
|
><P
|
|
> Members of this group can see members in any of the selected groups.
|
|
This setting is only visible if the 'usevisibilitygroups' parameter
|
|
is enabled on the the Bugzilla Configuration page. See
|
|
<A
|
|
HREF="#parameters"
|
|
>Section 3.1</A
|
|
> for information on configuring Bugzilla.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="users-and-groups"
|
|
>3.15.3. Assigning Users to Groups</A
|
|
></H3
|
|
><P
|
|
> A User can become a member of a group in several ways:
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> The user can be explicitly placed in the group by editing
|
|
the user's profile. This can be done by accessing the "Users" page
|
|
from the "Administration" page. Use the search form to find the user
|
|
you want to edit group membership for, and click on their email
|
|
address in the search results to edit their profile. The profile
|
|
page lists all the groups, and indicates if the user is a member of
|
|
the group either directly or indirectly. More information on indirect
|
|
group membership is below. For more details on User administration,
|
|
see <A
|
|
HREF="#useradmin"
|
|
>Section 3.2</A
|
|
>.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> The group can include another group of which the user is
|
|
a member. This is indicated by square brackets around the checkbox
|
|
next to the group name in the user's profile.
|
|
See <A
|
|
HREF="#edit-groups"
|
|
>Section 3.15.2</A
|
|
> for details on group inheritance.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> The user's email address can match the regular expression
|
|
that has been specified to automatically grant membership to
|
|
the group. This is indicated by "*" around the check box by the
|
|
group name in the user's profile.
|
|
See <A
|
|
HREF="#create-groups"
|
|
>Section 3.15.1</A
|
|
> for details on
|
|
the regular expression option when creating groups.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN2166"
|
|
>3.15.4. Assigning Group Controls to Products</A
|
|
></H3
|
|
><P
|
|
> The primary functionality of groups is derived from the relationship of
|
|
groups to products. The concepts around segregating access to bugs with
|
|
product group controls can be confusing. For details and examples on this
|
|
topic, see <A
|
|
HREF="#product-group-controls"
|
|
>Section 3.4.4</A
|
|
>.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="sanitycheck"
|
|
>3.16. Checking and Maintaining Database Integrity</A
|
|
></H2
|
|
><P
|
|
> Over time it is possible for the Bugzilla database to become corrupt
|
|
or to have anomalies.
|
|
This could happen through normal usage of Bugzilla, manual database
|
|
administration outside of the Bugzilla user interface, or from some
|
|
other unexpected event. Bugzilla includes a "Sanity Check" script that
|
|
can perform several basic database checks, and repair certain problems or
|
|
inconsistencies.
|
|
</P
|
|
><P
|
|
> To run the "Sanity Check" script, log in as an Administrator and click the
|
|
"Sanity Check" link in the admin page. Any problems that are found will be
|
|
displayed in red letters. If the script is capable of fixing a problem,
|
|
it will present a link to initiate the fix. If the script can not
|
|
fix the problem it will require manual database administration or recovery.
|
|
</P
|
|
><P
|
|
> The "Sanity Check" script can also be run from the command line via the perl
|
|
script <TT
|
|
CLASS="filename"
|
|
>sanitycheck.pl</TT
|
|
>. The script can also be run as
|
|
a <B
|
|
CLASS="command"
|
|
>cron</B
|
|
> job. Results will be delivered by email.
|
|
</P
|
|
><P
|
|
> The "Sanity Check" script should be run on a regular basis as a matter of
|
|
best practice.
|
|
</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> The "Sanity Check" script is no substitute for a competent database
|
|
administrator. It is only designed to check and repair basic database
|
|
problems.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="chapter"
|
|
><HR><H1
|
|
><A
|
|
NAME="security"
|
|
></A
|
|
>Chapter 4. Bugzilla Security</H1
|
|
><P
|
|
>While some of the items in this chapter are related to the operating
|
|
system Bugzilla is running on or some of the support software required to
|
|
run Bugzilla, it is all related to protecting your data. This is not
|
|
intended to be a comprehensive guide to securing Linux, Apache, MySQL, or
|
|
any other piece of software mentioned. There is no substitute for active
|
|
administration and monitoring of a machine. The key to good security is
|
|
actually right in the middle of the word: <EM
|
|
>U R It</EM
|
|
>.
|
|
</P
|
|
><P
|
|
>While programmers in general always strive to write secure code,
|
|
accidents can and do happen. The best approach to security is to always
|
|
assume that the program you are working with isn't 100% secure and restrict
|
|
its access to other parts of your machine as much as possible.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="security-os"
|
|
>4.1. Operating System</A
|
|
></H2
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="security-os-ports"
|
|
>4.1.1. TCP/IP Ports</A
|
|
></H3
|
|
><P
|
|
>The TCP/IP standard defines more than 65,000 ports for sending
|
|
and receiving traffic. Of those, Bugzilla needs exactly one to operate
|
|
(different configurations and options may require up to 3). You should
|
|
audit your server and make sure that you aren't listening on any ports
|
|
you don't need to be. It's also highly recommended that the server
|
|
Bugzilla resides on, along with any other machines you administer, be
|
|
placed behind some kind of firewall.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="security-os-accounts"
|
|
>4.1.2. System User Accounts</A
|
|
></H3
|
|
><P
|
|
>Many <A
|
|
HREF="#gloss-daemon"
|
|
><I
|
|
CLASS="glossterm"
|
|
>daemons</I
|
|
></A
|
|
>, such
|
|
as Apache's <TT
|
|
CLASS="filename"
|
|
>httpd</TT
|
|
> or MySQL's
|
|
<TT
|
|
CLASS="filename"
|
|
>mysqld</TT
|
|
>, run as either <SPAN
|
|
CLASS="QUOTE"
|
|
>"root"</SPAN
|
|
> or
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"nobody"</SPAN
|
|
>. This is even worse on Windows machines where the
|
|
majority of <A
|
|
HREF="#gloss-service"
|
|
><I
|
|
CLASS="glossterm"
|
|
>services</I
|
|
></A
|
|
>
|
|
run as <SPAN
|
|
CLASS="QUOTE"
|
|
>"SYSTEM"</SPAN
|
|
>. While running as <SPAN
|
|
CLASS="QUOTE"
|
|
>"root"</SPAN
|
|
> or
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"SYSTEM"</SPAN
|
|
> introduces obvious security concerns, the
|
|
problems introduced by running everything as <SPAN
|
|
CLASS="QUOTE"
|
|
>"nobody"</SPAN
|
|
> may
|
|
not be so obvious. Basically, if you run every daemon as
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"nobody"</SPAN
|
|
> and one of them gets compromised it can
|
|
compromise every other daemon running as <SPAN
|
|
CLASS="QUOTE"
|
|
>"nobody"</SPAN
|
|
> on your
|
|
machine. For this reason, it is recommended that you create a user
|
|
account for each daemon.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>You will need to set the <CODE
|
|
CLASS="option"
|
|
>webservergroup</CODE
|
|
> option
|
|
in <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
> to the group your web server runs
|
|
as. This will allow <TT
|
|
CLASS="filename"
|
|
>./checksetup.pl</TT
|
|
> to set file
|
|
permissions on Unix systems so that nothing is world-writable.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="security-os-chroot"
|
|
>4.1.3. The <TT
|
|
CLASS="filename"
|
|
>chroot</TT
|
|
> Jail</A
|
|
></H3
|
|
><P
|
|
> If your system supports it, you may wish to consider running
|
|
Bugzilla inside of a <TT
|
|
CLASS="filename"
|
|
>chroot</TT
|
|
> jail. This option
|
|
provides unprecedented security by restricting anything running
|
|
inside the jail from accessing any information outside of it. If you
|
|
wish to use this option, please consult the documentation that came
|
|
with your system.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="security-webserver"
|
|
>4.2. Web server</A
|
|
></H2
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="security-webserver-access"
|
|
>4.2.1. Disabling Remote Access to Bugzilla Configuration Files</A
|
|
></H3
|
|
><P
|
|
> There are many files that are placed in the Bugzilla directory
|
|
area that should not be accessible from the web server. Because of the way
|
|
Bugzilla is currently layed out, the list of what should and should not
|
|
be accessible is rather complicated. A quick way is to run
|
|
<TT
|
|
CLASS="filename"
|
|
>testserver.pl</TT
|
|
> to check if your web server serves
|
|
Bugzilla files as expected. If not, you may want to follow the few
|
|
steps below.
|
|
</P
|
|
><DIV
|
|
CLASS="tip"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="tip"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Bugzilla ships with the ability to create
|
|
<A
|
|
HREF="#gloss-htaccess"
|
|
><I
|
|
CLASS="glossterm"
|
|
><TT
|
|
CLASS="filename"
|
|
>.htaccess</TT
|
|
></I
|
|
></A
|
|
>
|
|
files that enforce these rules. Instructions for enabling these
|
|
directives in Apache can be found in <A
|
|
HREF="#http-apache"
|
|
>Section 2.2.4.1</A
|
|
>
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
></P
|
|
><UL
|
|
COMPACT="COMPACT"
|
|
><LI
|
|
><P
|
|
>In the main Bugzilla directory, you should:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
COMPACT="COMPACT"
|
|
><LI
|
|
><P
|
|
>Block:
|
|
<TT
|
|
CLASS="filename"
|
|
>*.pl</TT
|
|
>, <TT
|
|
CLASS="filename"
|
|
>*localconfig*</TT
|
|
>
|
|
</P
|
|
></LI
|
|
></UL
|
|
></LI
|
|
><LI
|
|
><P
|
|
>In <TT
|
|
CLASS="filename"
|
|
>data</TT
|
|
>:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
COMPACT="COMPACT"
|
|
><LI
|
|
><P
|
|
>Block everything</P
|
|
></LI
|
|
></UL
|
|
></LI
|
|
><LI
|
|
><P
|
|
>In <TT
|
|
CLASS="filename"
|
|
>data/webdot</TT
|
|
>:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
COMPACT="COMPACT"
|
|
><LI
|
|
><P
|
|
>If you use a remote webdot server:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
COMPACT="COMPACT"
|
|
><LI
|
|
><P
|
|
>Block everything</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>But allow
|
|
<TT
|
|
CLASS="filename"
|
|
>*.dot</TT
|
|
>
|
|
only for the remote webdot server</P
|
|
></LI
|
|
></UL
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Otherwise, if you use a local GraphViz:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
COMPACT="COMPACT"
|
|
><LI
|
|
><P
|
|
>Block everything</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>But allow:
|
|
<TT
|
|
CLASS="filename"
|
|
>*.png</TT
|
|
>, <TT
|
|
CLASS="filename"
|
|
>*.gif</TT
|
|
>, <TT
|
|
CLASS="filename"
|
|
>*.jpg</TT
|
|
>, <TT
|
|
CLASS="filename"
|
|
>*.map</TT
|
|
>
|
|
</P
|
|
></LI
|
|
></UL
|
|
></LI
|
|
><LI
|
|
><P
|
|
>And if you don't use any dot:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
COMPACT="COMPACT"
|
|
><LI
|
|
><P
|
|
>Block everything</P
|
|
></LI
|
|
></UL
|
|
></LI
|
|
></UL
|
|
></LI
|
|
><LI
|
|
><P
|
|
>In <TT
|
|
CLASS="filename"
|
|
>Bugzilla</TT
|
|
>:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
COMPACT="COMPACT"
|
|
><LI
|
|
><P
|
|
>Block everything</P
|
|
></LI
|
|
></UL
|
|
></LI
|
|
><LI
|
|
><P
|
|
>In <TT
|
|
CLASS="filename"
|
|
>template</TT
|
|
>:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
COMPACT="COMPACT"
|
|
><LI
|
|
><P
|
|
>Block everything</P
|
|
></LI
|
|
></UL
|
|
></LI
|
|
></UL
|
|
><P
|
|
>Be sure to test that data that should not be accessed remotely is
|
|
properly blocked. Of particular interest is the localconfig file which
|
|
contains your database password. Also, be aware that many editors
|
|
create temporary and backup files in the working directory and that
|
|
those should also not be accessible. For more information, see
|
|
<A
|
|
HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=186383"
|
|
TARGET="_top"
|
|
>bug 186383</A
|
|
>
|
|
or
|
|
<A
|
|
HREF="http://online.securityfocus.com/bid/6501"
|
|
TARGET="_top"
|
|
>Bugtraq ID 6501</A
|
|
>.
|
|
To test, simply run <TT
|
|
CLASS="filename"
|
|
>testserver.pl</TT
|
|
>, as said above.
|
|
</P
|
|
><DIV
|
|
CLASS="tip"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="tip"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Be sure to check <A
|
|
HREF="#http"
|
|
>Section 2.2.4</A
|
|
> for instructions
|
|
specific to the web server you use.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="security-bugzilla"
|
|
>4.3. Bugzilla</A
|
|
></H2
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="security-bugzilla-charset"
|
|
>4.3.1. Prevent users injecting malicious Javascript</A
|
|
></H3
|
|
><P
|
|
>If you installed Bugzilla version 2.22 or later from scratch,
|
|
then the <EM
|
|
>utf8</EM
|
|
> parameter is switched on by default.
|
|
This makes Bugzilla explicitly set the character encoding, following
|
|
<A
|
|
HREF="http://www.cert.org/tech_tips/malicious_code_mitigation.html#3"
|
|
TARGET="_top"
|
|
>a
|
|
CERT advisory</A
|
|
> recommending exactly this.
|
|
The following therefore does not apply to you; just keep
|
|
<EM
|
|
>utf8</EM
|
|
> turned on.
|
|
</P
|
|
><P
|
|
>If you've upgraded from an older version, then it may be possible
|
|
for a Bugzilla user to take advantage of character set encoding
|
|
ambiguities to inject HTML into Bugzilla comments.
|
|
This could include malicious scripts.
|
|
This is because due to internationalization concerns, we are unable to
|
|
turn the <EM
|
|
>utf8</EM
|
|
> parameter on by default for upgraded
|
|
installations.
|
|
Turning it on manually will prevent this problem.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="chapter"
|
|
><HR><H1
|
|
><A
|
|
NAME="using"
|
|
></A
|
|
>Chapter 5. Using Bugzilla</H1
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="using-intro"
|
|
>5.1. Introduction</A
|
|
></H2
|
|
><P
|
|
>This section contains information for end-users of Bugzilla. There
|
|
is a Bugzilla test installation, called
|
|
<A
|
|
HREF="http://landfill.bugzilla.org/"
|
|
TARGET="_top"
|
|
>Landfill</A
|
|
>, which you are
|
|
welcome to play with (if it's up). However, not all of the Bugzilla
|
|
installations there will necessarily have all Bugzilla features enabled,
|
|
and different installations run different versions, so some things may not
|
|
quite work as this document describes.</P
|
|
><P
|
|
> Frequently Asked Questions (FAQ) are available and answered on
|
|
<A
|
|
HREF="http://wiki.mozilla.org/Bugzilla:FAQ"
|
|
TARGET="_top"
|
|
>wiki.mozilla.org</A
|
|
>.
|
|
They may cover some questions you have which are left unanswered.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="myaccount"
|
|
>5.2. Create a Bugzilla Account</A
|
|
></H2
|
|
><P
|
|
>If you want to use Bugzilla, first you need to create an account.
|
|
Consult with the administrator responsible for your installation of
|
|
Bugzilla for the URL you should use to access it. If you're
|
|
test-driving Bugzilla, use this URL:
|
|
<A
|
|
HREF="http://landfill.bugzilla.org/bugzilla-3.6-branch/"
|
|
TARGET="_top"
|
|
>http://landfill.bugzilla.org/bugzilla-3.6-branch/</A
|
|
>.
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> On the home page <TT
|
|
CLASS="filename"
|
|
>index.cgi</TT
|
|
>, click the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Open a new Bugzilla account"</SPAN
|
|
> link, or the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"New Account"</SPAN
|
|
> link available in the footer of pages.
|
|
Now enter your email address, then click the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Send"</SPAN
|
|
>
|
|
button.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If none of these links is available, this means that the
|
|
administrator of the installation has disabled self-registration.
|
|
This means that only an administrator can create accounts
|
|
for other users. One reason could be that this installation is
|
|
private.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Also, if only some users are allowed to create an account on
|
|
the installation, you may see these links but your registration
|
|
may fail if your email address doesn't match the ones accepted
|
|
by the installation. This is another way to restrict who can
|
|
access and edit bugs in this installation.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Within moments, and if your registration is accepted, you should
|
|
receive an email to the address you provided, which contains your
|
|
login name (generally the same as the email address), and two URLs
|
|
with a token (a random string generated by the installation) to
|
|
confirm, respectively cancel, your registration. This is a way to
|
|
prevent users from abusing the generation of user accounts, for
|
|
instance by entering inexistent email addresses, or email addresses
|
|
which do not belong to them.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> By default, you have 3 days to confirm your registration. Past this
|
|
timeframe, the token is invalidated and the registration is
|
|
automatically canceled. You can also cancel this registration sooner
|
|
by using the appropriate URL in the email you got.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> If you confirm your registration, Bugzilla will ask you your real name
|
|
(optional, but recommended) and your password, which must be between
|
|
3 and 16 characters long.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Now all you need to do is to click the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Log In"</SPAN
|
|
>
|
|
link in the footer at the bottom of the page in your browser,
|
|
enter your email address and password you just chose into the
|
|
login form, and click the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Log in"</SPAN
|
|
> button.
|
|
</P
|
|
></LI
|
|
></OL
|
|
><P
|
|
> You are now logged in. Bugzilla uses cookies to remember you are
|
|
logged in so, unless you have cookies disabled or your IP address changes,
|
|
you should not have to log in again during your session.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="bug_page"
|
|
>5.3. Anatomy of a Bug</A
|
|
></H2
|
|
><P
|
|
>The core of Bugzilla is the screen which displays a particular
|
|
bug. It's a good place to explain some Bugzilla concepts.
|
|
<A
|
|
HREF="http://landfill.bugzilla.org/bugzilla-3.6-branch/show_bug.cgi?id=1"
|
|
TARGET="_top"
|
|
> Bug 1 on Landfill</A
|
|
>
|
|
|
|
is a good example. Note that the labels for most fields are hyperlinks;
|
|
clicking them will take you to context-sensitive help on that
|
|
particular field. Fields marked * may not be present on every
|
|
installation of Bugzilla.</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Product and Component</EM
|
|
>:
|
|
Bugs are divided up by Product and Component, with a Product
|
|
having one or more Components in it. For example,
|
|
bugzilla.mozilla.org's "Bugzilla" Product is composed of several
|
|
Components:
|
|
<P
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
><TBODY
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Administration:</EM
|
|
>
|
|
Administration of a Bugzilla installation.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Bugzilla-General:</EM
|
|
>
|
|
Anything that doesn't fit in the other components, or spans
|
|
multiple components.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Creating/Changing Bugs:</EM
|
|
>
|
|
Creating, changing, and viewing bugs.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Documentation:</EM
|
|
>
|
|
The Bugzilla documentation, including The Bugzilla Guide.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Email:</EM
|
|
>
|
|
Anything to do with email sent by Bugzilla.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Installation:</EM
|
|
>
|
|
The installation process of Bugzilla.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Query/Buglist:</EM
|
|
>
|
|
Anything to do with searching for bugs and viewing the
|
|
buglists.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Reporting/Charting:</EM
|
|
>
|
|
Getting reports from Bugzilla.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>User Accounts:</EM
|
|
>
|
|
Anything about managing a user account from the user's perspective.
|
|
Saved queries, creating accounts, changing passwords, logging in,
|
|
etc.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>User Interface:</EM
|
|
>
|
|
General issues having to do with the user interface cosmetics (not
|
|
functionality) including cosmetic issues, HTML templates,
|
|
etc.</TD
|
|
></TR
|
|
></TBODY
|
|
></TABLE
|
|
><P
|
|
></P
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Status and Resolution:</EM
|
|
>
|
|
|
|
These define exactly what state the bug is in - from not even
|
|
being confirmed as a bug, through to being fixed and the fix
|
|
confirmed by Quality Assurance. The different possible values for
|
|
Status and Resolution on your installation should be documented in the
|
|
context-sensitive help for those items.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Assigned To:</EM
|
|
>
|
|
The person responsible for fixing the bug.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>*QA Contact:</EM
|
|
>
|
|
The person responsible for quality assurance on this bug.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>*URL:</EM
|
|
>
|
|
A URL associated with the bug, if any.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Summary:</EM
|
|
>
|
|
A one-sentence summary of the problem.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>*Status Whiteboard:</EM
|
|
>
|
|
(a.k.a. Whiteboard) A free-form text area for adding short notes
|
|
and tags to a bug.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>*Keywords:</EM
|
|
>
|
|
The administrator can define keywords which you can use to tag and
|
|
categorise bugs - e.g. The Mozilla Project has keywords like crash
|
|
and regression.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Platform and OS:</EM
|
|
>
|
|
These indicate the computing environment where the bug was
|
|
found.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Version:</EM
|
|
>
|
|
The "Version" field is usually used for versions of a product which
|
|
have been released, and is set to indicate which versions of a
|
|
Component have the particular problem the bug report is
|
|
about.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Priority:</EM
|
|
>
|
|
The bug assignee uses this field to prioritize his or her bugs.
|
|
It's a good idea not to change this on other people's bugs.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Severity:</EM
|
|
>
|
|
This indicates how severe the problem is - from blocker
|
|
("application unusable") to trivial ("minor cosmetic issue"). You
|
|
can also use this field to indicate whether a bug is an enhancement
|
|
request.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>*Target:</EM
|
|
>
|
|
(a.k.a. Target Milestone) A future version by which the bug is to
|
|
be fixed. e.g. The Bugzilla Project's milestones for future
|
|
Bugzilla versions are 2.18, 2.20, 3.0, etc. Milestones are not
|
|
restricted to numbers, thought - you can use any text strings, such
|
|
as dates.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Reporter:</EM
|
|
>
|
|
The person who filed the bug.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>CC list:</EM
|
|
>
|
|
A list of people who get mail when the bug changes.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>*Time Tracking:</EM
|
|
>
|
|
This form can be used for time tracking.
|
|
To use this feature, you have to be blessed group membership
|
|
specified by the <SPAN
|
|
CLASS="QUOTE"
|
|
>"timetrackinggroup"</SPAN
|
|
> parameter.
|
|
<P
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
><TBODY
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Orig. Est.:</EM
|
|
>
|
|
This field shows the original estimated time.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Current Est.:</EM
|
|
>
|
|
This field shows the current estimated time.
|
|
This number is calculated from <SPAN
|
|
CLASS="QUOTE"
|
|
>"Hours Worked"</SPAN
|
|
>
|
|
and <SPAN
|
|
CLASS="QUOTE"
|
|
>"Hours Left"</SPAN
|
|
>.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Hours Worked:</EM
|
|
>
|
|
This field shows the number of hours worked.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Hours Left:</EM
|
|
>
|
|
This field shows the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Current Est."</SPAN
|
|
> -
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Hours Worked"</SPAN
|
|
>.
|
|
This value + <SPAN
|
|
CLASS="QUOTE"
|
|
>"Hours Worked"</SPAN
|
|
> will become the
|
|
new Current Est.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>%Complete:</EM
|
|
>
|
|
This field shows what percentage of the task is complete.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Gain:</EM
|
|
>
|
|
This field shows the number of hours that the bug is ahead of the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Orig. Est."</SPAN
|
|
>.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Deadline:</EM
|
|
>
|
|
This field shows the deadline for this bug.</TD
|
|
></TR
|
|
></TBODY
|
|
></TABLE
|
|
><P
|
|
></P
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Attachments:</EM
|
|
>
|
|
You can attach files (e.g. testcases or patches) to bugs. If there
|
|
are any attachments, they are listed in this section. Attachments are
|
|
normally stored in the Bugzilla database, unless they are marked as
|
|
Big Files, which are stored directly on disk.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>*Dependencies:</EM
|
|
>
|
|
If this bug cannot be fixed unless other bugs are fixed (depends
|
|
on), or this bug stops other bugs being fixed (blocks), their
|
|
numbers are recorded here.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>*Votes:</EM
|
|
>
|
|
Whether this bug has any votes.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Additional Comments:</EM
|
|
>
|
|
You can add your two cents to the bug discussion here, if you have
|
|
something worthwhile to say.</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="lifecycle"
|
|
>5.4. Life Cycle of a Bug</A
|
|
></H2
|
|
><P
|
|
> The life cycle, also known as work flow, of a bug is currently hardcoded
|
|
into Bugzilla. <A
|
|
HREF="#lifecycle-image"
|
|
>Figure 5-1</A
|
|
> contains a graphical
|
|
representation of this life cycle. If you wish to customize this image for
|
|
your site, the <A
|
|
HREF="../images/bzLifecycle.xml"
|
|
TARGET="_top"
|
|
>diagram file</A
|
|
>
|
|
is available in <A
|
|
HREF="http://www.gnome.org/projects/dia"
|
|
TARGET="_top"
|
|
>Dia's</A
|
|
>
|
|
native XML format.
|
|
</P
|
|
><DIV
|
|
CLASS="figure"
|
|
><A
|
|
NAME="lifecycle-image"
|
|
></A
|
|
><P
|
|
><B
|
|
>Figure 5-1. Lifecycle of a Bugzilla Bug</B
|
|
></P
|
|
><DIV
|
|
CLASS="mediaobject"
|
|
><P
|
|
><IMG
|
|
SRC="../images/bzLifecycle.png"></P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="query"
|
|
>5.5. Searching for Bugs</A
|
|
></H2
|
|
><P
|
|
>The Bugzilla Search page is the interface where you can find
|
|
any bug report, comment, or patch currently in the Bugzilla system. You
|
|
can play with it here:
|
|
<A
|
|
HREF="http://landfill.bugzilla.org/bugzilla-3.6-branch/query.cgi"
|
|
TARGET="_top"
|
|
>http://landfill.bugzilla.org/bugzilla-3.6-branch/query.cgi</A
|
|
>.</P
|
|
><P
|
|
>The Search page has controls for selecting different possible
|
|
values for all of the fields in a bug, as described above. For some
|
|
fields, multiple values can be selected. In those cases, Bugzilla
|
|
returns bugs where the content of the field matches any one of the selected
|
|
values. If none is selected, then the field can take any value.</P
|
|
><P
|
|
> After a search is run, you can save it as a Saved Search, which
|
|
will appear in the page footer. If you are in the group defined
|
|
by the "querysharegroup" parameter, you may share your queries
|
|
with other users, see <A
|
|
HREF="#savedsearches"
|
|
>Saved Searches</A
|
|
> for more details.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="boolean"
|
|
>5.5.1. Boolean Charts</A
|
|
></H3
|
|
><P
|
|
> Highly advanced querying is done using Boolean Charts.
|
|
</P
|
|
><P
|
|
> The boolean charts further restrict the set of results
|
|
returned by a query. It is possible to search for bugs
|
|
based on elaborate combinations of criteria.
|
|
</P
|
|
><P
|
|
> The simplest boolean searches have only one term. These searches
|
|
permit the selected left <EM
|
|
>field</EM
|
|
>
|
|
to be compared using a
|
|
selectable <EM
|
|
>operator</EM
|
|
> to a
|
|
specified <EM
|
|
>value.</EM
|
|
>
|
|
Using the "And," "Or," and "Add Another Boolean Chart" buttons,
|
|
additional terms can be included in the query, further
|
|
altering the list of bugs returned by the query.
|
|
</P
|
|
><P
|
|
> There are three fields in each row of a boolean search.
|
|
</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Field:</EM
|
|
>
|
|
the items being searched
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Operator:</EM
|
|
>
|
|
the comparison operator
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Value:</EM
|
|
>
|
|
the value to which the field is being compared
|
|
</P
|
|
></LI
|
|
></UL
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="pronouns"
|
|
>5.5.1.1. Pronoun Substitution</A
|
|
></H4
|
|
><P
|
|
> Sometimes, a query needs to compare a user-related field
|
|
(such as ReportedBy) with a role-specific user (such as the
|
|
user running the query or the user to whom each bug is assigned).
|
|
When the operator is either "equals" or "notequals", the value
|
|
can be "%reporter%", "%assignee%", "%qacontact%", or "%user%".
|
|
The user pronoun
|
|
refers to the user who is executing the query or, in the case
|
|
of whining reports, the user who will be the recipient
|
|
of the report. The reporter, assignee, and qacontact
|
|
pronouns refer to the corresponding fields in the bug.
|
|
</P
|
|
><P
|
|
> Boolean charts also let you type a group name in any user-related
|
|
field if the operator is either "equals", "notequals" or "anyexact".
|
|
This will let you query for any member belonging (or not) to the
|
|
specified group. The group name must be entered following the
|
|
"%group.foo%" syntax, where "foo" is the group name.
|
|
So if you are looking for bugs reported by any user being in the
|
|
"editbugs" group, then you can type "%group.editbugs%".
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="negation"
|
|
>5.5.1.2. Negation</A
|
|
></H4
|
|
><P
|
|
> At first glance, negation seems redundant. Rather than
|
|
searching for
|
|
<A
|
|
NAME="AEN2493"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> NOT("summary" "contains the string" "foo"),
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
one could search for
|
|
<A
|
|
NAME="AEN2495"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> ("summary" "does not contain the string" "foo").
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
However, the search
|
|
<A
|
|
NAME="AEN2497"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> ("CC" "does not contain the string" "@mozilla.org")
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
would find every bug where anyone on the CC list did not contain
|
|
"@mozilla.org" while
|
|
<A
|
|
NAME="AEN2499"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> NOT("CC" "contains the string" "@mozilla.org")
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
would find every bug where there was nobody on the CC list who
|
|
did contain the string. Similarly, the use of negation also permits
|
|
complex expressions to be built using terms OR'd together and then
|
|
negated. Negation permits queries such as
|
|
<A
|
|
NAME="AEN2501"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> NOT(("product" "equals" "update") OR
|
|
("component" "equals" "Documentation"))
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
to find bugs that are neither
|
|
in the update product or in the documentation component or
|
|
<A
|
|
NAME="AEN2503"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> NOT(("commenter" "equals" "%assignee%") OR
|
|
("component" "equals" "Documentation"))
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
to find non-documentation
|
|
bugs on which the assignee has never commented.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="multiplecharts"
|
|
>5.5.1.3. Multiple Charts</A
|
|
></H4
|
|
><P
|
|
> The terms within a single row of a boolean chart are all
|
|
constraints on a single piece of data. If you are looking for
|
|
a bug that has two different people cc'd on it, then you need
|
|
to use two boolean charts. A search for
|
|
<A
|
|
NAME="AEN2508"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> ("cc" "contains the string" "foo@") AND
|
|
("cc" "contains the string" "@mozilla.org")
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
would return only bugs with "foo@mozilla.org" on the cc list.
|
|
If you wanted bugs where there is someone on the cc list
|
|
containing "foo@" and someone else containing "@mozilla.org",
|
|
then you would need two boolean charts.
|
|
<A
|
|
NAME="AEN2510"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
> First chart: ("cc" "contains the string" "foo@")
|
|
</P
|
|
><P
|
|
> Second chart: ("cc" "contains the string" "@mozilla.org")
|
|
</P
|
|
></BLOCKQUOTE
|
|
>
|
|
The bugs listed will be only the bugs where ALL the charts are true.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="quicksearch"
|
|
>5.5.2. Quicksearch</A
|
|
></H3
|
|
><P
|
|
> Quicksearch is a single-text-box query tool which uses
|
|
metacharacters to indicate what is to be searched. For example, typing
|
|
"<TT
|
|
CLASS="literal"
|
|
>foo|bar</TT
|
|
>"
|
|
into Quicksearch would search for "foo" or "bar" in the
|
|
summary and status whiteboard of a bug; adding
|
|
"<TT
|
|
CLASS="literal"
|
|
>:BazProduct</TT
|
|
>" would
|
|
search only in that product.
|
|
You can use it to find a bug by its number or its alias, too.
|
|
</P
|
|
><P
|
|
> You'll find the Quicksearch box in Bugzilla's footer area.
|
|
On Bugzilla's front page, there is an additional
|
|
<A
|
|
HREF="../../page.cgi?id=quicksearch.html"
|
|
TARGET="_top"
|
|
>Help</A
|
|
>
|
|
link which details how to use it.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="casesensitivity"
|
|
>5.5.3. Case Sensitivity in Searches</A
|
|
></H3
|
|
><P
|
|
> Bugzilla queries are case-insensitive and accent-insensitive, when
|
|
used with either MySQL or Oracle databases. When using Bugzilla with
|
|
PostgreSQL, however, some queries are case-sensitive. This is due to
|
|
the way PostgreSQL handles case and accent sensitivity.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="list"
|
|
>5.5.4. Bug Lists</A
|
|
></H3
|
|
><P
|
|
>If you run a search, a list of matching bugs will be returned.
|
|
</P
|
|
><P
|
|
>The format of the list is configurable. For example, it can be
|
|
sorted by clicking the column headings. Other useful features can be
|
|
accessed using the links at the bottom of the list:
|
|
<P
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
><TBODY
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Long Format:</EM
|
|
>
|
|
|
|
this gives you a large page with a non-editable summary of the fields
|
|
of each bug.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>XML:</EM
|
|
>
|
|
|
|
get the buglist in the XML format.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>CSV:</EM
|
|
>
|
|
|
|
get the buglist as comma-separated values, for import into e.g.
|
|
a spreadsheet.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Feed:</EM
|
|
>
|
|
|
|
get the buglist as an Atom feed. Copy this link into your
|
|
favorite feed reader. If you are using Firefox, you can also
|
|
save the list as a live bookmark by clicking the live bookmark
|
|
icon in the status bar. To limit the number of bugs in the feed,
|
|
add a limit=n parameter to the URL.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>iCalendar:</EM
|
|
>
|
|
|
|
Get the buglist as an iCalendar file. Each bug is represented as a
|
|
to-do item in the imported calendar.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Change Columns:</EM
|
|
>
|
|
|
|
change the bug attributes which appear in the list.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Change several bugs at once:</EM
|
|
>
|
|
|
|
If your account is sufficiently empowered, and more than one bug
|
|
appear in the bug list, this link is displayed which lets you make
|
|
the same change to all the bugs in the list - for example, changing
|
|
their assignee.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Send mail to bug assignees:</EM
|
|
>
|
|
|
|
If more than one bug appear in the bug list and there are at least
|
|
two distinct bug assignees, this links is displayed which lets you
|
|
easily send a mail to the assignees of all bugs on the list.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Edit Search:</EM
|
|
>
|
|
|
|
If you didn't get exactly the results you were looking for, you can
|
|
return to the Query page through this link and make small revisions
|
|
to the query you just made so you get more accurate results.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
> <EM
|
|
>Remember Search As:</EM
|
|
>
|
|
|
|
You can give a search a name and remember it; a link will appear
|
|
in your page footer giving you quick access to run it again later.
|
|
</TD
|
|
></TR
|
|
></TBODY
|
|
></TABLE
|
|
><P
|
|
></P
|
|
>
|
|
</P
|
|
><P
|
|
> If you would like to access the bug list from another program
|
|
it is often useful to have the list returned in something other
|
|
than HTML. By adding the ctype=type parameter into the bug list URL
|
|
you can specify several alternate formats. Besides the types described
|
|
above, the following formats are also supported: ECMAScript, also known
|
|
as JavaScript (ctype=js), and Resource Description Framework RDF/XML
|
|
(ctype=rdf).
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="individual-buglists"
|
|
>5.5.5. Adding/removing tags to/from bugs</A
|
|
></H3
|
|
><P
|
|
> You can add and remove tags from individual bugs, which let you find and
|
|
manage them more easily. Creating a new tag automatically generates a saved
|
|
search - whose name is the name of the tag - which lists bugs with this tag.
|
|
This saved search will be displayed in the footer of pages by default, as
|
|
all other saved searches. The main difference between tags and normal saved
|
|
searches is that saved searches, as described in the previous section, are
|
|
stored in the form of a list of matching criteria, while the saved search
|
|
generated by tags is a list of bug numbers. Consequently, you can easily
|
|
edit this list by either adding or removing tags from bugs. To enable this
|
|
feature, you have to turn on the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Enable tags for bugs"</SPAN
|
|
> user
|
|
preference, see <A
|
|
HREF="#userpreferences"
|
|
>Section 5.10</A
|
|
>. This feature is disabled
|
|
by default.
|
|
</P
|
|
><P
|
|
> This feature is useful when you want to keep track of several bugs, but
|
|
for different reasons. Instead of adding yourself to the CC list of all
|
|
these bugs and mixing all these reasons, you can now store these bugs in
|
|
separate lists, e.g. <SPAN
|
|
CLASS="QUOTE"
|
|
>"Keep in mind"</SPAN
|
|
>, <SPAN
|
|
CLASS="QUOTE"
|
|
>"Interesting bugs"</SPAN
|
|
>,
|
|
or <SPAN
|
|
CLASS="QUOTE"
|
|
>"Triage"</SPAN
|
|
>. One big advantage of this way to manage bugs
|
|
is that you can easily add or remove bugs one by one, which is not
|
|
possible to do with saved searches without having to edit the search
|
|
criteria again.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="bugreports"
|
|
>5.6. Filing Bugs</A
|
|
></H2
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="fillingbugs"
|
|
>5.6.1. Reporting a New Bug</A
|
|
></H3
|
|
><P
|
|
>Years of bug writing experience has been distilled for your
|
|
reading pleasure into the
|
|
<A
|
|
HREF="http://landfill.bugzilla.org/bugzilla-3.6-branch/page.cgi?id=bug-writing.html"
|
|
TARGET="_top"
|
|
> Bug Writing Guidelines</A
|
|
>.
|
|
While some of the advice is Mozilla-specific, the basic principles of
|
|
reporting Reproducible, Specific bugs, isolating the Product you are
|
|
using, the Version of the Product, the Component which failed, the
|
|
Hardware Platform, and Operating System you were using at the time of
|
|
the failure go a long way toward ensuring accurate, responsible fixes
|
|
for the bug that bit you.</P
|
|
><P
|
|
>The procedure for filing a bug is as follows:</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> Click the <SPAN
|
|
CLASS="QUOTE"
|
|
>"New"</SPAN
|
|
> link available in the footer
|
|
of pages, or the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Enter a new bug report"</SPAN
|
|
> link
|
|
displayed on the home page of the Bugzilla installation.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If you want to file a test bug to see how Bugzilla works,
|
|
you can do it on one of our test installations on
|
|
<A
|
|
HREF="http://landfill.bugzilla.org/bugzilla-3.6-branch/"
|
|
TARGET="_top"
|
|
>Landfill</A
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></LI
|
|
><LI
|
|
><P
|
|
> You first have to select the product in which you found a bug.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> You now see a form where you can specify the component (part of
|
|
the product which is affected by the bug you discovered; if you have
|
|
no idea, just select <SPAN
|
|
CLASS="QUOTE"
|
|
>"General"</SPAN
|
|
> if such a component exists),
|
|
the version of the program you were using, the Operating System and
|
|
platform your program is running on and the severity of the bug (if the
|
|
bug you found crashes the program, it's probably a major or a critical
|
|
bug; if it's a typo somewhere, that's something pretty minor; if it's
|
|
something you would like to see implemented, then that's an enhancement).
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> You now have to give a short but descriptive summary of the bug you found.
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"My program is crashing all the time"</SPAN
|
|
> is a very poor summary
|
|
and doesn't help developers at all. Try something more meaningful or
|
|
your bug will probably be ignored due to a lack of precision.
|
|
The next step is to give a very detailed list of steps to reproduce
|
|
the problem you encountered. Try to limit these steps to a minimum set
|
|
required to reproduce the problem. This will make the life of
|
|
developers easier, and the probability that they consider your bug in
|
|
a reasonable timeframe will be much higher.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Try to make sure that everything in the summary is also in the first
|
|
comment. Summaries are often updated and this will ensure your original
|
|
information is easily accessible.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></LI
|
|
><LI
|
|
><P
|
|
> As you file the bug, you can also attach a document (testcase, patch,
|
|
or screenshot of the problem).
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Depending on the Bugzilla installation you are using and the product in
|
|
which you are filing the bug, you can also request developers to consider
|
|
your bug in different ways (such as requesting review for the patch you
|
|
just attached, requesting your bug to block the next release of the
|
|
product, and many other product specific requests).
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Now is a good time to read your bug report again. Remove all misspellings,
|
|
otherwise your bug may not be found by developers running queries for some
|
|
specific words, and so your bug would not get any attention.
|
|
Also make sure you didn't forget any important information developers
|
|
should know in order to reproduce the problem, and make sure your
|
|
description of the problem is explicit and clear enough.
|
|
When you think your bug report is ready to go, the last step is to
|
|
click the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Commit"</SPAN
|
|
> button to add your report into the database.
|
|
</P
|
|
></LI
|
|
></OL
|
|
><P
|
|
> You do not need to put "any" or similar strings in the URL field.
|
|
If there is no specific URL associated with the bug, leave this
|
|
field blank.
|
|
</P
|
|
><P
|
|
>If you feel a bug you filed was incorrectly marked as a
|
|
DUPLICATE of another, please question it in your bug, not
|
|
the bug it was duped to. Feel free to CC the person who duped it
|
|
if they are not already CCed.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="cloningbugs"
|
|
>5.6.2. Clone an Existing Bug</A
|
|
></H3
|
|
><P
|
|
> Starting with version 2.20, Bugzilla has a feature that allows you
|
|
to clone an existing bug. The newly created bug will inherit
|
|
most settings from the old bug. This allows you to track more
|
|
easily similar concerns in a new bug. To use this, go to the bug
|
|
that you want to clone, then click the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Clone This Bug"</SPAN
|
|
>
|
|
link on the bug page. This will take you to the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Enter Bug"</SPAN
|
|
>
|
|
page that is filled with the values that the old bug has.
|
|
You can change those values and/or texts if needed.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="attachments"
|
|
>5.7. Attachments</A
|
|
></H2
|
|
><P
|
|
> You should use attachments, rather than comments, for large chunks of ASCII
|
|
data, such as trace, debugging output files, or log files. That way, it
|
|
doesn't bloat the bug for everyone who wants to read it, and cause people to
|
|
receive fat, useless mails.
|
|
</P
|
|
><P
|
|
>You should make sure to trim screenshots. There's no need to show the
|
|
whole screen if you are pointing out a single-pixel problem.
|
|
</P
|
|
><P
|
|
>Bugzilla stores and uses a Content-Type for each attachment
|
|
(e.g. text/html). To download an attachment as a different
|
|
Content-Type (e.g. application/xhtml+xml), you can override this
|
|
using a 'content_type' parameter on the URL, e.g.
|
|
<TT
|
|
CLASS="filename"
|
|
>&content_type=text/plain</TT
|
|
>.
|
|
</P
|
|
><P
|
|
> If you have a really large attachment, something that does not need to
|
|
be recorded forever (as most attachments are), or something that is too
|
|
big for your database, you can mark your attachment as a
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Big File"</SPAN
|
|
>, assuming the administrator of the installation
|
|
has enabled this feature. Big Files are stored directly on disk instead
|
|
of in the database. The maximum size of a <SPAN
|
|
CLASS="QUOTE"
|
|
>"Big File"</SPAN
|
|
> is
|
|
normally larger than the maximum size of a regular attachment. Independently
|
|
of the storage system used, an administrator can delete these attachments
|
|
at any time. Nevertheless, if these files are stored in the database, the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"allow_attachment_deletion"</SPAN
|
|
> parameter (which is turned off
|
|
by default) must be enabled in order to delete them.
|
|
</P
|
|
><P
|
|
> Also, if the administrator turned on the <SPAN
|
|
CLASS="QUOTE"
|
|
>"allow_attach_url"</SPAN
|
|
>
|
|
parameter, you can enter the URL pointing to the attachment instead of
|
|
uploading the attachment itself. For example, this is useful if you want to
|
|
point to an external application, a website or a very large file. Note that
|
|
there is no guarantee that the source file will always be available, nor
|
|
that its content will remain unchanged.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="patchviewer"
|
|
>5.7.1. Patch Viewer</A
|
|
></H3
|
|
><P
|
|
>Viewing and reviewing patches in Bugzilla is often difficult due to
|
|
lack of context, improper format and the inherent readability issues that
|
|
raw patches present. Patch Viewer is an enhancement to Bugzilla designed
|
|
to fix that by offering increased context, linking to sections, and
|
|
integrating with Bonsai, LXR and CVS.</P
|
|
><P
|
|
>Patch viewer allows you to:</P
|
|
><P
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
><TBODY
|
|
><TR
|
|
><TD
|
|
>View patches in color, with side-by-side view rather than trying
|
|
to interpret the contents of the patch.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>See the difference between two patches.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Get more context in a patch.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Collapse and expand sections of a patch for easy
|
|
reading.</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Link to a particular section of a patch for discussion or
|
|
review</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Go to Bonsai or LXR to see more context, blame, and
|
|
cross-references for the part of the patch you are looking at</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Create a rawtext unified format diff out of any patch, no
|
|
matter what format it came from</TD
|
|
></TR
|
|
></TBODY
|
|
></TABLE
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="patchviewer_view"
|
|
>5.7.1.1. Viewing Patches in Patch Viewer</A
|
|
></H4
|
|
><P
|
|
>The main way to view a patch in patch viewer is to click on the
|
|
"Diff" link next to a patch in the Attachments list on a bug. You may
|
|
also do this within the edit window by clicking the "View Attachment As
|
|
Diff" button in the Edit Attachment screen.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="patchviewer_diff"
|
|
>5.7.1.2. Seeing the Difference Between Two Patches</A
|
|
></H4
|
|
><P
|
|
>To see the difference between two patches, you must first view the
|
|
newer patch in Patch Viewer. Then select the older patch from the
|
|
dropdown at the top of the page ("Differences between [dropdown] and
|
|
this patch") and click the "Diff" button. This will show you what
|
|
is new or changed in the newer patch.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="patchviewer_context"
|
|
>5.7.1.3. Getting More Context in a Patch</A
|
|
></H4
|
|
><P
|
|
>To get more context in a patch, you put a number in the textbox at
|
|
the top of Patch Viewer ("Patch / File / [textbox]") and hit enter.
|
|
This will give you that many lines of context before and after each
|
|
change. Alternatively, you can click on the "File" link there and it
|
|
will show each change in the full context of the file. This feature only
|
|
works against files that were diffed using "cvs diff".</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="patchviewer_collapse"
|
|
>5.7.1.4. Collapsing and Expanding Sections of a Patch</A
|
|
></H4
|
|
><P
|
|
>To view only a certain set of files in a patch (for example, if a
|
|
patch is absolutely huge and you want to only review part of it at a
|
|
time), you can click the "(+)" and "(-)" links next to each file (to
|
|
expand it or collapse it). If you want to collapse all files or expand
|
|
all files, you can click the "Collapse All" and "Expand All" links at the
|
|
top of the page.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="patchviewer_link"
|
|
>5.7.1.5. Linking to a Section of a Patch</A
|
|
></H4
|
|
><P
|
|
>To link to a section of a patch (for example, if you want to be
|
|
able to give someone a URL to show them which part you are talking
|
|
about) you simply click the "Link Here" link on the section header. The
|
|
resulting URL can be copied and used in discussion.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="patchviewer_bonsai_lxr"
|
|
>5.7.1.6. Going to Bonsai and LXR</A
|
|
></H4
|
|
><P
|
|
>To go to Bonsai to get blame for the lines you are interested in,
|
|
you can click the "Lines XX-YY" link on the section header you are
|
|
interested in. This works even if the patch is against an old
|
|
version of the file, since Bonsai stores all versions of the file.</P
|
|
><P
|
|
>To go to LXR, you click on the filename on the file header
|
|
(unfortunately, since LXR only does the most recent version, line
|
|
numbers are likely to rot).</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="patchviewer_unified_diff"
|
|
>5.7.1.7. Creating a Unified Diff</A
|
|
></H4
|
|
><P
|
|
>If the patch is not in a format that you like, you can turn it
|
|
into a unified diff format by clicking the "Raw Unified" link at the top
|
|
of the page.</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="hintsandtips"
|
|
>5.8. Hints and Tips</A
|
|
></H2
|
|
><P
|
|
>This section distills some Bugzilla tips and best practices
|
|
that have been developed.</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN2646"
|
|
>5.8.1. Autolinkification</A
|
|
></H3
|
|
><P
|
|
>Bugzilla comments are plain text - so typing <U> will
|
|
produce less-than, U, greater-than rather than underlined text.
|
|
However, Bugzilla will automatically make hyperlinks out of certain
|
|
sorts of text in comments. For example, the text
|
|
"http://www.bugzilla.org" will be turned into a link:
|
|
<A
|
|
HREF="http://www.bugzilla.org"
|
|
TARGET="_top"
|
|
>http://www.bugzilla.org</A
|
|
>.
|
|
Other strings which get linkified in the obvious manner are:
|
|
<P
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
><TBODY
|
|
><TR
|
|
><TD
|
|
>bug 12345</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>comment 7</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>bug 23456, comment 53</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>attachment 4321</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>mailto:george@example.com</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>george@example.com</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>ftp://ftp.mozilla.org</TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
>Most other sorts of URL</TD
|
|
></TR
|
|
></TBODY
|
|
></TABLE
|
|
><P
|
|
></P
|
|
>
|
|
</P
|
|
><P
|
|
>A corollary here is that if you type a bug number in a comment,
|
|
you should put the word "bug" before it, so it gets autolinkified
|
|
for the convenience of others.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="commenting"
|
|
>5.8.2. Comments</A
|
|
></H3
|
|
><P
|
|
>If you are changing the fields on a bug, only comment if
|
|
either you have something pertinent to say, or Bugzilla requires it.
|
|
Otherwise, you may spam people unnecessarily with bug mail.
|
|
To take an example: a user can set up their account to filter out messages
|
|
where someone just adds themselves to the CC field of a bug
|
|
(which happens a lot.) If you come along, add yourself to the CC field,
|
|
and add a comment saying "Adding self to CC", then that person
|
|
gets a pointless piece of mail they would otherwise have avoided.
|
|
</P
|
|
><P
|
|
> Don't use sigs in comments. Signing your name ("Bill") is acceptable,
|
|
if you do it out of habit, but full mail/news-style
|
|
four line ASCII art creations are not.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="comment-wrapping"
|
|
>5.8.3. Server-Side Comment Wrapping</A
|
|
></H3
|
|
><P
|
|
> Bugzilla stores comments unwrapped and wraps them at display time. This
|
|
ensures proper wrapping in all browsers. Lines beginning with the ">"
|
|
character are assumed to be quotes, and are not wrapped.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="dependencytree"
|
|
>5.8.4. Dependency Tree</A
|
|
></H3
|
|
><P
|
|
> On the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Dependency tree"</SPAN
|
|
> page linked from each bug
|
|
page, you can see the dependency relationship from the bug as a
|
|
tree structure.
|
|
</P
|
|
><P
|
|
> You can change how much depth to show, and you can hide resolved bugs
|
|
from this page. You can also collaps/expand dependencies for
|
|
each bug on the tree view, using the [-]/[+] buttons that appear
|
|
before its summary. This option is not available for terminal
|
|
bugs in the tree (that don't have further dependencies).
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="timetracking"
|
|
>5.9. Time Tracking Information</A
|
|
></H2
|
|
><P
|
|
> Users who belong to the group specified by the <SPAN
|
|
CLASS="QUOTE"
|
|
>"timetrackinggroup"</SPAN
|
|
>
|
|
parameter have access to time-related fields. Developers can see
|
|
deadlines and estimated times to fix bugs, and can provide time spent
|
|
on these bugs.
|
|
</P
|
|
><P
|
|
> At any time, a summary of the time spent by developers on bugs is
|
|
accessible either from bug lists when clicking the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Time Summary"</SPAN
|
|
>
|
|
button or from individual bugs when clicking the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Summarize time"</SPAN
|
|
>
|
|
link in the time tracking table. The <TT
|
|
CLASS="filename"
|
|
>summarize_time.cgi</TT
|
|
>
|
|
page lets you view this information either per developer or per bug,
|
|
and can be split on a month basis to have greater details on how time
|
|
is spent by developers.
|
|
</P
|
|
><P
|
|
> As soon as a bug is marked as RESOLVED, the remaining time expected
|
|
to fix the bug is set to zero. This lets QA people set it again for
|
|
their own usage, and it will be set to zero again when the bug will
|
|
be marked as CLOSED.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="userpreferences"
|
|
>5.10. User Preferences</A
|
|
></H2
|
|
><P
|
|
> Once logged in, you can customize various aspects of
|
|
Bugzilla via the "Preferences" link in the page footer.
|
|
The preferences are split into five tabs:</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="generalpreferences"
|
|
>5.10.1. General Preferences</A
|
|
></H3
|
|
><P
|
|
> This tab allows you to change several default settings of Bugzilla.
|
|
</P
|
|
><P
|
|
></P
|
|
><UL
|
|
COMPACT="COMPACT"
|
|
><LI
|
|
><P
|
|
> Bugzilla's general appearance (skin) - select which skin to use.
|
|
Bugzilla supports adding custom skins.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Quote the associated comment when you click on its reply link - sets
|
|
the behavior of the comment "Reply" link. Options include quoting the
|
|
full comment, just reference the comment number, or turn the link off.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Language used in email - select which language email will be sent in,
|
|
from the list of available languages.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> After changing a bug - This controls what page is displayed after
|
|
changes to a bug are submitted. The options include to show the bug
|
|
just modified, to show the next bug in your list, or to do nothing.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Enable tags for bugs - turn bug tagging on or off.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Zoom textareas large when in use (requires JavaScript) - enable or
|
|
disable the automatic expanding of text areas when text is being
|
|
entered into them.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Field separator character for CSV files -
|
|
Select between a comma and semi-colon for exported CSV bug lists.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Automatically add me to the CC list of bugs I change - set default
|
|
behavior of CC list. Options include "Always", "Never", and "Only
|
|
if I have no role on them".
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> When viewing a bug, show comments in this order -
|
|
controls the order of comments. Options include "Oldest
|
|
to Newest", "Newest to Oldest" and "Newest to Oldest, but keep the
|
|
bug description at the top".
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Show a quip at the top of each bug list - controls
|
|
whether a quip will be shown on the Bug list page.
|
|
</P
|
|
></LI
|
|
></UL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="emailpreferences"
|
|
>5.10.2. Email Preferences</A
|
|
></H3
|
|
><P
|
|
> This tab allows you to enable or disable email notification on
|
|
specific events.
|
|
</P
|
|
><P
|
|
> In general, users have almost complete control over how much (or
|
|
how little) email Bugzilla sends them. If you want to receive the
|
|
maximum amount of email possible, click the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Enable All
|
|
Mail"</SPAN
|
|
> button. If you don't want to receive any email from
|
|
Bugzilla at all, click the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Disable All Mail"</SPAN
|
|
> button.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> A Bugzilla administrator can stop a user from receiving
|
|
bugmail by clicking the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Bugmail Disabled"</SPAN
|
|
> checkbox
|
|
when editing the user account. This is a drastic step
|
|
best taken only for disabled accounts, as it overrides
|
|
the user's individual mail preferences.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> There are two global options -- <SPAN
|
|
CLASS="QUOTE"
|
|
>"Email me when someone
|
|
asks me to set a flag"</SPAN
|
|
> and <SPAN
|
|
CLASS="QUOTE"
|
|
>"Email me when someone
|
|
sets a flag I asked for"</SPAN
|
|
>. These define how you want to
|
|
receive bugmail with regards to flags. Their use is quite
|
|
straightforward; enable the checkboxes if you want Bugzilla to
|
|
send you mail under either of the above conditions.
|
|
</P
|
|
><P
|
|
> If you'd like to set your bugmail to something besides
|
|
'Completely ON' and 'Completely OFF', the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Field/recipient specific options"</SPAN
|
|
> table
|
|
allows you to do just that. The rows of the table
|
|
define events that can happen to a bug -- things like
|
|
attachments being added, new comments being made, the
|
|
priority changing, etc. The columns in the table define
|
|
your relationship with the bug:
|
|
</P
|
|
><P
|
|
></P
|
|
><UL
|
|
COMPACT="COMPACT"
|
|
><LI
|
|
><P
|
|
> Reporter - Where you are the person who initially
|
|
reported the bug. Your name/account appears in the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Reporter:"</SPAN
|
|
> field.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Assignee - Where you are the person who has been
|
|
designated as the one responsible for the bug. Your
|
|
name/account appears in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Assigned To:"</SPAN
|
|
>
|
|
field of the bug.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> QA Contact - You are one of the designated
|
|
QA Contacts for the bug. Your account appears in the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"QA Contact:"</SPAN
|
|
> text-box of the bug.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> CC - You are on the list CC List for the bug.
|
|
Your account appears in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"CC:"</SPAN
|
|
> text box
|
|
of the bug.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Voter - You have placed one or more votes for the bug.
|
|
Your account appears only if someone clicks on the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Show votes for this bug"</SPAN
|
|
> link on the bug.
|
|
</P
|
|
></LI
|
|
></UL
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Some columns may not be visible for your installation, depending
|
|
on your site's configuration.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> To fine-tune your bugmail, decide the events for which you want
|
|
to receive bugmail; then decide if you want to receive it all
|
|
the time (enable the checkbox for every column), or only when
|
|
you have a certain relationship with a bug (enable the checkbox
|
|
only for those columns). For example: if you didn't want to
|
|
receive mail when someone added themselves to the CC list, you
|
|
could uncheck all the boxes in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"CC Field Changes"</SPAN
|
|
>
|
|
line. As another example, if you never wanted to receive email
|
|
on bugs you reported unless the bug was resolved, you would
|
|
un-check all boxes in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Reporter"</SPAN
|
|
> column
|
|
except for the one on the <SPAN
|
|
CLASS="QUOTE"
|
|
>"The bug is resolved or
|
|
verified"</SPAN
|
|
> row.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Bugzilla adds the <SPAN
|
|
CLASS="QUOTE"
|
|
>"X-Bugzilla-Reason"</SPAN
|
|
> header to
|
|
all bugmail it sends, describing the recipient's relationship
|
|
(AssignedTo, Reporter, QAContact, CC, or Voter) to the bug.
|
|
This header can be used to do further client-side filtering.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> Bugzilla has a feature called <SPAN
|
|
CLASS="QUOTE"
|
|
>"Users Watching"</SPAN
|
|
>.
|
|
When you enter one or more comma-delineated user accounts (usually email
|
|
addresses) into the text entry box, you will receive a copy of all the
|
|
bugmail those users are sent (security settings permitting).
|
|
This powerful functionality enables seamless transitions as developers
|
|
change projects or users go on holiday.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> The ability to watch other users may not be available in all
|
|
Bugzilla installations. If you don't see this feature, and feel
|
|
that you need it, speak to your administrator.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> Each user listed in the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Users watching you"</SPAN
|
|
> field
|
|
has you listed in their <SPAN
|
|
CLASS="QUOTE"
|
|
>"Users to watch"</SPAN
|
|
> list
|
|
and can get bugmail according to your relationship to the bug and
|
|
their <SPAN
|
|
CLASS="QUOTE"
|
|
>"Field/recipient specific options"</SPAN
|
|
> setting.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="savedsearches"
|
|
>5.10.3. Saved Searches</A
|
|
></H3
|
|
><P
|
|
> On this tab you can view and run any Saved Searches that you have
|
|
created, and also any Saved Searches that other members of the group
|
|
defined in the "querysharegroup" parameter have shared.
|
|
Saved Searches can be added to the page footer from this screen.
|
|
If somebody is sharing a Search with a group she or he is allowed to
|
|
<A
|
|
HREF="#groups"
|
|
>assign users to</A
|
|
>, the sharer may opt to have
|
|
the Search show up in the footer of the group's direct members by default.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="accountpreferences"
|
|
>5.10.4. Name and Password</A
|
|
></H3
|
|
><P
|
|
>On this tab, you can change your basic account information,
|
|
including your password, email address and real name. For security
|
|
reasons, in order to change anything on this page you must type your
|
|
<EM
|
|
>current</EM
|
|
> password into the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Password"</SPAN
|
|
>
|
|
field at the top of the page.
|
|
If you attempt to change your email address, a confirmation
|
|
email is sent to both the old and new addresses, with a link to use to
|
|
confirm the change. This helps to prevent account hijacking.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="permissionsettings"
|
|
>5.10.5. Permissions</A
|
|
></H3
|
|
><P
|
|
> This is a purely informative page which outlines your current
|
|
permissions on this installation of Bugzilla.
|
|
</P
|
|
><P
|
|
> A complete list of permissions is below. Only users with
|
|
<EM
|
|
>editusers</EM
|
|
> privileges can change the permissions
|
|
of other users.
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
>admin</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user is an Administrator.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>bz_canusewhineatothers</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user can configure whine reports for other users.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>bz_canusewhines</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user can configure whine reports for self.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>bz_sudoers</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user can perform actions as other users.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>bz_sudo_protect</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user can not be impersonated by other users.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>canconfirm</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user can confirm a bug or mark it a duplicate.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>creategroups</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user can create and destroy groups.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>editbugs</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user can edit all bug fields.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>editclassifications</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user can create, destroy, and edit classifications.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>editcomponents</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user can create, destroy, and edit components.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>editkeywords</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user can create, destroy, and edit keywords.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>editusers</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user can edit or disable users.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>tweakparams</DT
|
|
><DD
|
|
><P
|
|
>
|
|
Indicates user can change Parameters.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> For more information on how permissions work in Bugzilla (i.e. who can
|
|
change what), see <A
|
|
HREF="#cust-change-permissions"
|
|
>Section 6.4</A
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="reporting"
|
|
>5.11. Reports and Charts</A
|
|
></H2
|
|
><P
|
|
>As well as the standard buglist, Bugzilla has two more ways of
|
|
viewing sets of bugs. These are the reports (which give different
|
|
views of the current state of the database) and charts (which plot
|
|
the changes in particular sets of bugs over time.)</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="reports"
|
|
>5.11.1. Reports</A
|
|
></H3
|
|
><P
|
|
> A report is a view of the current state of the bug database.
|
|
</P
|
|
><P
|
|
> You can run either an HTML-table-based report, or a graphical
|
|
line/pie/bar-chart-based one. The two have different pages to
|
|
define them, but are close cousins - once you've defined and
|
|
viewed a report, you can switch between any of the different
|
|
views of the data at will.
|
|
</P
|
|
><P
|
|
> Both report types are based on the idea of defining a set of bugs
|
|
using the standard search interface, and then choosing some
|
|
aspect of that set to plot on the horizontal and/or vertical axes.
|
|
You can also get a form of 3-dimensional report by choosing to have
|
|
multiple images or tables.
|
|
</P
|
|
><P
|
|
> So, for example, you could use the search form to choose "all
|
|
bugs in the WorldControl product", and then plot their severity
|
|
against their component to see which component had had the largest
|
|
number of bad bugs reported against it.
|
|
</P
|
|
><P
|
|
> Once you've defined your parameters and hit "Generate Report",
|
|
you can switch between HTML, CSV, Bar, Line and Pie. (Note: Pie
|
|
is only available if you didn't define a vertical axis, as pie
|
|
charts don't have one.) The other controls are fairly self-explanatory;
|
|
you can change the size of the image if you find text is overwriting
|
|
other text, or the bars are too thin to see.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="charts"
|
|
>5.11.2. Charts</A
|
|
></H3
|
|
><P
|
|
> A chart is a view of the state of the bug database over time.
|
|
</P
|
|
><P
|
|
> Bugzilla currently has two charting systems - Old Charts and New
|
|
Charts. Old Charts have been part of Bugzilla for a long time; they
|
|
chart each status and resolution for each product, and that's all.
|
|
They are deprecated, and going away soon - we won't say any more
|
|
about them.
|
|
New Charts are the future - they allow you to chart anything you
|
|
can define as a search.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Both charting forms require the administrator to set up the
|
|
data-gathering script. If you can't see any charts, ask them whether
|
|
they have done so.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> An individual line on a chart is called a data set.
|
|
All data sets are organised into categories and subcategories. The
|
|
data sets that Bugzilla defines automatically use the Product name
|
|
as a Category and Component names as Subcategories, but there is no
|
|
need for you to follow that naming scheme with your own charts if
|
|
you don't want to.
|
|
</P
|
|
><P
|
|
> Data sets may be public or private. Everyone sees public data sets in
|
|
the list, but only their creator sees private data sets. Only
|
|
administrators can make data sets public.
|
|
No two data sets, even two private ones, can have the same set of
|
|
category, subcategory and name. So if you are creating private data
|
|
sets, one idea is to have the Category be your username.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN2843"
|
|
>5.11.2.1. Creating Charts</A
|
|
></H4
|
|
><P
|
|
> You create a chart by selecting a number of data sets from the
|
|
list, and pressing Add To List for each. In the List Of Data Sets
|
|
To Plot, you can define the label that data set will have in the
|
|
chart's legend, and also ask Bugzilla to Sum a number of data sets
|
|
(e.g. you could Sum data sets representing RESOLVED, VERIFIED and
|
|
CLOSED in a particular product to get a data set representing all
|
|
the resolved bugs in that product.)
|
|
</P
|
|
><P
|
|
> If you've erroneously added a data set to the list, select it
|
|
using the checkbox and click Remove. Once you add more than one
|
|
data set, a "Grand Total" line
|
|
automatically appears at the bottom of the list. If you don't want
|
|
this, simply remove it as you would remove any other line.
|
|
</P
|
|
><P
|
|
> You may also choose to plot only over a certain date range, and
|
|
to cumulate the results - that is, to plot each one using the
|
|
previous one as a baseline, so the top line gives a sum of all
|
|
the data sets. It's easier to try than to explain :-)
|
|
</P
|
|
><P
|
|
> Once a data set is in the list, one can also perform certain
|
|
actions on it. For example, one can edit the
|
|
data set's parameters (name, frequency etc.) if it's one you
|
|
created or if you are an administrator.
|
|
</P
|
|
><P
|
|
> Once you are happy, click Chart This List to see the chart.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H4
|
|
CLASS="section"
|
|
><A
|
|
NAME="charts-new-series"
|
|
>5.11.2.2. Creating New Data Sets</A
|
|
></H4
|
|
><P
|
|
> You may also create new data sets of your own. To do this,
|
|
click the "create a new data set" link on the Create Chart page.
|
|
This takes you to a search-like interface where you can define
|
|
the search that Bugzilla will plot. At the bottom of the page,
|
|
you choose the category, sub-category and name of your new
|
|
data set.
|
|
</P
|
|
><P
|
|
> If you have sufficient permissions, you can make the data set public,
|
|
and reduce the frequency of data collection to less than the default
|
|
seven days.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="flags"
|
|
>5.12. Flags</A
|
|
></H2
|
|
><P
|
|
> A flag is a kind of status that can be set on bugs or attachments
|
|
to indicate that the bugs/attachments are in a certain state.
|
|
Each installation can define its own set of flags that can be set
|
|
on bugs or attachments.
|
|
</P
|
|
><P
|
|
> If your installation has defined a flag, you can set or unset that flag,
|
|
and if your administrator has enabled requesting of flags, you can submit
|
|
a request for another user to set the flag.
|
|
</P
|
|
><P
|
|
> To set a flag, select either "+" or "-" from the drop-down menu next to
|
|
the name of the flag in the "Flags" list. The meaning of these values are
|
|
flag-specific and thus cannot be described in this documentation,
|
|
but by way of example, setting a flag named "review" to "+" may indicate
|
|
that the bug/attachment has passed review, while setting it to "-"
|
|
may indicate that the bug/attachment has failed review.
|
|
</P
|
|
><P
|
|
> To unset a flag, click its drop-down menu and select the blank value.
|
|
Note that marking an attachment as obsolete automatically cancels all
|
|
pending requests for the attachment.
|
|
</P
|
|
><P
|
|
> If your administrator has enabled requests for a flag, request a flag
|
|
by selecting "?" from the drop-down menu and then entering the username
|
|
of the user you want to set the flag in the text field next to the menu.
|
|
</P
|
|
><P
|
|
> A set flag appears in bug reports and on "edit attachment" pages with the
|
|
abbreviated username of the user who set the flag prepended to the
|
|
flag name. For example, if Jack sets a "review" flag to "+", it appears
|
|
as Jack: review [ + ]
|
|
</P
|
|
><P
|
|
> A requested flag appears with the user who requested the flag prepended
|
|
to the flag name and the user who has been requested to set the flag
|
|
appended to the flag name within parentheses. For example, if Jack
|
|
asks Jill for review, it appears as Jack: review [ ? ] (Jill).
|
|
</P
|
|
><P
|
|
> You can browse through open requests made of you and by you by selecting
|
|
'My Requests' from the footer. You can also look at open requests limited
|
|
by other requesters, requestees, products, components, and flag names from
|
|
this page. Note that you can use '-' for requestee to specify flags with
|
|
'no requestee' set.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="whining"
|
|
>5.13. Whining</A
|
|
></H2
|
|
><P
|
|
> Whining is a feature in Bugzilla that can regularly annoy users at
|
|
specified times. Using this feature, users can execute saved searches
|
|
at specific times (i.e. the 15th of the month at midnight) or at
|
|
regular intervals (i.e. every 15 minutes on Sundays). The results of the
|
|
searches are sent to the user, either as a single email or as one email
|
|
per bug, along with some descriptive text.
|
|
</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Throughout this section it will be assumed that all users are members
|
|
of the bz_canusewhines group, membership in which is required in order
|
|
to use the Whining system. You can easily make all users members of
|
|
the bz_canusewhines group by setting the User RegExp to ".*" (without
|
|
the quotes).
|
|
</P
|
|
><P
|
|
> Also worth noting is the bz_canusewhineatothers group. Members of this
|
|
group can create whines for any user or group in Bugzilla using a
|
|
extended form of the whining interface. Features only available to
|
|
members of the bz_canusewhineatothers group will be noted in the
|
|
appropriate places.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> For whining to work, a special Perl script must be executed at regular
|
|
intervals. More information on this is available in
|
|
<A
|
|
HREF="#installation-whining"
|
|
>Section 2.3.3</A
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> This section does not cover the whineatnews.pl script. See
|
|
<A
|
|
HREF="#installation-whining-cron"
|
|
>Section 2.3.2</A
|
|
> for more information on
|
|
The Whining Cron.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="whining-overview"
|
|
>5.13.1. The Event</A
|
|
></H3
|
|
><P
|
|
> The whining system defines an "Event" as one or more queries being
|
|
executed at regular intervals, with the results of said queries (if
|
|
there are any) being emailed to the user. Events are created by
|
|
clicking on the "Add new event" button.
|
|
</P
|
|
><P
|
|
> Once a new event is created, the first thing to set is the "Email
|
|
subject line". The contents of this field will be used in the subject
|
|
line of every email generated by this event. In addition to setting a
|
|
subject, space is provided to enter some descriptive text that will be
|
|
included at the top of each message (to help you in understanding why
|
|
you received the email in the first place).
|
|
</P
|
|
><P
|
|
> The next step is to specify when the Event is to be run (the Schedule)
|
|
and what searches are to be performed (the Searches).
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="whining-schedule"
|
|
>5.13.2. Whining Schedule</A
|
|
></H3
|
|
><P
|
|
> Each whining event is associated with zero or more schedules. A
|
|
schedule is used to specify when the query (specified below) is to be
|
|
run. A new event starts out with no schedules (which means it will
|
|
never run, as it is not scheduled to run). To add a schedule, press
|
|
the "Add a new schedule" button.
|
|
</P
|
|
><P
|
|
> Each schedule includes an interval, which you use to tell Bugzilla
|
|
when the event should be run. An event can be run on certain days of
|
|
the week, certain days of the month, during weekdays (defined as
|
|
Monday through Friday), or every day.
|
|
</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Be careful if you set your event to run on the 29th, 30th, or 31st of
|
|
the month, as your event may not run exactly when expected. If you
|
|
want your event to run on the last day of the month, select "Last day
|
|
of the month" as the interval.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> Once you have specified the day(s) on which the event is to be run, you
|
|
should now specify the time at which the event is to be run. You can
|
|
have the event run at a certain hour on the specified day(s), or
|
|
every hour, half-hour, or quarter-hour on the specified day(s).
|
|
</P
|
|
><P
|
|
> If a single schedule does not execute an event as many times as you
|
|
would want, you can create another schedule for the same event. For
|
|
example, if you want to run an event on days whose numbers are
|
|
divisible by seven, you would need to add four schedules to the event,
|
|
setting the schedules to run on the 7th, 14th, 21st, and 28th (one day
|
|
per schedule) at whatever time (or times) you choose.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If you are a member of the bz_canusewhineatothers group, then you
|
|
will be presented with another option: "Mail to". Using this you
|
|
can control who will receive the emails generated by this event. You
|
|
can choose to send the emails to a single user (identified by email
|
|
address) or a single group (identified by group name). To send to
|
|
multiple users or groups, create a new schedule for each additional
|
|
user/group.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="whining-query"
|
|
>5.13.3. Whining Searches</A
|
|
></H3
|
|
><P
|
|
> Each whining event is associated with zero or more searches. A search
|
|
is any saved search to be run as part of the specified schedule (see
|
|
above). You start out without any searches associated with the event
|
|
(which means that the event will not run, as there will never be any
|
|
results to return). To add a search, press the "Include search" button.
|
|
</P
|
|
><P
|
|
> The first field to examine in your newly added search is the Sort field.
|
|
Searches are run, and results included, in the order specified by the
|
|
Sort field. Searches with smaller Sort values will run before searches
|
|
with bigger Sort values.
|
|
</P
|
|
><P
|
|
> The next field to examine is the Search field. This is where you
|
|
choose the actual search that is to be run. Instead of defining search
|
|
parameters here, you are asked to choose from the list of saved
|
|
searches (the same list that appears at the bottom of every Bugzilla
|
|
page). You are only allowed to choose from searches that you have
|
|
saved yourself (the default saved search, "My Bugs", is not a valid
|
|
choice). If you do not have any saved searches, you can take this
|
|
opportunity to create one (see <A
|
|
HREF="#list"
|
|
>Section 5.5.4</A
|
|
>).
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> When running queries, the whining system acts as if you are the user
|
|
executing the query. This means that the whining system will ignore
|
|
bugs that match your query, but that you can not access.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> Once you have chosen the saved search to be executed, give the query a
|
|
descriptive title. This title will appear in the email, above the
|
|
results of the query. If you choose "One message per bug", the query
|
|
title will appear at the top of each email that contains a bug matching
|
|
your query.
|
|
</P
|
|
><P
|
|
> Finally, decide if the results of the query should be sent in a single
|
|
email, or if each bug should appear in its own email.
|
|
</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Think carefully before checking the "One message per bug" box. If
|
|
you create a query that matches thousands of bugs, you will receive
|
|
thousands of emails!
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN2903"
|
|
>5.13.4. Saving Your Changes</A
|
|
></H3
|
|
><P
|
|
> Once you have defined at least one schedule, and created at least one
|
|
query, go ahead and "Update/Commit". This will save your Event and make
|
|
it available for immediate execution.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If you ever feel like deleting your event, you may do so using the
|
|
"Remove Event" button in the upper-right corner of each Event. You
|
|
can also modify an existing event, so long as you "Update/Commit"
|
|
after completing your modifications.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="chapter"
|
|
><HR><H1
|
|
><A
|
|
NAME="customization"
|
|
></A
|
|
>Chapter 6. Customizing Bugzilla</H1
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="extensions"
|
|
>6.1. Bugzilla Extensions</A
|
|
></H2
|
|
><P
|
|
> One of the best ways to customize Bugzilla is by writing a Bugzilla
|
|
Extension. Bugzilla Extensions let you modify both the code and
|
|
UI of Bugzilla in a way that can be distributed to other Bugzilla
|
|
users and ported forward to future versions of Bugzilla with minimal
|
|
effort.
|
|
</P
|
|
><P
|
|
> See the <A
|
|
HREF="api/Bugzilla/Extension.html"
|
|
TARGET="_top"
|
|
>Bugzilla Extension
|
|
documentation</A
|
|
> for information on how to write an Extension.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="cust-skins"
|
|
>6.2. Custom Skins</A
|
|
></H2
|
|
><P
|
|
> Bugzilla allows you to have multiple skins. These are custom CSS and possibly
|
|
also custom images for Bugzilla. To create a new custom skin, you have two
|
|
choices:
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> Make a single CSS file, and put it in the
|
|
<TT
|
|
CLASS="filename"
|
|
>skins/contrib</TT
|
|
> directory.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Make a directory that contains all the same CSS file
|
|
names as <TT
|
|
CLASS="filename"
|
|
>skins/standard/</TT
|
|
>, and put
|
|
your directory in <TT
|
|
CLASS="filename"
|
|
>skins/contrib/</TT
|
|
>.
|
|
</P
|
|
></LI
|
|
></UL
|
|
>
|
|
</P
|
|
><P
|
|
> After you put the file or the directory there, make sure to run checksetup.pl
|
|
so that it can reset the file permissions correctly.
|
|
</P
|
|
><P
|
|
> After you have installed the new skin, it will show up as an option in the
|
|
user's General Preferences. If you would like to force a particular skin on all
|
|
users, just select it in the Default Preferences and then uncheck "Enabled" on
|
|
the preference.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="cust-templates"
|
|
>6.3. Template Customization</A
|
|
></H2
|
|
><P
|
|
> Administrators can configure the look and feel of Bugzilla without
|
|
having to edit Perl files or face the nightmare of massive merge
|
|
conflicts when they upgrade to a newer version in the future.
|
|
</P
|
|
><P
|
|
> Templatization also makes localized versions of Bugzilla possible,
|
|
for the first time. It's possible to have Bugzilla's UI language
|
|
determined by the user's browser. More information is available in
|
|
<A
|
|
HREF="#template-http-accept"
|
|
>Section 6.3.6</A
|
|
>.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="template-directory"
|
|
>6.3.1. Template Directory Structure</A
|
|
></H3
|
|
><P
|
|
> The template directory structure starts with top level directory
|
|
named <TT
|
|
CLASS="filename"
|
|
>template</TT
|
|
>, which contains a directory
|
|
for each installed localization. The next level defines the
|
|
language used in the templates. Bugzilla comes with English
|
|
templates, so the directory name is <TT
|
|
CLASS="filename"
|
|
>en</TT
|
|
>,
|
|
and we will discuss <TT
|
|
CLASS="filename"
|
|
>template/en</TT
|
|
> throughout
|
|
the documentation. Below <TT
|
|
CLASS="filename"
|
|
>template/en</TT
|
|
> is the
|
|
<TT
|
|
CLASS="filename"
|
|
>default</TT
|
|
> directory, which contains all the
|
|
standard templates shipped with Bugzilla.
|
|
</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> A directory <TT
|
|
CLASS="filename"
|
|
>data/templates</TT
|
|
> also exists;
|
|
this is where Template Toolkit puts the compiled versions of
|
|
the templates from either the default or custom directories.
|
|
<EM
|
|
>Do not</EM
|
|
> directly edit the files in this
|
|
directory, or all your changes will be lost the next time
|
|
Template Toolkit recompiles the templates.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="template-method"
|
|
>6.3.2. Choosing a Customization Method</A
|
|
></H3
|
|
><P
|
|
> If you want to edit Bugzilla's templates, the first decision
|
|
you must make is how you want to go about doing so. There are two
|
|
choices, and which you use depends mainly on the scope of your
|
|
modifications, and the method you plan to use to upgrade Bugzilla.
|
|
</P
|
|
><P
|
|
> The first method of making customizations is to directly edit the
|
|
templates found in <TT
|
|
CLASS="filename"
|
|
>template/en/default</TT
|
|
>.
|
|
This is probably the best way to go about it if you are going to
|
|
be upgrading Bugzilla through CVS, because if you then execute
|
|
a <B
|
|
CLASS="command"
|
|
>cvs update</B
|
|
>, any changes you have made will
|
|
be merged automagically with the updated versions.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If you use this method, and CVS conflicts occur during an
|
|
update, the conflicted templates (and possibly other parts
|
|
of your installation) will not work until they are resolved.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> The second method is to copy the templates to be modified
|
|
into a mirrored directory structure under
|
|
<TT
|
|
CLASS="filename"
|
|
>template/en/custom</TT
|
|
>. Templates in this
|
|
directory structure automatically override any identically-named
|
|
and identically-located templates in the
|
|
<TT
|
|
CLASS="filename"
|
|
>default</TT
|
|
> directory.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> The <TT
|
|
CLASS="filename"
|
|
>custom</TT
|
|
> directory does not exist
|
|
at first and must be created if you want to use it.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> The second method of customization should be used if you
|
|
use the overwriting method of upgrade, because otherwise
|
|
your changes will be lost. This method may also be better if
|
|
you are using the CVS method of upgrading and are going to make major
|
|
changes, because it is guaranteed that the contents of this directory
|
|
will not be touched during an upgrade, and you can then decide whether
|
|
to continue using your own templates, or make the effort to merge your
|
|
changes into the new versions by hand.
|
|
</P
|
|
><P
|
|
> Using this method, your installation may break if incompatible
|
|
changes are made to the template interface. Such changes should
|
|
be documented in the release notes, provided you are using a
|
|
stable release of Bugzilla. If you use using unstable code, you will
|
|
need to deal with this one yourself, although if possible the changes
|
|
will be mentioned before they occur in the deprecations section of the
|
|
previous stable release's release notes.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Regardless of which method you choose, it is recommended that
|
|
you run <B
|
|
CLASS="command"
|
|
>./checksetup.pl</B
|
|
> after
|
|
editing any templates in the <TT
|
|
CLASS="filename"
|
|
>template/en/default</TT
|
|
>
|
|
directory, and after creating or editing any templates in the
|
|
<TT
|
|
CLASS="filename"
|
|
>custom</TT
|
|
> directory.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> It is <EM
|
|
>required</EM
|
|
> that you run
|
|
<B
|
|
CLASS="command"
|
|
>./checksetup.pl</B
|
|
> after creating a new
|
|
template in the <TT
|
|
CLASS="filename"
|
|
>custom</TT
|
|
> directory. Failure
|
|
to do so will raise an incomprehensible error message.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="template-edit"
|
|
>6.3.3. How To Edit Templates</A
|
|
></H3
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If you are making template changes that you intend on submitting back
|
|
for inclusion in standard Bugzilla, you should read the relevant
|
|
sections of the
|
|
<A
|
|
HREF="http://www.bugzilla.org/docs/developer.html"
|
|
TARGET="_top"
|
|
>Developers'
|
|
Guide</A
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> The syntax of the Template Toolkit language is beyond the scope of
|
|
this guide. It's reasonably easy to pick up by looking at the current
|
|
templates; or, you can read the manual, available on the
|
|
<A
|
|
HREF="http://www.template-toolkit.org"
|
|
TARGET="_top"
|
|
>Template Toolkit home
|
|
page</A
|
|
>.
|
|
</P
|
|
><P
|
|
> One thing you should take particular care about is the need
|
|
to properly HTML filter data that has been passed into the template.
|
|
This means that if the data can possibly contain special HTML characters
|
|
such as <, and the data was not intended to be HTML, they need to be
|
|
converted to entity form, i.e. &lt;. You use the 'html' filter in the
|
|
Template Toolkit to do this. If you forget, you may open up
|
|
your installation to cross-site scripting attacks.
|
|
</P
|
|
><P
|
|
> Also note that Bugzilla adds a few filters of its own, that are not
|
|
in standard Template Toolkit. In particular, the 'url_quote' filter
|
|
can convert characters that are illegal or have special meaning in URLs,
|
|
such as &, to the encoded form, i.e. %26. This actually encodes most
|
|
characters (but not the common ones such as letters and numbers and so
|
|
on), including the HTML-special characters, so there's never a need to
|
|
HTML filter afterwards.
|
|
</P
|
|
><P
|
|
> Editing templates is a good way of doing a <SPAN
|
|
CLASS="QUOTE"
|
|
>"poor man's custom
|
|
fields"</SPAN
|
|
>.
|
|
For example, if you don't use the Status Whiteboard, but want to have
|
|
a free-form text entry box for <SPAN
|
|
CLASS="QUOTE"
|
|
>"Build Identifier"</SPAN
|
|
>,
|
|
then you can just
|
|
edit the templates to change the field labels. It's still be called
|
|
status_whiteboard internally, but your users don't need to know that.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="template-formats"
|
|
>6.3.4. Template Formats and Types</A
|
|
></H3
|
|
><P
|
|
> Some CGI's have the ability to use more than one template. For example,
|
|
<TT
|
|
CLASS="filename"
|
|
>buglist.cgi</TT
|
|
> can output itself as RDF, or as two
|
|
formats of HTML (complex and simple). The mechanism that provides this
|
|
feature is extensible.
|
|
</P
|
|
><P
|
|
> Bugzilla can support different types of output, which again can have
|
|
multiple formats. In order to request a certain type, you can append
|
|
the &ctype=<contenttype> (such as rdf or html) to the
|
|
<TT
|
|
CLASS="filename"
|
|
><cginame>.cgi</TT
|
|
> URL. If you would like to
|
|
retrieve a certain format, you can use the &format=<format>
|
|
(such as simple or complex) in the URL.
|
|
</P
|
|
><P
|
|
> To see if a CGI supports multiple output formats and types, grep the
|
|
CGI for <SPAN
|
|
CLASS="QUOTE"
|
|
>"get_format"</SPAN
|
|
>. If it's not present, adding
|
|
multiple format/type support isn't too hard - see how it's done in
|
|
other CGIs, e.g. config.cgi.
|
|
</P
|
|
><P
|
|
> To make a new format template for a CGI which supports this,
|
|
open a current template for
|
|
that CGI and take note of the INTERFACE comment (if present.) This
|
|
comment defines what variables are passed into this template. If
|
|
there isn't one, I'm afraid you'll have to read the template and
|
|
the code to find out what information you get.
|
|
</P
|
|
><P
|
|
> Write your template in whatever markup or text style is appropriate.
|
|
</P
|
|
><P
|
|
> You now need to decide what content type you want your template
|
|
served as. The content types are defined in the
|
|
<TT
|
|
CLASS="filename"
|
|
>Bugzilla/Constants.pm</TT
|
|
> file in the
|
|
<TT
|
|
CLASS="filename"
|
|
>contenttypes</TT
|
|
>
|
|
constant. If your content type is not there, add it. Remember
|
|
the three- or four-letter tag assigned to your content type.
|
|
This tag will be part of the template filename.
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> After adding or changing a content type, it's suitable to edit
|
|
<TT
|
|
CLASS="filename"
|
|
>Bugzilla/Constants.pm</TT
|
|
> in order to reflect
|
|
the changes. Also, the file should be kept up to date after an
|
|
upgrade if content types have been customized in the past.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> Save the template as <TT
|
|
CLASS="filename"
|
|
><stubname>-<formatname>.<contenttypetag>.tmpl</TT
|
|
>.
|
|
Try out the template by calling the CGI as
|
|
<TT
|
|
CLASS="filename"
|
|
><cginame>.cgi?format=<formatname>&ctype=<type></TT
|
|
> .
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="template-specific"
|
|
>6.3.5. Particular Templates</A
|
|
></H3
|
|
><P
|
|
> There are a few templates you may be particularly interested in
|
|
customizing for your installation.
|
|
</P
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>index.html.tmpl</B
|
|
>:
|
|
This is the Bugzilla front page.
|
|
</P
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>global/header.html.tmpl</B
|
|
>:
|
|
This defines the header that goes on all Bugzilla pages.
|
|
The header includes the banner, which is what appears to users
|
|
and is probably what you want to edit instead. However the
|
|
header also includes the HTML HEAD section, so you could for
|
|
example add a stylesheet or META tag by editing the header.
|
|
</P
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>global/banner.html.tmpl</B
|
|
>:
|
|
This contains the <SPAN
|
|
CLASS="QUOTE"
|
|
>"banner"</SPAN
|
|
>, the part of the header
|
|
that appears
|
|
at the top of all Bugzilla pages. The default banner is reasonably
|
|
barren, so you'll probably want to customize this to give your
|
|
installation a distinctive look and feel. It is recommended you
|
|
preserve the Bugzilla version number in some form so the version
|
|
you are running can be determined, and users know what docs to read.
|
|
</P
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>global/footer.html.tmpl</B
|
|
>:
|
|
This defines the footer that goes on all Bugzilla pages. Editing
|
|
this is another way to quickly get a distinctive look and feel for
|
|
your Bugzilla installation.
|
|
</P
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>global/variables.none.tmpl</B
|
|
>:
|
|
This defines a list of terms that may be changed in order to
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"brand"</SPAN
|
|
> the Bugzilla instance In this way, terms
|
|
like <SPAN
|
|
CLASS="QUOTE"
|
|
>"bugs"</SPAN
|
|
> can be replaced with <SPAN
|
|
CLASS="QUOTE"
|
|
>"issues"</SPAN
|
|
>
|
|
across the whole Bugzilla installation. The name
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Bugzilla"</SPAN
|
|
> and other words can be customized as well.
|
|
</P
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>list/table.html.tmpl</B
|
|
>:
|
|
This template controls the appearance of the bug lists created
|
|
by Bugzilla. Editing this template allows per-column control of
|
|
the width and title of a column, the maximum display length of
|
|
each entry, and the wrap behaviour of long entries.
|
|
For long bug lists, Bugzilla inserts a 'break' every 100 bugs by
|
|
default; this behaviour is also controlled by this template, and
|
|
that value can be modified here.
|
|
</P
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>bug/create/user-message.html.tmpl</B
|
|
>:
|
|
This is a message that appears near the top of the bug reporting page.
|
|
By modifying this, you can tell your users how they should report
|
|
bugs.
|
|
</P
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>bug/process/midair.html.tmpl</B
|
|
>:
|
|
This is the page used if two people submit simultaneous changes to the
|
|
same bug. The second person to submit their changes will get this page
|
|
to tell them what the first person did, and ask if they wish to
|
|
overwrite those changes or go back and revisit the bug. The default
|
|
title and header on this page read "Mid-air collision detected!" If
|
|
you work in the aviation industry, or other environment where this
|
|
might be found offensive (yes, we have true stories of this happening)
|
|
you'll want to change this to something more appropriate for your
|
|
environment.
|
|
</P
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>bug/create/create.html.tmpl</B
|
|
> and
|
|
<B
|
|
CLASS="command"
|
|
>bug/create/comment.txt.tmpl</B
|
|
>:
|
|
You may not wish to go to the effort of creating custom fields in
|
|
Bugzilla, yet you want to make sure that each bug report contains
|
|
a number of pieces of important information for which there is not
|
|
a special field. The bug entry system has been designed in an
|
|
extensible fashion to enable you to add arbitrary HTML widgets,
|
|
such as drop-down lists or textboxes, to the bug entry page
|
|
and have their values appear formatted in the initial comment.
|
|
A hidden field that indicates the format should be added inside
|
|
the form in order to make the template functional. Its value should
|
|
be the suffix of the template filename. For example, if the file
|
|
is called <TT
|
|
CLASS="filename"
|
|
>create-cust.html.tmpl</TT
|
|
>, then
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
><input type="hidden" name="format" value="cust"></PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
should be used inside the form.
|
|
</P
|
|
><P
|
|
>
|
|
An example of this is the mozilla.org
|
|
<A
|
|
HREF="http://landfill.bugzilla.org/bugzilla-tip/enter_bug.cgi?product=WorldControl&format=guided"
|
|
TARGET="_top"
|
|
>guided
|
|
bug submission form</A
|
|
>. The code for this comes with the Bugzilla
|
|
distribution as an example for you to copy. It can be found in the
|
|
files
|
|
<TT
|
|
CLASS="filename"
|
|
>create-guided.html.tmpl</TT
|
|
> and
|
|
<TT
|
|
CLASS="filename"
|
|
>comment-guided.html.tmpl</TT
|
|
>.
|
|
</P
|
|
><P
|
|
> So to use this feature, create a custom template for
|
|
<TT
|
|
CLASS="filename"
|
|
>enter_bug.cgi</TT
|
|
>. The default template, on which you
|
|
could base it, is
|
|
<TT
|
|
CLASS="filename"
|
|
>custom/bug/create/create.html.tmpl</TT
|
|
>.
|
|
Call it <TT
|
|
CLASS="filename"
|
|
>create-<formatname>.html.tmpl</TT
|
|
>, and
|
|
in it, add widgets for each piece of information you'd like
|
|
collected - such as a build number, or set of steps to reproduce.
|
|
</P
|
|
><P
|
|
> Then, create a template like
|
|
<TT
|
|
CLASS="filename"
|
|
>custom/bug/create/comment.txt.tmpl</TT
|
|
>, and call it
|
|
<TT
|
|
CLASS="filename"
|
|
>comment-<formatname>.txt.tmpl</TT
|
|
>. This
|
|
template should reference the form fields you have created using
|
|
the syntax <TT
|
|
CLASS="filename"
|
|
>[% form.<fieldname> %]</TT
|
|
>. When a
|
|
bug report is
|
|
submitted, the initial comment attached to the bug report will be
|
|
formatted according to the layout of this template.
|
|
</P
|
|
><P
|
|
> For example, if your custom enter_bug template had a field
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
><input type="text" name="buildid" size="30"></PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
and then your comment.txt.tmpl had
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>BuildID: [% form.buildid %]</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
then something like
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>BuildID: 20020303</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
would appear in the initial comment.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="template-http-accept"
|
|
>6.3.6. Configuring Bugzilla to Detect the User's Language</A
|
|
></H3
|
|
><P
|
|
>Bugzilla honours the user's Accept: HTTP header. You can install
|
|
templates in other languages, and Bugzilla will pick the most appropriate
|
|
according to a priority order defined by you. Many
|
|
language templates can be obtained from <A
|
|
HREF="http://www.bugzilla.org/download.html#localizations"
|
|
TARGET="_top"
|
|
>http://www.bugzilla.org/download.html#localizations</A
|
|
>. Instructions
|
|
for submitting new languages are also available from that location.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="cust-change-permissions"
|
|
>6.4. Customizing Who Can Change What</A
|
|
></H2
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> This feature should be considered experimental; the Bugzilla code you
|
|
will be changing is not stable, and could change or move between
|
|
versions. Be aware that if you make modifications as outlined here,
|
|
you may have
|
|
to re-make them or port them if Bugzilla changes internally between
|
|
versions, and you upgrade.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> Companies often have rules about which employees, or classes of employees,
|
|
are allowed to change certain things in the bug system. For example,
|
|
only the bug's designated QA Contact may be allowed to VERIFY the bug.
|
|
Bugzilla has been
|
|
designed to make it easy for you to write your own custom rules to define
|
|
who is allowed to make what sorts of value transition.
|
|
</P
|
|
><P
|
|
> By default, assignees, QA owners and users
|
|
with <EM
|
|
>editbugs</EM
|
|
> privileges can edit all fields of bugs,
|
|
except group restrictions (unless they are members of the groups they
|
|
are trying to change). Bug reporters also have the ability to edit some
|
|
fields, but in a more restrictive manner. Other users, without
|
|
<EM
|
|
>editbugs</EM
|
|
> privileges, can not edit
|
|
bugs, except to comment and add themselves to the CC list.
|
|
</P
|
|
><P
|
|
> For maximum flexibility, customizing this means editing Bugzilla's Perl
|
|
code. This gives the administrator complete control over exactly who is
|
|
allowed to do what. The relevant method is called
|
|
<TT
|
|
CLASS="filename"
|
|
>check_can_change_field()</TT
|
|
>,
|
|
and is found in <TT
|
|
CLASS="filename"
|
|
>Bug.pm</TT
|
|
> in your
|
|
Bugzilla/ directory. If you open that file and search for
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"sub check_can_change_field"</SPAN
|
|
>, you'll find it.
|
|
</P
|
|
><P
|
|
> This function has been carefully commented to allow you to see exactly
|
|
how it works, and give you an idea of how to make changes to it.
|
|
Certain marked sections should not be changed - these are
|
|
the <SPAN
|
|
CLASS="QUOTE"
|
|
>"plumbing"</SPAN
|
|
> which makes the rest of the function work.
|
|
In between those sections, you'll find snippets of code like:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> # Allow the assignee to change anything.
|
|
if ($ownerid eq $whoid) {
|
|
return 1;
|
|
}</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
It's fairly obvious what this piece of code does.
|
|
</P
|
|
><P
|
|
> So, how does one go about changing this function? Well, simple changes
|
|
can be made just by removing pieces - for example, if you wanted to
|
|
prevent any user adding a comment to a bug, just remove the lines marked
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Allow anyone to change comments."</SPAN
|
|
> If you don't want the
|
|
Reporter to have any special rights on bugs they have filed, just
|
|
remove the entire section that deals with the Reporter.
|
|
</P
|
|
><P
|
|
> More complex customizations are not much harder. Basically, you add
|
|
a check in the right place in the function, i.e. after all the variables
|
|
you are using have been set up. So, don't look at $ownerid before
|
|
$ownerid has been obtained from the database. You can either add a
|
|
positive check, which returns 1 (allow) if certain conditions are true,
|
|
or a negative check, which returns 0 (deny.) E.g.:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> if ($field eq "qacontact") {
|
|
if (Bugzilla->user->in_group("quality_assurance")) {
|
|
return 1;
|
|
}
|
|
else {
|
|
return 0;
|
|
}
|
|
}</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
This says that only users in the group "quality_assurance" can change
|
|
the QA Contact field of a bug.
|
|
</P
|
|
><P
|
|
> Getting more weird:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> if (($field eq "priority") &&
|
|
(Bugzilla->user->email =~ /.*\@example\.com$/))
|
|
{
|
|
if ($oldvalue eq "P1") {
|
|
return 1;
|
|
}
|
|
else {
|
|
return 0;
|
|
}
|
|
}</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
This says that if the user is trying to change the priority field,
|
|
and their email address is @example.com, they can only do so if the
|
|
old value of the field was "P1". Not very useful, but illustrative.
|
|
</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> If you are modifying <TT
|
|
CLASS="filename"
|
|
>process_bug.cgi</TT
|
|
> in any
|
|
way, do not change the code that is bounded by DO_NOT_CHANGE blocks.
|
|
Doing so could compromise security, or cause your installation to
|
|
stop working entirely.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> For a list of possible field names, look at the bugs table in the
|
|
database. If you need help writing custom rules for your organization,
|
|
ask in the newsgroup.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="integration"
|
|
>6.5. Integrating Bugzilla with Third-Party Tools</A
|
|
></H2
|
|
><P
|
|
> Many utilities and applications can integrate with Bugzilla,
|
|
either on the client- or server-side. None of them are maintained
|
|
by the Bugzilla community, nor are they tested during our
|
|
QA tests, so use them at your own risk. They are listed at
|
|
<A
|
|
HREF="https://wiki.mozilla.org/Bugzilla:Addons"
|
|
TARGET="_top"
|
|
>https://wiki.mozilla.org/Bugzilla:Addons</A
|
|
>.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="appendix"
|
|
><HR><H1
|
|
><A
|
|
NAME="troubleshooting"
|
|
></A
|
|
>Appendix A. Troubleshooting</H1
|
|
><P
|
|
>This section gives solutions to common Bugzilla installation
|
|
problems. If none of the section headings seems to match your
|
|
problem, read the general advice.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="general-advice"
|
|
>A.1. General Advice</A
|
|
></H2
|
|
><P
|
|
>If you can't get <TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> to run to
|
|
completion, it normally explains what's wrong and how to fix it.
|
|
If you can't work it out, or if it's being uncommunicative, post
|
|
the errors in the
|
|
<A
|
|
HREF="news://news.mozilla.org/mozilla.support.bugzilla"
|
|
TARGET="_top"
|
|
>mozilla.support.bugzilla</A
|
|
>
|
|
newsgroup.
|
|
</P
|
|
><P
|
|
>If you have made it all the way through
|
|
<A
|
|
HREF="#installation"
|
|
>Section 2.1</A
|
|
> (Installation) and
|
|
<A
|
|
HREF="#configuration"
|
|
>Section 2.2</A
|
|
> (Configuration) but accessing the Bugzilla
|
|
URL doesn't work, the first thing to do is to check your web server error
|
|
log. For Apache, this is often located at
|
|
<TT
|
|
CLASS="filename"
|
|
>/etc/logs/httpd/error_log</TT
|
|
>. The error messages
|
|
you see may be self-explanatory enough to enable you to diagnose and
|
|
fix the problem. If not, see below for some commonly-encountered
|
|
errors. If that doesn't help, post the errors to the newsgroup.
|
|
</P
|
|
><P
|
|
> Bugzilla can also log all user-based errors (and many code-based errors)
|
|
that occur, without polluting the web server's error log. To enable
|
|
Bugzilla error logging, create a file that Bugzilla can write to, named
|
|
<TT
|
|
CLASS="filename"
|
|
>errorlog</TT
|
|
>, in the Bugzilla <TT
|
|
CLASS="filename"
|
|
>data</TT
|
|
>
|
|
directory. Errors will be logged as they occur, and will include the type
|
|
of the error, the IP address and username (if available) of the user who
|
|
triggered the error, and the values of all environment variables; if a
|
|
form was being submitted, the data in the form will also be included.
|
|
To disable error logging, delete or rename the
|
|
<TT
|
|
CLASS="filename"
|
|
>errorlog</TT
|
|
> file.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="trbl-testserver"
|
|
>A.2. The Apache web server is not serving Bugzilla pages</A
|
|
></H2
|
|
><P
|
|
>After you have run <B
|
|
CLASS="command"
|
|
>checksetup.pl</B
|
|
> twice,
|
|
run <B
|
|
CLASS="command"
|
|
>testserver.pl http://yoursite.yourdomain/yoururl</B
|
|
>
|
|
to confirm that your web server is configured properly for
|
|
Bugzilla.
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> <SAMP
|
|
CLASS="prompt"
|
|
>bash$</SAMP
|
|
> ./testserver.pl http://landfill.bugzilla.org/bugzilla-tip
|
|
TEST-OK Webserver is running under group id in $webservergroup.
|
|
TEST-OK Got ant picture.
|
|
TEST-OK Webserver is executing CGIs.
|
|
TEST-OK Webserver is preventing fetch of http://landfill.bugzilla.org/bugzilla-tip/localconfig.
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="trbl-perlmodule"
|
|
>A.3. I installed a Perl module, but
|
|
<TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
> claims it's not installed!</A
|
|
></H2
|
|
><P
|
|
>This could be caused by one of two things:</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>You have two versions of Perl on your machine. You are installing
|
|
modules into one, and Bugzilla is using the other. Rerun the CPAN
|
|
commands (or manual compile) using the full path to Perl from the
|
|
top of <TT
|
|
CLASS="filename"
|
|
>checksetup.pl</TT
|
|
>. This will make sure you
|
|
are installing the modules in the right place.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The permissions on your library directories are set incorrectly.
|
|
They must, at the very least, be readable by the web server user or
|
|
group. It is recommended that they be world readable.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="trbl-dbdSponge"
|
|
>A.4. DBD::Sponge::db prepare failed</A
|
|
></H2
|
|
><P
|
|
>The following error message may appear due to a bug in DBD::mysql
|
|
(over which the Bugzilla team have no control):
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> DBD::Sponge::db prepare failed: Cannot determine NUM_OF_FIELDS at D:/Perl/site/lib/DBD/mysql.pm line 248.
|
|
SV = NULL(0x0) at 0x20fc444
|
|
REFCNT = 1
|
|
FLAGS = (PADBUSY,PADMY)
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>To fix this, go to
|
|
<TT
|
|
CLASS="filename"
|
|
><path-to-perl>/lib/DBD/sponge.pm</TT
|
|
>
|
|
in your Perl installation and replace
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> my $numFields;
|
|
if ($attribs->{'NUM_OF_FIELDS'}) {
|
|
$numFields = $attribs->{'NUM_OF_FIELDS'};
|
|
} elsif ($attribs->{'NAME'}) {
|
|
$numFields = @{$attribs->{NAME}};
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>with</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> my $numFields;
|
|
if ($attribs->{'NUM_OF_FIELDS'}) {
|
|
$numFields = $attribs->{'NUM_OF_FIELDS'};
|
|
} elsif ($attribs->{'NAMES'}) {
|
|
$numFields = @{$attribs->{NAMES}};
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>(note the S added to NAME.)</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="paranoid-security"
|
|
>A.5. cannot chdir(/var/spool/mqueue)</A
|
|
></H2
|
|
><P
|
|
>If you are installing Bugzilla on SuSE Linux, or some other
|
|
distributions with <SPAN
|
|
CLASS="QUOTE"
|
|
>"paranoid"</SPAN
|
|
> security options, it is
|
|
possible that the checksetup.pl script may fail with the error:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
>cannot chdir(/var/spool/mqueue): Permission denied
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
</P
|
|
><P
|
|
>This is because your <TT
|
|
CLASS="filename"
|
|
>/var/spool/mqueue</TT
|
|
>
|
|
directory has a mode of <SAMP
|
|
CLASS="computeroutput"
|
|
>drwx------</SAMP
|
|
>.
|
|
Type <B
|
|
CLASS="command"
|
|
>chmod 755 <TT
|
|
CLASS="filename"
|
|
>/var/spool/mqueue</TT
|
|
></B
|
|
>
|
|
as root to fix this problem. This will allow any process running on your
|
|
machine the ability to <EM
|
|
>read</EM
|
|
> the
|
|
<TT
|
|
CLASS="filename"
|
|
>/var/spool/mqueue</TT
|
|
> directory.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="trbl-relogin-everyone"
|
|
>A.6. Everybody is constantly being forced to relogin</A
|
|
></H2
|
|
><P
|
|
>The most-likely cause is that the <SPAN
|
|
CLASS="QUOTE"
|
|
>"cookiepath"</SPAN
|
|
> parameter
|
|
is not set correctly in the Bugzilla configuration. You can change this (if
|
|
you're a Bugzilla administrator) from the editparams.cgi page via the web interface.
|
|
</P
|
|
><P
|
|
>The value of the cookiepath parameter should be the actual directory
|
|
containing your Bugzilla installation, <EM
|
|
>as seen by the end-user's
|
|
web browser</EM
|
|
>. Leading and trailing slashes are mandatory. You can
|
|
also set the cookiepath to any directory which is a parent of the Bugzilla
|
|
directory (such as '/', the root directory). But you can't put something
|
|
that isn't at least a partial match or it won't work. What you're actually
|
|
doing is restricting the end-user's browser to sending the cookies back only
|
|
to that directory.
|
|
</P
|
|
><P
|
|
>How do you know if you want your specific Bugzilla directory or the
|
|
whole site?
|
|
</P
|
|
><P
|
|
>If you have only one Bugzilla running on the server, and you don't
|
|
mind having other applications on the same server with it being able to see
|
|
the cookies (you might be doing this on purpose if you have other things on
|
|
your site that share authentication with Bugzilla), then you'll want to have
|
|
the cookiepath set to "/", or to a sufficiently-high enough directory that
|
|
all of the involved apps can see the cookies.
|
|
</P
|
|
><DIV
|
|
CLASS="example"
|
|
><A
|
|
NAME="trbl-relogin-everyone-share"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example A-1. Examples of urlbase/cookiepath pairs for sharing login cookies</B
|
|
></P
|
|
><A
|
|
NAME="AEN3145"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
CLASS="literallayout"
|
|
><br>
|
|
urlbase is <A
|
|
HREF="http://bugzilla.mozilla.org/"
|
|
TARGET="_top"
|
|
>http://bugzilla.mozilla.org/</A
|
|
><br>
|
|
cookiepath is /<br>
|
|
<br>
|
|
urlbase is <A
|
|
HREF="http://tools.mysite.tld/bugzilla/"
|
|
TARGET="_top"
|
|
>http://tools.mysite.tld/bugzilla/</A
|
|
><br>
|
|
but you have http://tools.mysite.tld/someotherapp/ which shares<br>
|
|
authentication with your Bugzilla<br>
|
|
cookiepath is /<br>
|
|
</P
|
|
></BLOCKQUOTE
|
|
></DIV
|
|
><P
|
|
>On the other hand, if you have more than one Bugzilla running on the
|
|
server (some people do - we do on landfill) then you need to have the
|
|
cookiepath restricted enough so that the different Bugzillas don't
|
|
confuse their cookies with one another.
|
|
</P
|
|
><DIV
|
|
CLASS="example"
|
|
><A
|
|
NAME="trbl-relogin-everyone-restrict"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example A-2. Examples of urlbase/cookiepath pairs to restrict the login cookie</B
|
|
></P
|
|
><A
|
|
NAME="AEN3152"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
CLASS="literallayout"
|
|
><br>
|
|
urlbase is <A
|
|
HREF="http://landfill.bugzilla.org/bugzilla-tip/"
|
|
TARGET="_top"
|
|
>http://landfill.bugzilla.org/bugzilla-tip/</A
|
|
><br>
|
|
cookiepath is /bugzilla-tip/<br>
|
|
<br>
|
|
urlbase is <A
|
|
HREF="http://landfill.bugzilla.org/bugzilla-2.16-branch/"
|
|
TARGET="_top"
|
|
>http://landfill.bugzilla.org/bugzilla-2.16-branch/</A
|
|
><br>
|
|
cookiepath is /bugzilla-2.16-branch/<br>
|
|
</P
|
|
></BLOCKQUOTE
|
|
></DIV
|
|
><P
|
|
>If you had cookiepath set to <SPAN
|
|
CLASS="QUOTE"
|
|
>"/"</SPAN
|
|
> at any point in the
|
|
past and need to set it to something more restrictive
|
|
(i.e. <SPAN
|
|
CLASS="QUOTE"
|
|
>"/bugzilla/"</SPAN
|
|
>), you can safely do this without
|
|
requiring users to delete their Bugzilla-related cookies in their
|
|
browser (this is true starting with Bugzilla 2.18 and Bugzilla 2.16.5).
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="trbl-index"
|
|
>A.7. <TT
|
|
CLASS="filename"
|
|
>index.cgi</TT
|
|
> doesn't show up unless specified in the URL</A
|
|
></H2
|
|
><P
|
|
> You probably need to set up your web server in such a way that it
|
|
will serve the index.cgi page as an index page.
|
|
</P
|
|
><P
|
|
> If you are using Apache, you can do this by adding
|
|
<TT
|
|
CLASS="filename"
|
|
>index.cgi</TT
|
|
> to the end of the
|
|
<SAMP
|
|
CLASS="computeroutput"
|
|
>DirectoryIndex</SAMP
|
|
> line
|
|
as mentioned in <A
|
|
HREF="#http-apache"
|
|
>Section 2.2.4.1</A
|
|
>.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="trbl-passwd-encryption"
|
|
>A.8. checksetup.pl reports "Client does not support authentication protocol
|
|
requested by server..."</A
|
|
></H2
|
|
><P
|
|
> This error is occurring because you are using the new password
|
|
encryption that comes with MySQL 4.1, while your
|
|
<TT
|
|
CLASS="filename"
|
|
>DBD::mysql</TT
|
|
> module was compiled against an
|
|
older version of MySQL. If you recompile <TT
|
|
CLASS="filename"
|
|
>DBD::mysql</TT
|
|
>
|
|
against the current MySQL libraries (or just obtain a newer version
|
|
of this module) then the error may go away.
|
|
</P
|
|
><P
|
|
> If that does not fix the problem, or if you cannot recompile the
|
|
existing module (e.g. you're running Windows) and/or don't want to
|
|
replace it (e.g. you want to keep using a packaged version), then a
|
|
workaround is available from the MySQL docs:
|
|
<A
|
|
HREF="http://dev.mysql.com/doc/mysql/en/Old_client.html"
|
|
TARGET="_top"
|
|
>http://dev.mysql.com/doc/mysql/en/Old_client.html</A
|
|
>
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="appendix"
|
|
><HR><H1
|
|
><A
|
|
NAME="patches"
|
|
></A
|
|
>Appendix B. Contrib</H1
|
|
><P
|
|
> There are a number of unofficial Bugzilla add-ons in the
|
|
<TT
|
|
CLASS="filename"
|
|
>$BUGZILLA_ROOT/contrib/</TT
|
|
>
|
|
directory. This section documents them.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="cmdline"
|
|
>B.1. Command-line Search Interface</A
|
|
></H2
|
|
><P
|
|
> There are a suite of Unix utilities for searching Bugzilla from the
|
|
command line. They live in the
|
|
<TT
|
|
CLASS="filename"
|
|
>contrib/cmdline</TT
|
|
> directory.
|
|
There are three files - <TT
|
|
CLASS="filename"
|
|
>query.conf</TT
|
|
>,
|
|
<TT
|
|
CLASS="filename"
|
|
>buglist</TT
|
|
> and <TT
|
|
CLASS="filename"
|
|
>bugs</TT
|
|
>.
|
|
</P
|
|
><DIV
|
|
CLASS="warning"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="warning"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> These files pre-date the templatization work done as part of the
|
|
2.16 release, and have not been updated.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> <TT
|
|
CLASS="filename"
|
|
>query.conf</TT
|
|
> contains the mapping from
|
|
options to field names and comparison types. Quoted option names
|
|
are <SPAN
|
|
CLASS="QUOTE"
|
|
>"grepped"</SPAN
|
|
> for, so it should be easy to edit this
|
|
file. Comments (#) have no effect; you must make sure these lines
|
|
do not contain any quoted <SPAN
|
|
CLASS="QUOTE"
|
|
>"option"</SPAN
|
|
>.
|
|
</P
|
|
><P
|
|
> <TT
|
|
CLASS="filename"
|
|
>buglist</TT
|
|
> is a shell script that submits a
|
|
Bugzilla query and writes the resulting HTML page to stdout.
|
|
It supports both short options, (such as <SPAN
|
|
CLASS="QUOTE"
|
|
>"-Afoo"</SPAN
|
|
>
|
|
or <SPAN
|
|
CLASS="QUOTE"
|
|
>"-Rbar"</SPAN
|
|
>) and long options (such
|
|
as <SPAN
|
|
CLASS="QUOTE"
|
|
>"--assignedto=foo"</SPAN
|
|
> or <SPAN
|
|
CLASS="QUOTE"
|
|
>"--reporter=bar"</SPAN
|
|
>).
|
|
If the first character of an option is not <SPAN
|
|
CLASS="QUOTE"
|
|
>"-"</SPAN
|
|
>, it is
|
|
treated as if it were prefixed with <SPAN
|
|
CLASS="QUOTE"
|
|
>"--default="</SPAN
|
|
>.
|
|
</P
|
|
><P
|
|
> The column list is taken from the COLUMNLIST environment variable.
|
|
This is equivalent to the <SPAN
|
|
CLASS="QUOTE"
|
|
>"Change Columns"</SPAN
|
|
> option
|
|
that is available when you list bugs in buglist.cgi. If you have
|
|
already used Bugzilla, grep for COLUMNLIST in your cookies file
|
|
to see your current COLUMNLIST setting.
|
|
</P
|
|
><P
|
|
> <TT
|
|
CLASS="filename"
|
|
>bugs</TT
|
|
> is a simple shell script which calls
|
|
<TT
|
|
CLASS="filename"
|
|
>buglist</TT
|
|
> and extracts the
|
|
bug numbers from the output. Adding the prefix
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"http://bugzilla.mozilla.org/buglist.cgi?bug_id="</SPAN
|
|
>
|
|
turns the bug list into a working link if any bugs are found.
|
|
Counting bugs is easy. Pipe the results through
|
|
<B
|
|
CLASS="command"
|
|
>sed -e 's/,/ /g' | wc | awk '{printf $2 "\n"}'</B
|
|
>
|
|
</P
|
|
><P
|
|
> Akkana Peck says she has good results piping
|
|
<TT
|
|
CLASS="filename"
|
|
>buglist</TT
|
|
> output through
|
|
<B
|
|
CLASS="command"
|
|
>w3m -T text/html -dump</B
|
|
>
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="cmdline-bugmail"
|
|
>B.2. Command-line 'Send Unsent Bug-mail' tool</A
|
|
></H2
|
|
><P
|
|
> Within the <TT
|
|
CLASS="filename"
|
|
>contrib</TT
|
|
> directory
|
|
exists a utility with the descriptive (if compact) name
|
|
of <TT
|
|
CLASS="filename"
|
|
>sendunsentbugmail.pl</TT
|
|
>. The purpose of this
|
|
script is, simply, to send out any bug-related mail that should
|
|
have been sent by now, but for one reason or another has not.
|
|
</P
|
|
><P
|
|
> To accomplish this task, <TT
|
|
CLASS="filename"
|
|
>sendunsentbugmail.pl</TT
|
|
> uses
|
|
the same mechanism as the <TT
|
|
CLASS="filename"
|
|
>sanitycheck.cgi</TT
|
|
> script;
|
|
it scans through the entire database looking for bugs with changes that
|
|
were made more than 30 minutes ago, but where there is no record of
|
|
anyone related to that bug having been sent mail. Having compiled a list,
|
|
it then uses the standard rules to determine who gets mail, and sends it
|
|
out.
|
|
</P
|
|
><P
|
|
> As the script runs, it indicates the bug for which it is currently
|
|
sending mail; when it has finished, it gives a numerical count of how
|
|
many mails were sent and how many people were excluded. (Individual
|
|
user names are not recorded or displayed.) If the script produces
|
|
no output, that means no unsent mail was detected.
|
|
</P
|
|
><P
|
|
> <EM
|
|
>Usage</EM
|
|
>: move the sendunsentbugmail.pl script
|
|
up into the main directory, ensure it has execute permission, and run it
|
|
from the command line (or from a cron job) with no parameters.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="appendix"
|
|
><HR><H1
|
|
><A
|
|
NAME="install-perlmodules-manual"
|
|
></A
|
|
>Appendix C. Manual Installation of Perl Modules</H1
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="modules-manual-instructions"
|
|
>C.1. Instructions</A
|
|
></H2
|
|
><P
|
|
> If you need to install Perl modules manually, here's how it's done.
|
|
Download the module using the link given in the next section, and then
|
|
apply this magic incantation, as root:
|
|
</P
|
|
><P
|
|
>
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
><SAMP
|
|
CLASS="prompt"
|
|
>bash#</SAMP
|
|
> tar -xzvf <module>.tar.gz
|
|
<SAMP
|
|
CLASS="prompt"
|
|
>bash#</SAMP
|
|
> cd <module>
|
|
<SAMP
|
|
CLASS="prompt"
|
|
>bash#</SAMP
|
|
> perl Makefile.PL
|
|
<SAMP
|
|
CLASS="prompt"
|
|
>bash#</SAMP
|
|
> make
|
|
<SAMP
|
|
CLASS="prompt"
|
|
>bash#</SAMP
|
|
> make test
|
|
<SAMP
|
|
CLASS="prompt"
|
|
>bash#</SAMP
|
|
> make install</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> In order to compile source code under Windows you will need to obtain
|
|
a 'make' utility. The <B
|
|
CLASS="command"
|
|
>nmake</B
|
|
> utility provided with
|
|
Microsoft Visual C++ may be used. As an alternative, there is a
|
|
utility called <B
|
|
CLASS="command"
|
|
>dmake</B
|
|
> available from CPAN which is
|
|
written entirely in Perl.
|
|
</P
|
|
><P
|
|
> As described in <A
|
|
HREF="#modules-manual-download"
|
|
>Section C.2</A
|
|
>, however, most
|
|
packages already exist and are available from ActiveState or theory58S.
|
|
We highly recommend that you install them using the ppm GUI available with
|
|
ActiveState and to add the theory58S repository to your list of repositories.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="modules-manual-download"
|
|
>C.2. Download Locations</A
|
|
></H2
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Running Bugzilla on Windows requires the use of ActiveState
|
|
Perl 5.8.1 or higher. Many modules already exist in the core
|
|
distribution of ActiveState Perl. Additional modules can be downloaded
|
|
from <A
|
|
HREF="http://theoryx5.uwinnipeg.ca/ppms/"
|
|
TARGET="_top"
|
|
>http://theoryx5.uwinnipeg.ca/ppms/</A
|
|
> if you use
|
|
Perl 5.8.x or from <A
|
|
HREF="http://cpan.uwinnipeg.ca/PPMPackages/10xx/"
|
|
TARGET="_top"
|
|
>http://cpan.uwinnipeg.ca/PPMPackages/10xx/</A
|
|
>
|
|
if you use Perl 5.10.x.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
> CGI:
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/CGI.pm/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/CGI.pm/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://perldoc.perl.org/CGI.html"
|
|
TARGET="_top"
|
|
>http://perldoc.perl.org/CGI.html</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> Data-Dumper:
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/Data-Dumper/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/Data-Dumper/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://search.cpan.org/dist/Data-Dumper/Dumper.pm"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/Data-Dumper/Dumper.pm</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> Date::Format (part of TimeDate):
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/TimeDate/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/TimeDate/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://search.cpan.org/dist/TimeDate/lib/Date/Format.pm"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/TimeDate/lib/Date/Format.pm</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> DBI:
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/DBI/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/DBI/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://dbi.perl.org/docs/"
|
|
TARGET="_top"
|
|
>http://dbi.perl.org/docs/</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> DBD::mysql:
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/DBD-mysql/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/DBD-mysql/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://search.cpan.org/dist/DBD-mysql/lib/DBD/mysql.pm"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/DBD-mysql/lib/DBD/mysql.pm</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> DBD::Pg:
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/DBD-Pg/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/DBD-Pg/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://search.cpan.org/dist/DBD-Pg/Pg.pm"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/DBD-Pg/Pg.pm</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> Template-Toolkit:
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/Template-Toolkit/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/Template-Toolkit/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://www.template-toolkit.org/docs.html"
|
|
TARGET="_top"
|
|
>http://www.template-toolkit.org/docs.html</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> GD:
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/GD/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/GD/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://search.cpan.org/dist/GD/GD.pm"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/GD/GD.pm</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> Template::Plugin::GD:
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/Template-GD/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/Template-GD/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://www.template-toolkit.org/docs/aqua/Modules/index.html"
|
|
TARGET="_top"
|
|
>http://www.template-toolkit.org/docs/aqua/Modules/index.html</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> MIME::Parser (part of MIME-tools):
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/MIME-tools/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/MIME-tools/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://search.cpan.org/dist/MIME-tools/lib/MIME/Parser.pm"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/MIME-tools/lib/MIME/Parser.pm</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="modules-manual-optional"
|
|
>C.3. Optional Modules</A
|
|
></H2
|
|
><P
|
|
> Chart::Lines:
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/Chart/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/Chart/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://search.cpan.org/dist/Chart/Chart.pod"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/Chart/Chart.pod</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> GD::Graph:
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/GDGraph/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/GDGraph/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://search.cpan.org/dist/GDGraph/Graph.pm"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/GDGraph/Graph.pm</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> GD::Text::Align (part of GD::Text::Util):
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/GDTextUtil/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/GDTextUtil/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://search.cpan.org/dist/GDTextUtil/Text/Align.pm"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/GDTextUtil/Text/Align.pm</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> XML::Twig:
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/dist/XML-Twig/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/dist/XML-Twig/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://standards.ieee.org/resources/spasystem/twig/twig_stable.html"
|
|
TARGET="_top"
|
|
>http://standards.ieee.org/resources/spasystem/twig/twig_stable.html</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
> PatchReader:
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
CPAN Download Page: <A
|
|
HREF="http://search.cpan.org/author/JKEISER/PatchReader/"
|
|
TARGET="_top"
|
|
>http://search.cpan.org/author/JKEISER/PatchReader/</A
|
|
><br>
|
|
Documentation: <A
|
|
HREF="http://www.johnkeiser.com/mozilla/Patch_Viewer.html"
|
|
TARGET="_top"
|
|
>http://www.johnkeiser.com/mozilla/Patch_Viewer.html</A
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="appendix"
|
|
><HR><H1
|
|
><A
|
|
NAME="gfdl"
|
|
></A
|
|
>Appendix D. GNU Free Documentation License</H1
|
|
><P
|
|
>Version 1.1, March 2000</P
|
|
><A
|
|
NAME="AEN3310"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
>Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place,
|
|
Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and
|
|
distribute verbatim copies of this license document, but changing it is
|
|
not allowed.</P
|
|
></BLOCKQUOTE
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="gfdl-0"
|
|
>0. Preamble</A
|
|
></H2
|
|
><P
|
|
>The purpose of this License is to make a manual, textbook, or other
|
|
written document "free" in the sense of freedom: to assure everyone the
|
|
effective freedom to copy and redistribute it, with or without modifying
|
|
it, either commercially or noncommercially. Secondarily, this License
|
|
preserves for the author and publisher a way to get credit for their
|
|
work, while not being considered responsible for modifications made by
|
|
others.</P
|
|
><P
|
|
>This License is a kind of "copyleft", which means that derivative
|
|
works of the document must themselves be free in the same sense. It
|
|
complements the GNU General Public License, which is a copyleft license
|
|
designed for free software.</P
|
|
><P
|
|
>We have designed this License in order to use it for manuals for
|
|
free software, because free software needs free documentation: a free
|
|
program should come with manuals providing the same freedoms that the
|
|
software does. But this License is not limited to software manuals; it
|
|
can be used for any textual work, regardless of subject matter or whether
|
|
it is published as a printed book. We recommend this License principally
|
|
for works whose purpose is instruction or reference.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="gfdl-1"
|
|
>1. Applicability and Definition</A
|
|
></H2
|
|
><P
|
|
>This License applies to any manual or other work that contains a
|
|
notice placed by the copyright holder saying it can be distributed under
|
|
the terms of this License. The "Document", below, refers to any such
|
|
manual or work. Any member of the public is a licensee, and is addressed
|
|
as "you".</P
|
|
><P
|
|
>A "Modified Version" of the Document means any work containing the
|
|
Document or a portion of it, either copied verbatim, or with
|
|
modifications and/or translated into another language.</P
|
|
><P
|
|
>A "Secondary Section" is a named appendix or a front-matter section
|
|
of the Document that deals exclusively with the relationship of the
|
|
publishers or authors of the Document to the Document's overall subject
|
|
(or to related matters) and contains nothing that could fall directly
|
|
within that overall subject. (For example, if the Document is in part a
|
|
textbook of mathematics, a Secondary Section may not explain any
|
|
mathematics.) The relationship could be a matter of historical connection
|
|
with the subject or with related matters, or of legal, commercial,
|
|
philosophical, ethical or political position regarding them.</P
|
|
><P
|
|
>The "Invariant Sections" are certain Secondary Sections whose
|
|
titles are designated, as being those of Invariant Sections, in the
|
|
notice that says that the Document is released under this License.</P
|
|
><P
|
|
>The "Cover Texts" are certain short passages of text that are
|
|
listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says
|
|
that the Document is released under this License.</P
|
|
><P
|
|
>A "Transparent" copy of the Document means a machine-readable copy,
|
|
represented in a format whose specification is available to the general
|
|
public, whose contents can be viewed and edited directly and
|
|
straightforwardly with generic text editors or (for images composed of
|
|
pixels) generic paint programs or (for drawings) some widely available
|
|
drawing editor, and that is suitable for input to text formatters or for
|
|
automatic translation to a variety of formats suitable for input to text
|
|
formatters. A copy made in an otherwise Transparent file format whose
|
|
markup has been designed to thwart or discourage subsequent modification
|
|
by readers is not Transparent. A copy that is not "Transparent" is called
|
|
"Opaque".</P
|
|
><P
|
|
>Examples of suitable formats for Transparent copies include plain
|
|
ASCII without markup, Texinfo input format, LaTeX input format, SGML or
|
|
XML using a publicly available DTD, and standard-conforming simple HTML
|
|
designed for human modification. Opaque formats include PostScript, PDF,
|
|
proprietary formats that can be read and edited only by proprietary word
|
|
processors, SGML or XML for which the DTD and/or processing tools are not
|
|
generally available, and the machine-generated HTML produced by some word
|
|
processors for output purposes only.</P
|
|
><P
|
|
>The "Title Page" means, for a printed book, the title page itself,
|
|
plus such following pages as are needed to hold, legibly, the material
|
|
this License requires to appear in the title page. For works in formats
|
|
which do not have any title page as such, "Title Page" means the text
|
|
near the most prominent appearance of the work's title, preceding the
|
|
beginning of the body of the text.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="gfdl-2"
|
|
>2. Verbatim Copying</A
|
|
></H2
|
|
><P
|
|
>You may copy and distribute the Document in any medium, either
|
|
commercially or noncommercially, provided that this License, the
|
|
copyright notices, and the license notice saying this License applies to
|
|
the Document are reproduced in all copies, and that you add no other
|
|
conditions whatsoever to those of this License. You may not use technical
|
|
measures to obstruct or control the reading or further copying of the
|
|
copies you make or distribute. However, you may accept compensation in
|
|
exchange for copies. If you distribute a large enough number of copies
|
|
you must also follow the conditions in section 3.</P
|
|
><P
|
|
>You may also lend copies, under the same conditions stated above,
|
|
and you may publicly display copies.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="gfdl-3"
|
|
>3. Copying in Quantity</A
|
|
></H2
|
|
><P
|
|
>If you publish printed copies of the Document numbering more than
|
|
100, and the Document's license notice requires Cover Texts, you must
|
|
enclose the copies in covers that carry, clearly and legibly, all these
|
|
Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts
|
|
on the back cover. Both covers must also clearly and legibly identify you
|
|
as the publisher of these copies. The front cover must present the full
|
|
title with all words of the title equally prominent and visible. You may
|
|
add other material on the covers in addition. Copying with changes
|
|
limited to the covers, as long as they preserve the title of the Document
|
|
and satisfy these conditions, can be treated as verbatim copying in other
|
|
respects.</P
|
|
><P
|
|
>If the required texts for either cover are too voluminous to fit
|
|
legibly, you should put the first ones listed (as many as fit reasonably)
|
|
on the actual cover, and continue the rest onto adjacent pages.</P
|
|
><P
|
|
>If you publish or distribute Opaque copies of the Document
|
|
numbering more than 100, you must either include a machine-readable
|
|
Transparent copy along with each Opaque copy, or state in or with each
|
|
Opaque copy a publicly-accessible computer-network location containing a
|
|
complete Transparent copy of the Document, free of added material, which
|
|
the general network-using public has access to download anonymously at no
|
|
charge using public-standard network protocols. If you use the latter
|
|
option, you must take reasonably prudent steps, when you begin
|
|
distribution of Opaque copies in quantity, to ensure that this
|
|
Transparent copy will remain thus accessible at the stated location until
|
|
at least one year after the last time you distribute an Opaque copy
|
|
(directly or through your agents or retailers) of that edition to the
|
|
public.</P
|
|
><P
|
|
>It is requested, but not required, that you contact the authors of
|
|
the Document well before redistributing any large number of copies, to
|
|
give them a chance to provide you with an updated version of the
|
|
Document.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="gfdl-4"
|
|
>4. Modifications</A
|
|
></H2
|
|
><P
|
|
>You may copy and distribute a Modified Version of the Document
|
|
under the conditions of sections 2 and 3 above, provided that you release
|
|
the Modified Version under precisely this License, with the Modified
|
|
Version filling the role of the Document, thus licensing distribution and
|
|
modification of the Modified Version to whoever possesses a copy of it.
|
|
In addition, you must do these things in the Modified Version:</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="A"
|
|
><LI
|
|
><P
|
|
>Use in the Title Page (and on the covers, if any) a title
|
|
distinct from that of the Document, and from those of previous
|
|
versions (which should, if there were any, be listed in the History
|
|
section of the Document). You may use the same title as a previous
|
|
version if the original publisher of that version gives
|
|
permission.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>List on the Title Page, as authors, one or more persons or
|
|
entities responsible for authorship of the modifications in the
|
|
Modified Version, together with at least five of the principal
|
|
authors of the Document (all of its principal authors, if it has less
|
|
than five).</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>State on the Title page the name of the publisher of the
|
|
Modified Version, as the publisher.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Preserve all the copyright notices of the Document.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Add an appropriate copyright notice for your modifications
|
|
adjacent to the other copyright notices.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Include, immediately after the copyright notices, a license
|
|
notice giving the public permission to use the Modified Version under
|
|
the terms of this License, in the form shown in the Addendum
|
|
below.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Preserve in that license notice the full lists of Invariant
|
|
Sections and required Cover Texts given in the Document's license
|
|
notice.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Include an unaltered copy of this License.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Preserve the section entitled "History", and its title, and add
|
|
to it an item stating at least the title, year, new authors, and
|
|
publisher of the Modified Version as given on the Title Page. If
|
|
there is no section entitled "History" in the Document, create one
|
|
stating the title, year, authors, and publisher of the Document as
|
|
given on its Title Page, then add an item describing the Modified
|
|
Version as stated in the previous sentence.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Preserve the network location, if any, given in the Document
|
|
for public access to a Transparent copy of the Document, and likewise
|
|
the network locations given in the Document for previous versions it
|
|
was based on. These may be placed in the "History" section. You may
|
|
omit a network location for a work that was published at least four
|
|
years before the Document itself, or if the original publisher of the
|
|
version it refers to gives permission.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>In any section entitled "Acknowledgements" or "Dedications",
|
|
preserve the section's title, and preserve in the section all the
|
|
substance and tone of each of the contributor acknowledgements and/or
|
|
dedications given therein.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Preserve all the Invariant Sections of the Document, unaltered
|
|
in their text and in their titles. Section numbers or the equivalent
|
|
are not considered part of the section titles.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Delete any section entitled "Endorsements". Such a section may
|
|
not be included in the Modified Version.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Do not retitle any existing section as "Endorsements" or to
|
|
conflict in title with any Invariant Section.</P
|
|
></LI
|
|
></OL
|
|
><P
|
|
>If the Modified Version includes new front-matter sections or
|
|
appendices that qualify as Secondary Sections and contain no material
|
|
copied from the Document, you may at your option designate some or all of
|
|
these sections as invariant. To do this, add their titles to the list of
|
|
Invariant Sections in the Modified Version's license notice. These titles
|
|
must be distinct from any other section titles.</P
|
|
><P
|
|
>You may add a section entitled "Endorsements", provided it contains
|
|
nothing but endorsements of your Modified Version by various parties--for
|
|
example, statements of peer review or that the text has been approved by
|
|
an organization as the authoritative definition of a standard.</P
|
|
><P
|
|
>You may add a passage of up to five words as a Front-Cover Text,
|
|
and a passage of up to 25 words as a Back-Cover Text, to the end of the
|
|
list of Cover Texts in the Modified Version. Only one passage of
|
|
Front-Cover Text and one of Back-Cover Text may be added by (or through
|
|
arrangements made by) any one entity. If the Document already includes a
|
|
cover text for the same cover, previously added by you or by arrangement
|
|
made by the same entity you are acting on behalf of, you may not add
|
|
another; but you may replace the old one, on explicit permission from the
|
|
previous publisher that added the old one.</P
|
|
><P
|
|
>The author(s) and publisher(s) of the Document do not by this
|
|
License give permission to use their names for publicity for or to assert
|
|
or imply endorsement of any Modified Version.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="gfdl-5"
|
|
>5. Combining Documents</A
|
|
></H2
|
|
><P
|
|
>You may combine the Document with other documents released under
|
|
this License, under the terms defined in section 4 above for modified
|
|
versions, provided that you include in the combination all of the
|
|
Invariant Sections of all of the original documents, unmodified, and list
|
|
them all as Invariant Sections of your combined work in its license
|
|
notice.</P
|
|
><P
|
|
>The combined work need only contain one copy of this License, and
|
|
multiple identical Invariant Sections may be replaced with a single copy.
|
|
If there are multiple Invariant Sections with the same name but different
|
|
contents, make the title of each such section unique by adding at the end
|
|
of it, in parentheses, the name of the original author or publisher of
|
|
that section if known, or else a unique number. Make the same adjustment
|
|
to the section titles in the list of Invariant Sections in the license
|
|
notice of the combined work.</P
|
|
><P
|
|
>In the combination, you must combine any sections entitled
|
|
"History" in the various original documents, forming one section entitled
|
|
"History"; likewise combine any sections entitled "Acknowledgements", and
|
|
any sections entitled "Dedications". You must delete all sections
|
|
entitled "Endorsements."</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="gfdl-6"
|
|
>6. Collections of Documents</A
|
|
></H2
|
|
><P
|
|
>You may make a collection consisting of the Document and other
|
|
documents released under this License, and replace the individual copies
|
|
of this License in the various documents with a single copy that is
|
|
included in the collection, provided that you follow the rules of this
|
|
License for verbatim copying of each of the documents in all other
|
|
respects.</P
|
|
><P
|
|
>You may extract a single document from such a collection, and
|
|
distribute it individually under this License, provided you insert a copy
|
|
of this License into the extracted document, and follow this License in
|
|
all other respects regarding verbatim copying of that document.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="gfdl-7"
|
|
>7. Aggregation with Independent Works</A
|
|
></H2
|
|
><P
|
|
>A compilation of the Document or its derivatives with other
|
|
separate and independent documents or works, in or on a volume of a
|
|
storage or distribution medium, does not as a whole count as a Modified
|
|
Version of the Document, provided no compilation copyright is claimed for
|
|
the compilation. Such a compilation is called an "aggregate", and this
|
|
License does not apply to the other self-contained works thus compiled
|
|
with the Document, on account of their being thus compiled, if they are
|
|
not themselves derivative works of the Document.</P
|
|
><P
|
|
>If the Cover Text requirement of section 3 is applicable to these
|
|
copies of the Document, then if the Document is less than one quarter of
|
|
the entire aggregate, the Document's Cover Texts may be placed on covers
|
|
that surround only the Document within the aggregate. Otherwise they must
|
|
appear on covers around the whole aggregate.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="gfdl-8"
|
|
>8. Translation</A
|
|
></H2
|
|
><P
|
|
>Translation is considered a kind of modification, so you may
|
|
distribute translations of the Document under the terms of section 4.
|
|
Replacing Invariant Sections with translations requires special
|
|
permission from their copyright holders, but you may include translations
|
|
of some or all Invariant Sections in addition to the original versions of
|
|
these Invariant Sections. You may include a translation of this License
|
|
provided that you also include the original English version of this
|
|
License. In case of a disagreement between the translation and the
|
|
original English version of this License, the original English version
|
|
will prevail.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="gfdl-9"
|
|
>9. Termination</A
|
|
></H2
|
|
><P
|
|
>You may not copy, modify, sublicense, or distribute the Document
|
|
except as expressly provided for under this License. Any other attempt to
|
|
copy, modify, sublicense or distribute the Document is void, and will
|
|
automatically terminate your rights under this License. However, parties
|
|
who have received copies, or rights, from you under this License will not
|
|
have their licenses terminated so long as such parties remain in full
|
|
compliance.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="gfdl-10"
|
|
>10. Future Revisions of this License</A
|
|
></H2
|
|
><P
|
|
>The Free Software Foundation may publish new, revised versions of
|
|
the GNU Free Documentation License from time to time. Such new versions
|
|
will be similar in spirit to the present version, but may differ in
|
|
detail to address new problems or concerns. See
|
|
<A
|
|
HREF="http://www.gnu.org/copyleft/"
|
|
TARGET="_top"
|
|
>http://www.gnu.org/copyleft/</A
|
|
>.</P
|
|
><P
|
|
>Each version of the License is given a distinguishing version
|
|
number. If the Document specifies that a particular numbered version of
|
|
this License "or any later version" applies to it, you have the option of
|
|
following the terms and conditions either of that specified version or of
|
|
any later version that has been published (not as a draft) by the Free
|
|
Software Foundation. If the Document does not specify a version number of
|
|
this License, you may choose any version ever published (not as a draft)
|
|
by the Free Software Foundation.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><HR><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="gfdl-howto"
|
|
>How to use this License for your documents</A
|
|
></H2
|
|
><P
|
|
>To use this License in a document you have written, include a copy
|
|
of the License in the document and put the following copyright and
|
|
license notices just after the title page:</P
|
|
><A
|
|
NAME="AEN3400"
|
|
></A
|
|
><BLOCKQUOTE
|
|
CLASS="BLOCKQUOTE"
|
|
><P
|
|
>Copyright (c) YEAR YOUR NAME. Permission is granted to copy,
|
|
distribute and/or modify this document under the terms of the GNU Free
|
|
Documentation License, Version 1.1 or any later version published by
|
|
the Free Software Foundation; with the Invariant Sections being LIST
|
|
THEIR TITLES, with the Front-Cover Texts being LIST, and with the
|
|
Back-Cover Texts being LIST. A copy of the license is included in the
|
|
section entitled "GNU Free Documentation License".</P
|
|
></BLOCKQUOTE
|
|
><P
|
|
>If you have no Invariant Sections, write "with no Invariant
|
|
Sections" instead of saying which ones are invariant. If you have no
|
|
Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover
|
|
Texts being LIST"; likewise for Back-Cover Texts.</P
|
|
><P
|
|
>If your document contains nontrivial examples of program code, we
|
|
recommend releasing these examples in parallel under your choice of free
|
|
software license, such as the GNU General Public License, to permit their
|
|
use in free software.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="GLOSSARY"
|
|
><H1
|
|
><A
|
|
NAME="glossary"
|
|
></A
|
|
>Glossary</H1
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="AEN3405"
|
|
>0-9, high ascii</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="gloss-htaccess"
|
|
></A
|
|
><B
|
|
>.htaccess</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>Apache web server, and other NCSA-compliant web servers,
|
|
observe the convention of using files in directories called
|
|
<TT
|
|
CLASS="filename"
|
|
>.htaccess</TT
|
|
>
|
|
|
|
to restrict access to certain files. In Bugzilla, they are used
|
|
to keep secret files which would otherwise
|
|
compromise your installation - e.g. the
|
|
<TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
>
|
|
file contains the password to your database.
|
|
curious.</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-a"
|
|
>A</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="gloss-apache"
|
|
></A
|
|
><B
|
|
>Apache</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>In this context, Apache is the web server most commonly used
|
|
for serving up Bugzilla
|
|
pages. Contrary to popular belief, the apache web server has nothing
|
|
to do with the ancient and noble Native American tribe, but instead
|
|
derived its name from the fact that it was
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"a patchy"</SPAN
|
|
>
|
|
version of the original
|
|
<ACRONYM
|
|
CLASS="acronym"
|
|
>NCSA</ACRONYM
|
|
>
|
|
world-wide-web server.</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><P
|
|
><B
|
|
>Useful Directives when configuring Bugzilla</B
|
|
></P
|
|
><DL
|
|
><DT
|
|
><SAMP
|
|
CLASS="computeroutput"
|
|
><A
|
|
HREF="http://httpd.apache.org/docs-2.0/mod/core.html#addhandler"
|
|
TARGET="_top"
|
|
>AddHandler</A
|
|
></SAMP
|
|
></DT
|
|
><DD
|
|
><P
|
|
>Tell Apache that it's OK to run CGI scripts.</P
|
|
></DD
|
|
><DT
|
|
><SAMP
|
|
CLASS="computeroutput"
|
|
><A
|
|
HREF="http://httpd.apache.org/docs-2.0/mod/core.html#allowoverride"
|
|
TARGET="_top"
|
|
>AllowOverride</A
|
|
></SAMP
|
|
>, <SAMP
|
|
CLASS="computeroutput"
|
|
><A
|
|
HREF="http://httpd.apache.org/docs-2.0/mod/core.html#options"
|
|
TARGET="_top"
|
|
>Options</A
|
|
></SAMP
|
|
></DT
|
|
><DD
|
|
><P
|
|
>These directives are used to tell Apache many things about
|
|
the directory they apply to. For Bugzilla's purposes, we need
|
|
them to allow script execution and <TT
|
|
CLASS="filename"
|
|
>.htaccess</TT
|
|
>
|
|
overrides.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><SAMP
|
|
CLASS="computeroutput"
|
|
><A
|
|
HREF="http://httpd.apache.org/docs-2.0/mod/mod_dir.html#directoryindex"
|
|
TARGET="_top"
|
|
>DirectoryIndex</A
|
|
></SAMP
|
|
></DT
|
|
><DD
|
|
><P
|
|
>Used to tell Apache what files are indexes. If you can
|
|
not add <TT
|
|
CLASS="filename"
|
|
>index.cgi</TT
|
|
> to the list of valid files,
|
|
you'll need to set <SAMP
|
|
CLASS="computeroutput"
|
|
>$index_html</SAMP
|
|
> to
|
|
1 in <TT
|
|
CLASS="filename"
|
|
>localconfig</TT
|
|
> so
|
|
<B
|
|
CLASS="command"
|
|
>./checksetup.pl</B
|
|
> will create an
|
|
<TT
|
|
CLASS="filename"
|
|
>index.html</TT
|
|
> that redirects to
|
|
<TT
|
|
CLASS="filename"
|
|
>index.cgi</TT
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><SAMP
|
|
CLASS="computeroutput"
|
|
><A
|
|
HREF="http://httpd.apache.org/docs-2.0/mod/core.html#scriptinterpretersource"
|
|
TARGET="_top"
|
|
>ScriptInterpreterSource</A
|
|
></SAMP
|
|
></DT
|
|
><DD
|
|
><P
|
|
>Used when running Apache on windows so the shebang line
|
|
doesn't have to be changed in every Bugzilla script.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><P
|
|
>For more information about how to configure Apache for Bugzilla,
|
|
see <A
|
|
HREF="#http-apache"
|
|
>Section 2.2.4.1</A
|
|
>.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-b"
|
|
>B</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><B
|
|
>Bug</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>A
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"bug"</SPAN
|
|
>
|
|
|
|
in Bugzilla refers to an issue entered into the database which has an
|
|
associated number, assignments, comments, etc. Some also refer to a
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"tickets"</SPAN
|
|
>
|
|
or
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"issues"</SPAN
|
|
>;
|
|
in the context of Bugzilla, they are synonymous.</P
|
|
></DD
|
|
><DT
|
|
><B
|
|
>Bug Number</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>Each Bugzilla bug is assigned a number that uniquely identifies
|
|
that bug. The bug associated with a bug number can be pulled up via a
|
|
query, or easily from the very front page by typing the number in the
|
|
"Find" box.</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="gloss-bugzilla"
|
|
></A
|
|
><B
|
|
>Bugzilla</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>Bugzilla is the world-leading free software bug tracking system.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-c"
|
|
>C</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="gloss-cgi"
|
|
></A
|
|
><B
|
|
>Common Gateway Interface</B
|
|
></DT
|
|
> (CGI)<DD
|
|
><P
|
|
><ACRONYM
|
|
CLASS="acronym"
|
|
>CGI</ACRONYM
|
|
> is an acronym for Common Gateway Interface. This is
|
|
a standard for interfacing an external application with a web server. Bugzilla
|
|
is an example of a <ACRONYM
|
|
CLASS="acronym"
|
|
>CGI</ACRONYM
|
|
> application.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="gloss-component"
|
|
></A
|
|
><B
|
|
>Component</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>A Component is a subsection of a Product. It should be a narrow
|
|
category, tailored to your organization. All Products must contain at
|
|
least one Component (and, as a matter of fact, creating a Product
|
|
with no Components will create an error in Bugzilla).</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="gloss-cpan"
|
|
></A
|
|
><B
|
|
>Comprehensive Perl Archive Network</B
|
|
></DT
|
|
> (CPAN)<DD
|
|
><P
|
|
> <ACRONYM
|
|
CLASS="acronym"
|
|
>CPAN</ACRONYM
|
|
>
|
|
|
|
stands for the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Comprehensive Perl Archive Network"</SPAN
|
|
>.
|
|
CPAN maintains a large number of extremely useful
|
|
<I
|
|
CLASS="glossterm"
|
|
>Perl</I
|
|
>
|
|
modules - encapsulated chunks of code for performing a
|
|
particular task.</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="gloss-contrib"
|
|
></A
|
|
><B
|
|
><TT
|
|
CLASS="filename"
|
|
>contrib</TT
|
|
></B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>The <TT
|
|
CLASS="filename"
|
|
>contrib</TT
|
|
> directory is
|
|
a location to put scripts that have been contributed to Bugzilla but
|
|
are not a part of the official distribution. These scripts are written
|
|
by third parties and may be in languages other than perl. For those
|
|
that are in perl, there may be additional modules or other requirements
|
|
than those of the official distribution.
|
|
<DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Scripts in the <TT
|
|
CLASS="filename"
|
|
>contrib</TT
|
|
>
|
|
directory are not officially supported by the Bugzilla team and may
|
|
break in between versions.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
>
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-d"
|
|
>D</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="gloss-daemon"
|
|
></A
|
|
><B
|
|
>daemon</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>A daemon is a computer program which runs in the background. In
|
|
general, most daemons are started at boot time via System V init
|
|
scripts, or through RC scripts on BSD-based systems.
|
|
<I
|
|
CLASS="glossterm"
|
|
>mysqld</I
|
|
>,
|
|
the MySQL server, and
|
|
<I
|
|
CLASS="glossterm"
|
|
>apache</I
|
|
>,
|
|
a web server, are generally run as daemons.</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="gloss-dos"
|
|
></A
|
|
><B
|
|
>DOS Attack</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>A DOS, or Denial of Service attack, is when a user attempts to
|
|
deny access to a web server by repeatedly accessing a page or sending
|
|
malformed requests to a webserver. A D-DOS, or
|
|
Distributed Denial of Service attack, is when these requests come
|
|
from multiple sources at the same time. Unfortunately, these are much
|
|
more difficult to defend against.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-g"
|
|
>G</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="gloss-groups"
|
|
></A
|
|
><B
|
|
>Groups</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>The word
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Groups"</SPAN
|
|
>
|
|
|
|
has a very special meaning to Bugzilla. Bugzilla's main security
|
|
mechanism comes by placing users in groups, and assigning those
|
|
groups certain privileges to view bugs in particular
|
|
<I
|
|
CLASS="glossterm"
|
|
>Products</I
|
|
>
|
|
in the
|
|
<I
|
|
CLASS="glossterm"
|
|
>Bugzilla</I
|
|
>
|
|
database.</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-j"
|
|
>J</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="gloss-javascript"
|
|
></A
|
|
><B
|
|
>JavaScript</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>JavaScript is cool, we should talk about it.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-m"
|
|
>M</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="gloss-mta"
|
|
></A
|
|
><B
|
|
>Message Transport Agent</B
|
|
></DT
|
|
> (MTA)<DD
|
|
><P
|
|
>A Message Transport Agent is used to control the flow of email on a system.
|
|
The <A
|
|
HREF="http://search.cpan.org/dist/Email-Send/lib/Email/Send.pm"
|
|
TARGET="_top"
|
|
>Email::Send</A
|
|
>
|
|
Perl module, which Bugzilla uses to send email, can be configured to
|
|
use many different underlying implementations for actually sending the
|
|
mail using the <CODE
|
|
CLASS="option"
|
|
>mail_delivery_method</CODE
|
|
> parameter.
|
|
Implementations other than <TT
|
|
CLASS="literal"
|
|
>sendmail</TT
|
|
> require that the
|
|
<CODE
|
|
CLASS="option"
|
|
>sendmailnow</CODE
|
|
> param be set to <TT
|
|
CLASS="literal"
|
|
>on</TT
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="gloss-mysql"
|
|
></A
|
|
><B
|
|
>MySQL</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>MySQL is currently the required
|
|
<A
|
|
HREF="#gloss-rdbms"
|
|
><I
|
|
CLASS="glossterm"
|
|
>RDBMS</I
|
|
></A
|
|
> for Bugzilla. MySQL
|
|
can be downloaded from <A
|
|
HREF="http://www.mysql.com"
|
|
TARGET="_top"
|
|
>http://www.mysql.com</A
|
|
>. While you
|
|
should familiarize yourself with all of the documentation, some high
|
|
points are:
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
><A
|
|
HREF="http://www.mysql.com/doc/en/Backup.html"
|
|
TARGET="_top"
|
|
>Backup</A
|
|
></DT
|
|
><DD
|
|
><P
|
|
>Methods for backing up your Bugzilla database.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
HREF="http://www.mysql.com/doc/en/Option_files.html"
|
|
TARGET="_top"
|
|
>Option Files</A
|
|
></DT
|
|
><DD
|
|
><P
|
|
>Information about how to configure MySQL using
|
|
<TT
|
|
CLASS="filename"
|
|
>my.cnf</TT
|
|
>.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
HREF="http://www.mysql.com/doc/en/Privilege_system.html"
|
|
TARGET="_top"
|
|
>Privilege System</A
|
|
></DT
|
|
><DD
|
|
><P
|
|
>Information about how to protect your MySQL server.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-p"
|
|
>P</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="gloss-ppm"
|
|
></A
|
|
><B
|
|
>Perl Package Manager</B
|
|
></DT
|
|
> (PPM)<DD
|
|
><P
|
|
><A
|
|
HREF="http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/"
|
|
TARGET="_top"
|
|
>http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/</A
|
|
>
|
|
</P
|
|
></DD
|
|
><DT
|
|
><B
|
|
>Product</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>A Product is a broad category of types of bugs, normally
|
|
representing a single piece of software or entity. In general,
|
|
there are several Components to a Product. A Product may define a
|
|
group (used for security) for all bugs entered into
|
|
its Components.</P
|
|
></DD
|
|
><DT
|
|
><B
|
|
>Perl</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>First written by Larry Wall, Perl is a remarkable program
|
|
language. It has the benefits of the flexibility of an interpreted
|
|
scripting language (such as shell script), combined with the speed
|
|
and power of a compiled language, such as C.
|
|
<I
|
|
CLASS="glossterm"
|
|
>Bugzilla</I
|
|
>
|
|
|
|
is maintained in Perl.</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-q"
|
|
>Q</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><B
|
|
>QA</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
> <SPAN
|
|
CLASS="QUOTE"
|
|
>"QA"</SPAN
|
|
>,
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Q/A"</SPAN
|
|
>, and
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Q.A."</SPAN
|
|
>
|
|
are short for
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Quality Assurance"</SPAN
|
|
>.
|
|
In most large software development organizations, there is a team
|
|
devoted to ensuring the product meets minimum standards before
|
|
shipping. This team will also generally want to track the progress of
|
|
bugs over their life cycle, thus the need for the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"QA Contact"</SPAN
|
|
>
|
|
|
|
field in a bug.</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-r"
|
|
>R</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="gloss-rdbms"
|
|
></A
|
|
><B
|
|
>Relational DataBase Management System</B
|
|
></DT
|
|
> (RDBMS)<DD
|
|
><P
|
|
>A relational database management system is a database system
|
|
that stores information in tables that are related to each other.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="gloss-regexp"
|
|
></A
|
|
><B
|
|
>Regular Expression</B
|
|
></DT
|
|
> (regexp)<DD
|
|
><P
|
|
>A regular expression is an expression used for pattern matching.
|
|
<A
|
|
HREF="http://perldoc.com/perl5.6/pod/perlre.html#Regular-Expressions"
|
|
TARGET="_top"
|
|
>Documentation</A
|
|
>
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-s"
|
|
>S</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="gloss-service"
|
|
></A
|
|
><B
|
|
>Service</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>In Windows NT environment, a boot-time background application
|
|
is referred to as a service. These are generally managed through the
|
|
control panel while logged in as an account with
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Administrator"</SPAN
|
|
> level capabilities. For more
|
|
information, consult your Windows manual or the MSKB.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><B
|
|
> <ACRONYM
|
|
CLASS="acronym"
|
|
>SGML</ACRONYM
|
|
>
|
|
</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
> <ACRONYM
|
|
CLASS="acronym"
|
|
>SGML</ACRONYM
|
|
>
|
|
|
|
stands for
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"Standard Generalized Markup Language"</SPAN
|
|
>.
|
|
Created in the 1980's to provide an extensible means to maintain
|
|
documentation based upon content instead of presentation,
|
|
<ACRONYM
|
|
CLASS="acronym"
|
|
>SGML</ACRONYM
|
|
>
|
|
|
|
has withstood the test of time as a robust, powerful language.
|
|
<I
|
|
CLASS="glossterm"
|
|
> <ACRONYM
|
|
CLASS="acronym"
|
|
>XML</ACRONYM
|
|
>
|
|
</I
|
|
>
|
|
|
|
is the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"baby brother"</SPAN
|
|
>
|
|
|
|
of SGML; any valid
|
|
<ACRONYM
|
|
CLASS="acronym"
|
|
>XML</ACRONYM
|
|
>
|
|
|
|
document it, by definition, a valid
|
|
<ACRONYM
|
|
CLASS="acronym"
|
|
>SGML</ACRONYM
|
|
>
|
|
|
|
document. The document you are reading is written and maintained in
|
|
<ACRONYM
|
|
CLASS="acronym"
|
|
>SGML</ACRONYM
|
|
>,
|
|
and is also valid
|
|
<ACRONYM
|
|
CLASS="acronym"
|
|
>XML</ACRONYM
|
|
>
|
|
|
|
if you modify the Document Type Definition.</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-t"
|
|
>T</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="gloss-target-milestone"
|
|
></A
|
|
><B
|
|
>Target Milestone</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>Target Milestones are Product goals. They are configurable on a
|
|
per-Product basis. Most software development houses have a concept of
|
|
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"milestones"</SPAN
|
|
>
|
|
|
|
where the people funding a project expect certain functionality on
|
|
certain dates. Bugzilla facilitates meeting these milestones by
|
|
giving you the ability to declare by which milestone a bug will be
|
|
fixed, or an enhancement will be implemented.</P
|
|
></DD
|
|
><DT
|
|
><A
|
|
NAME="gloss-tcl"
|
|
></A
|
|
><B
|
|
>Tool Command Language</B
|
|
></DT
|
|
> (TCL)<DD
|
|
><P
|
|
>TCL is an open source scripting language available for Windows,
|
|
Macintosh, and Unix based systems. Bugzilla 1.0 was written in TCL but
|
|
never released. The first release of Bugzilla was 2.0, which was when
|
|
it was ported to perl.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><DIV
|
|
CLASS="glossdiv"
|
|
><H1
|
|
CLASS="glossdiv"
|
|
><A
|
|
NAME="gloss-z"
|
|
>Z</A
|
|
></H1
|
|
><DL
|
|
><DT
|
|
><A
|
|
NAME="gloss-zarro"
|
|
></A
|
|
><B
|
|
>Zarro Boogs Found</B
|
|
></DT
|
|
><DD
|
|
><P
|
|
>This is just a goofy way of saying that there were no bugs
|
|
found matching your query. When asked to explain this message,
|
|
Terry had the following to say:
|
|
</P
|
|
><A
|
|
NAME="AEN3649"
|
|
></A
|
|
><TABLE
|
|
BORDER="0"
|
|
WIDTH="100%"
|
|
CELLSPACING="0"
|
|
CELLPADDING="0"
|
|
CLASS="BLOCKQUOTE"
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
VALIGN="TOP"
|
|
> </TD
|
|
><TD
|
|
VALIGN="TOP"
|
|
><P
|
|
>I've been asked to explain this ... way back when, when
|
|
Netscape released version 4.0 of its browser, we had a release
|
|
party. Naturally, there had been a big push to try and fix every
|
|
known bug before the release. Naturally, that hadn't actually
|
|
happened. (This is not unique to Netscape or to 4.0; the same thing
|
|
has happened with every software project I've ever seen.) Anyway,
|
|
at the release party, T-shirts were handed out that said something
|
|
like "Netscape 4.0: Zarro Boogs". Just like the software, the
|
|
T-shirt had no known bugs. Uh-huh.
|
|
</P
|
|
><P
|
|
>So, when you query for a list of bugs, and it gets no results,
|
|
you can think of this as a friendly reminder. Of *course* there are
|
|
bugs matching your query, they just aren't in the bugsystem yet...
|
|
</P
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
VALIGN="TOP"
|
|
> </TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
COLSPAN="2"
|
|
ALIGN="RIGHT"
|
|
VALIGN="TOP"
|
|
>--<SPAN
|
|
CLASS="attribution"
|
|
>Terry Weissman</SPAN
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
> </TD
|
|
></TR
|
|
></TABLE
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |