| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| <HTML |
| ><HEAD |
| ><TITLE |
| >Bugzilla Configuration</TITLE |
| ><META |
| NAME="GENERATOR" |
| CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK |
| REL="HOME" |
| TITLE="The Bugzilla Guide - 2.20.1 |
| Release" |
| HREF="index.html"><LINK |
| REL="UP" |
| TITLE="Administering Bugzilla" |
| HREF="administration.html"><LINK |
| REL="PREVIOUS" |
| TITLE="Administering Bugzilla" |
| HREF="administration.html"><LINK |
| REL="NEXT" |
| TITLE="User Administration" |
| HREF="useradmin.html"></HEAD |
| ><BODY |
| CLASS="section" |
| BGCOLOR="#FFFFFF" |
| TEXT="#000000" |
| LINK="#0000FF" |
| VLINK="#840084" |
| ALINK="#0000FF" |
| ><DIV |
| CLASS="NAVHEADER" |
| ><TABLE |
| SUMMARY="Header navigation table" |
| WIDTH="100%" |
| BORDER="0" |
| CELLPADDING="0" |
| CELLSPACING="0" |
| ><TR |
| ><TH |
| COLSPAN="3" |
| ALIGN="center" |
| >The Bugzilla Guide - 2.20.1 |
| Release</TH |
| ></TR |
| ><TR |
| ><TD |
| WIDTH="10%" |
| ALIGN="left" |
| VALIGN="bottom" |
| ><A |
| HREF="administration.html" |
| ACCESSKEY="P" |
| >Prev</A |
| ></TD |
| ><TD |
| WIDTH="80%" |
| ALIGN="center" |
| VALIGN="bottom" |
| >Chapter 3. Administering Bugzilla</TD |
| ><TD |
| WIDTH="10%" |
| ALIGN="right" |
| VALIGN="bottom" |
| ><A |
| HREF="useradmin.html" |
| ACCESSKEY="N" |
| >Next</A |
| ></TD |
| ></TR |
| ></TABLE |
| ><HR |
| ALIGN="LEFT" |
| WIDTH="100%"></DIV |
| ><DIV |
| CLASS="section" |
| ><H1 |
| CLASS="section" |
| ><A |
| NAME="parameters" |
| >3.1. Bugzilla Configuration</A |
| ></H1 |
| ><P |
| > Bugzilla is configured by changing various parameters, accessed |
| from the "Edit parameters" link in the page footer. Here are |
| some of the key parameters on that page. You should run down this |
| list and set them appropriately after installing Bugzilla. |
| </P |
| ><P |
| ></P |
| ><DIV |
| CLASS="variablelist" |
| ><DL |
| ><DT |
| >maintainer</DT |
| ><DD |
| ><P |
| > |
| The maintainer parameter is the 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 |
| > This parameter defines the fully qualified domain name and web |
| server path to your Bugzilla installation. |
| </P |
| ><P |
| > For example, if your Bugzilla query page is |
| <TT |
| CLASS="filename" |
| >http://www.foo.com/bugzilla/query.cgi</TT |
| >, |
| set your <SPAN |
| CLASS="QUOTE" |
| >"urlbase"</SPAN |
| > |
| to <TT |
| CLASS="filename" |
| >http://www.foo.com/bugzilla/</TT |
| >. |
| </P |
| ></DD |
| ><DT |
| >makeproductgroups</DT |
| ><DD |
| ><P |
| > This dictates whether or not to automatically create groups |
| when new products are created. |
| </P |
| ></DD |
| ><DT |
| >useentrygroupdefault</DT |
| ><DD |
| ><P |
| > Bugzilla products can have a group associated with them, so that |
| certain users can only see bugs in certain products. When this |
| parameter is set to <SPAN |
| CLASS="QUOTE" |
| >"on"</SPAN |
| >, this |
| causes the initial group controls on newly created products |
| to place all newly-created bugs in the group |
| having the same name as the product immediately. |
| After a product is initially created, the group controls |
| can be further adjusted without interference by |
| this mechanism. |
| </P |
| ></DD |
| ><DT |
| >maildeliverymethod</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. |
| "testfile" 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 |
| >shadowdb</DT |
| ><DD |
| ><P |
| > You run into an interesting problem when Bugzilla reaches a |
| high level of continuous activity. MySQL supports only table-level |
| write locking. What this means is that if someone needs to make a |
| change to a bug, they will lock the entire table until the operation |
| is complete. Locking for write also blocks reads until the write is |
| complete. Note that more recent versions of mysql support row level |
| locking using different table types. These types are slower than the |
| standard type, and Bugzilla does not yet take advantage of features |
| such as transactions which would justify this speed decrease. The |
| Bugzilla team are, however, happy to hear about any experiences with |
| row level locking and Bugzilla. |
| </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. Although your database size will |
| double, a shadow database can cause an enormous performance |
| improvement when implemented on extremely high-traffic Bugzilla |
| databases. |
| </P |
| ><P |
| > As a guide, on reasonably old hardware, mozilla.org began needing |
| <SPAN |
| CLASS="QUOTE" |
| >"shadowdb"</SPAN |
| > when they reached around 40,000 Bugzilla |
| users with several hundred Bugzilla bug changes and comments per day. |
| </P |
| ><P |
| > The value of the parameter defines the name of the shadow bug |
| database. You will need to set the host and port settings from |
| the params page, and set up replication in your database server |
| so that updates reach this readonly mirror. Consult your database |
| documentation for more detail. |
| </P |
| ></DD |
| ><DT |
| >shutdownhtml</DT |
| ><DD |
| ><P |
| > If you need to shut down Bugzilla to perform administration, enter |
| some descriptive text (with embedded HTML codes, if you'd like) |
| into this box. Anyone who tries to use Bugzilla (including admins) |
| will receive a page displaying this text. Users can neither log in |
| nor log out while shutdownhtml is enabled. |
| </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 'shutdownhtml' |
| 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 |
| >passwordmail</DT |
| ><DD |
| ><P |
| > Every time a user creates an account, the text of this parameter |
| (with substitutions) is sent to the new user along with their |
| password message. |
| </P |
| ><P |
| > Add any text you wish to the "passwordmail" parameter box. For |
| instance, many people choose to use this box to give a quick |
| training blurb about how to use Bugzilla at your site. |
| </P |
| ></DD |
| ><DT |
| >movebugs</DT |
| ><DD |
| ><P |
| > This option is an undocumented feature to allow moving bugs |
| between separate Bugzilla installations. You will need to understand |
| the source code in order to use this feature. Please consult |
| <TT |
| CLASS="filename" |
| >movebugs.pl</TT |
| > in your Bugzilla source tree for |
| further documentation, such as it is. |
| </P |
| ></DD |
| ><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 |
| ><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 |
| >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 |
| >supportwatchers</DT |
| ><DD |
| ><P |
| > Turning on this option allows users to ask to receive copies |
| of bug mail sent to another user. Watching a user with |
| different group permissions is not a way to 'get around' the |
| system; copied emails are still subject to the normal groupset |
| permissions of a bug, and <SPAN |
| CLASS="QUOTE" |
| >"watchers"</SPAN |
| > will only be |
| copied on emails from bugs they would normally be allowed to view. |
| </P |
| ></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="NAVFOOTER" |
| ><HR |
| ALIGN="LEFT" |
| WIDTH="100%"><TABLE |
| SUMMARY="Footer navigation table" |
| WIDTH="100%" |
| BORDER="0" |
| CELLPADDING="0" |
| CELLSPACING="0" |
| ><TR |
| ><TD |
| WIDTH="33%" |
| ALIGN="left" |
| VALIGN="top" |
| ><A |
| HREF="administration.html" |
| ACCESSKEY="P" |
| >Prev</A |
| ></TD |
| ><TD |
| WIDTH="34%" |
| ALIGN="center" |
| VALIGN="top" |
| ><A |
| HREF="index.html" |
| ACCESSKEY="H" |
| >Home</A |
| ></TD |
| ><TD |
| WIDTH="33%" |
| ALIGN="right" |
| VALIGN="top" |
| ><A |
| HREF="useradmin.html" |
| ACCESSKEY="N" |
| >Next</A |
| ></TD |
| ></TR |
| ><TR |
| ><TD |
| WIDTH="33%" |
| ALIGN="left" |
| VALIGN="top" |
| >Administering Bugzilla</TD |
| ><TD |
| WIDTH="34%" |
| ALIGN="center" |
| VALIGN="top" |
| ><A |
| HREF="administration.html" |
| ACCESSKEY="U" |
| >Up</A |
| ></TD |
| ><TD |
| WIDTH="33%" |
| ALIGN="right" |
| VALIGN="top" |
| >User Administration</TD |
| ></TR |
| ></TABLE |
| ></DIV |
| ></BODY |
| ></HTML |
| > |
