<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html><head><meta http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968"><title>3.1. Bugzilla Configuration</title><link rel="stylesheet" type="text/css" href="../../style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"><meta name="keywords" content="Bugzilla, Guide, installation, FAQ, administration, integration, MySQL, Mozilla, webtools"><link rel="home" href="index.html" title="The Bugzilla Guide - 4.4.12 Release"><link rel="up" href="administration.html" title="Chapter 3. Administering Bugzilla"><link rel="prev" href="administration.html" title="Chapter 3. Administering Bugzilla"><link rel="next" href="useradmin.html" title="3.2. User Administration"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">3.1. Bugzilla Configuration</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="administration.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Administering Bugzilla</th><td width="20%" align="right"> <a accesskey="n" href="useradmin.html">Next</a></td></tr></table><hr></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="parameters"></a>3.1. Bugzilla Configuration</h2></div></div></div><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"><div class="titlepage"><div><div><h3 class="title"><a name="param-requiredsettings"></a>3.1.1. Required Settings</h3></div></div></div><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><div class="variablelist"><dl class="variablelist"><dt><span class="term"> maintainer </span></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><span class="term"> urlbase </span></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 <code class="filename">http://www.foo.com/bugzilla/query.cgi</code>, the <span class="quote">“<span class="quote">urlbase</span>”</span> should be set to <code class="filename">http://www.foo.com/bugzilla/</code>. </p></dd><dt><span class="term"> docs_urlbase </span></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 <code class="filename">http://www.foo.com/bugzilla/docs/html/parameters.html</code>, set the <span class="quote">“<span class="quote">docs_urlbase</span>”</span> to <code class="filename">http://www.foo.com/bugzilla/docs/html/</code>. </p></dd><dt><span class="term"> sslbase </span></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 <code class="filename">https://www.foo.com/bugzilla/index.cgi</code>, the <span class="quote">“<span class="quote">sslbase</span>”</span> should be set to <code class="filename">https://www.foo.com/bugzilla/</code>. </p></dd><dt><span class="term"> ssl_redirect </span></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><span class="term"> cookiedomain </span></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 <code class="filename">https://www.foo.com/</code>, setting this to <code class="filename">.foo.com/</code> will also allow <code class="filename">bar.foo.com/</code> to access Bugzilla cookies. </p></dd><dt><span class="term"> cookiepath </span></dt><dd><p> Defines a path, relative to the web server root, that Bugzilla cookies will be restricted to. For example, if the <span class="command"><strong>urlbase</strong></span> is set to <code class="filename">http://www.foo.com/bugzilla/</code>, the <span class="command"><strong>cookiepath</strong></span> should be set to <code class="filename">/bugzilla/</code>. Setting it to "/" will allow all sites served by this web server or virtual host to read Bugzilla cookies. </p></dd><dt><span class="term"> utf8 </span></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 <code class="filename">contrib/recode.pl</code> script. </p><div class="note" style="margin-left: 1em; margin-right: 1em"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.gif"></td><th align="left"></th></tr><tr><td align="left" valign="top"><p> If you turn this parameter from "off" to "on", you must re-run <code class="filename">checksetup.pl</code> immediately afterward. </p></td></tr></table></div></dd><dt><span class="term"> shutdownhtml </span></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" style="margin-left: 1em; margin-right: 1em"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.gif"></td><th align="left"></th></tr><tr><td align="left" valign="top"><p> Although regular log-in capability is disabled while <span class="command"><strong>shutdownhtml</strong></span> 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 <code class="filename">editparams.cgi</code> (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><span class="term"> announcehtml </span></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">“<span class="quote"><div></span>”</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">“<span class="quote">id=message</span>”</span> to the <span class="quote">“<span class="quote"><div></span>”</span> tag. </p></dd><dt><span class="term"> proxy_url </span></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 <span class="command"><strong>upgrade_notification</strong></span> parameter (below). If the proxy requires authentication, use the syntax: <code class="filename">http://user:pass@proxy_url/</code>. </p></dd><dt><span class="term"> upgrade_notification </span></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"><div class="titlepage"><div><div><h3 class="title"><a name="param-admin-policies"></a>3.1.2. Administrative Policies</h3></div></div></div><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"><div class="titlepage"><div><div><h3 class="title"><a name="param-user-authentication"></a>3.1.3. User Authentication</h3></div></div></div><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><div class="variablelist"><dl class="variablelist"><dt><span class="term"> emailregexp </span></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') in a slightly more restrictive way than what is allowed in RFC 2822. Some Bugzilla installations allow only local user names (i.e 'user' instead of 'user@example.com'). In that case, this parameter should be used to define the email domain. </p></dd><dt><span class="term"> emailsuffix </span></dt><dd><p> This string is appended to login names when actually sending email to a user. For example, If <span class="command"><strong>emailregexp</strong></span> 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"><div class="titlepage"><div><div><h3 class="title"><a name="param-attachments"></a>3.1.4. Attachments</h3></div></div></div><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"><div class="titlepage"><div><div><h3 class="title"><a name="param-bug-change-policies"></a>3.1.5. Bug Change Policies</h3></div></div></div><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><div class="variablelist"><dl class="variablelist"><dt><span class="term"> commenton* </span></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" style="margin-left: 1em; margin-right: 1em"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.gif"></td><th align="left"></th></tr><tr><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><span class="term"> noresolveonopenblockers </span></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"><div class="titlepage"><div><div><h3 class="title"><a name="param-bugfields"></a>3.1.6. Bug Fields</h3></div></div></div><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><div class="variablelist"><dl class="variablelist"><dt><span class="term"> useqacontact </span></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><span class="term"> usestatuswhiteboard </span></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"><div class="titlepage"><div><div><h3 class="title"><a name="param-bugmoving"></a>3.1.7. Bug Moving</h3></div></div></div><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 <span class="emphasis"><em>from</em></span> other bug databases to this Bugzilla installation are assigned to. </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="param-dependency-graphs"></a>3.1.8. Dependency Graphs</h3></div></div></div><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 <code class="filename">.dot</code> graphic description files. If no Web Dot server or binary is specified, then dependency graphs will be disabled. </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="param-group-security"></a>3.1.9. Group Security</h3></div></div></div><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 class="xref" href="groups.html" title="3.15. Groups and Group Security">Section 3.15, “Groups and Group Security”</a> </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"> makeproductgroups </span></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><span class="term"> usevisibilitygroups </span></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 class="xref" href="groups.html#edit-groups" title="3.15.2. Editing Groups and Assigning Group Permissions">Section 3.15.2, “Editing Groups and Assigning Group Permissions”</a>. </p></dd><dt><span class="term"> querysharegroup </span></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 class="xref" href="userpreferences.html#savedsearches" title="5.10.3. Saved Searches">Saved Searches</a>. </p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="bzldap"></a>3.1.10. LDAP Authentication</h3></div></div></div><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" style="margin-left: 1em; margin-right: 1em"><table border="0" summary="Caution"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Caution]" src="../images/caution.gif"></td><th align="left"></th></tr><tr><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 <code class="filename">bugzilla_ldapsync.rb</code> script in the <a class="glossterm" href="glossary.html#gloss-contrib"><em class="glossterm"> <code class="filename">contrib</code></em></a> directory. Another possible solution is fixing <a class="ulink" 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><div class="variablelist"><dl class="variablelist"><dt><a name="param-user_verify_class_for_ldap"></a><span class="term">user_verify_class</span></dt><dd><p>If you want to list <span class="quote">“<span class="quote">LDAP</span>”</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 <code class="filename">data/params</code> and set user_verify_class to <span class="quote">“<span class="quote">DB</span>”</span>. </p></dd><dt><a name="param-LDAPserver"></a><span class="term">LDAPserver</span></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">“<span class="quote">ldap.company.com</span>”</span> or <span class="quote">“<span class="quote">ldap.company.com:3268</span>”</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" style="margin-left: 1em; margin-right: 1em"><table border="0" summary="Tip"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="../images/tip.gif"></td><th align="left"></th></tr><tr><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">“<span class="quote">ldap://ldap.company.com</span>”</span>, LDAP over SSL: <span class="quote">“<span class="quote">ldaps://ldap.company.com</span>”</span> or LDAP over a UNIX domain socket <span class="quote">“<span class="quote">ldapi://%2fvar%2flib%2fldap_sock</span>”</span>. </p></dd><dt><a name="param-LDAPbinddn"></a><span class="term">LDAPbinddn [Optional]</span></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">“<span class="quote">cn=default,cn=user:password</span>”</span></p></dd><dt><a name="param-LDAPBaseDN"></a><span class="term">LDAPBaseDN</span></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">“<span class="quote">ou=People,o=Company</span>”</span></p></dd><dt><a name="param-LDAPuidattribute"></a><span class="term">LDAPuidattribute</span></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">“<span class="quote">uid</span>”</span></p></dd><dt><a name="param-LDAPmailattribute"></a><span class="term">LDAPmailattribute</span></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">“<span class="quote">mail</span>”</span></p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="bzradius"></a>3.1.11. RADIUS Authentication</h3></div></div></div><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" style="margin-left: 1em; margin-right: 1em"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.gif"></td><th align="left"></th></tr><tr><td align="left" valign="top"><p> Most caveats that apply to LDAP authentication apply to RADIUS authentication as well. See <a class="xref" href="parameters.html#bzldap" title="3.1.10. LDAP Authentication">Section 3.1.10, “LDAP Authentication”</a> for details. </p></td></tr></table></div><p>Parameters required to use RADIUS Authentication:</p><div class="variablelist"><dl class="variablelist"><dt><a name="param-user_verify_class_for_radius"></a><span class="term">user_verify_class</span></dt><dd><p>If you want to list <span class="quote">“<span class="quote">RADIUS</span>”</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 <code class="filename">data/params</code> and set user_verify_class to <span class="quote">“<span class="quote">DB</span>”</span>. </p></dd><dt><a name="param-RADIUS_server"></a><span class="term">RADIUS_server</span></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><span class="term">RADIUS_secret</span></dt><dd><p>This parameter should be set to the RADIUS server's secret. </p></dd><dt><a name="param-RADIUS_email_suffix"></a><span class="term">RADIUS_email_suffix</span></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 <code class="filename">Bugzilla/Auth/Verify/RADIUS.pm</code> to match your requirements. </p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="param-email"></a>3.1.12. Email</h3></div></div></div><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><div class="variablelist"><dl class="variablelist"><dt><span class="term"> mail_delivery_method </span></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 <code class="filename">data/mailer.testfile</code> for later review. "None" disables email sending entirely. </p></dd><dt><span class="term"> mailfrom </span></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><span class="term"> smtpserver </span></dt><dd><p> This is the SMTP server address, if the <span class="quote">“<span class="quote">mail_delivery_method</span>”</span> parameter is set to SMTP. Use "localhost" if you have a local MTA running, otherwise use a remote SMTP server. Append ":" and the port number, if a non-default port is needed. </p></dd><dt><span class="term"> smtp_username </span></dt><dd><p> Username to use for SASL authentication to the SMTP server. Leave this parameter empty if your server does not require authentication. </p></dd><dt><span class="term"> smtp_password </span></dt><dd><p> Password to use for SASL authentication to the SMTP server. This parameter will be ignored if the <span class="quote">“<span class="quote">smtp_username</span>”</span> parameter is left empty. </p></dd><dt><span class="term"> smtp_ssl </span></dt><dd><p> Enable SSL support for connection to the SMTP server. </p></dd><dt><span class="term"> smtp_debug </span></dt><dd><p> This parameter allows you to enable detailed debugging output. Log messages are printed the web server's error log. </p></dd><dt><span class="term"> whinedays </span></dt><dd><p> Set this to the number of days you want to let bugs go in the CONFIRMED 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><span class="term"> globalwatcher </span></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"><div class="titlepage"><div><div><h3 class="title"><a name="param-patchviewer"></a>3.1.13. Patch Viewer</h3></div></div></div><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"><div class="titlepage"><div><div><h3 class="title"><a name="param-querydefaults"></a>3.1.14. Query Defaults</h3></div></div></div><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"><div class="titlepage"><div><div><h3 class="title"><a name="param-shadowdatabase"></a>3.1.15. Shadow Database</h3></div></div></div><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">“<span class="quote">shadowdb</span>”</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" style="margin-left: 1em; margin-right: 1em"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.gif"></td><th align="left"></th></tr><tr><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"><div class="titlepage"><div><div><h3 class="title"><a name="admin-usermatching"></a>3.1.16. User Matching</h3></div></div></div><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><p> Another setting called 'ajax_user_autocompletion' enables certain user fields to display a list of matched user names as a drop down after typing a few characters. Note that it is recommended to use mod_perl when enabling 'ajax_user_autocompletion'. </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="administration.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="administration.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="useradmin.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 3. Administering Bugzilla </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 3.2. User Administration</td></tr></table></div></body></html>