<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>4.1. Parameters — Bugzilla 5.0.4 documentation</title>
<link rel="stylesheet" href="../_static/bugzilla.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '5.0.4',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true,
SOURCELINK_SUFFIX: '.txt'
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<link rel="shortcut icon" href="../_static/favicon.ico"/>
<link rel="search" title="Search" href="../search.html" />
<link rel="next" title="4.2. Default Preferences" href="preferences.html" />
<link rel="prev" title="4. Administration Guide" href="index.html" />
</head>
<body>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="preferences.html" title="4.2. Default Preferences"
accesskey="N">next</a></li>
<li class="right" >
<a href="index.html" title="4. Administration Guide"
accesskey="P">previous</a> |</li>
<li class="nav-item nav-item-0"><a href="../index.html">Bugzilla 5.0.4 documentation</a> »</li>
<li class="nav-item nav-item-1"><a href="index.html" accesskey="U">4. Administration Guide</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<div class="section" id="parameters">
<span id="id1"></span><h1>4.1. Parameters<a class="headerlink" href="#parameters" title="Permalink to this headline">¶</a></h1>
<p>Bugzilla is configured by changing various parameters, accessed
from the <span class="guilabel">Parameters</span> link, which is found on the Administration
page. The parameters are divided into several categories,
accessed via the menu on the left.</p>
<div class="section" id="required-settings">
<span id="param-required-settings"></span><h2>4.1.1. Required Settings<a class="headerlink" href="#required-settings" title="Permalink to this headline">¶</a></h2>
<p>The core required parameters for any Bugzilla installation are set
here. <span class="param">urlbase</span> is always required; the other parameters should be
set, or it must be explicitly decided not to
set them, before the new Bugzilla installation starts to be used.</p>
<dl class="docutils">
<dt>urlbase</dt>
<dd>Defines the fully qualified domain name and web
server path to this Bugzilla installation.
For example, if the Bugzilla query page is
<code class="file docutils literal"><span class="pre">http://www.foo.com/bugzilla/query.cgi</span></code>,
the <span class="param">urlbase</span> should be set
to <span class="paramval">http://www.foo.com/bugzilla/</span>.</dd>
<dt>ssl_redirect</dt>
<dd>If enabled, Bugzilla will force HTTPS (SSL) connections, by
automatically redirecting any users who try to use a non-SSL
connection. Also, when this is enabled, Bugzilla will send out links
using <span class="param">sslbase</span> in emails instead of <span class="param">urlbase</span>.</dd>
<dt>sslbase</dt>
<dd>Defines the fully qualified domain name and web
server path for HTTPS (SSL) connections to this Bugzilla installation.
For example, if the Bugzilla main page is
<code class="file docutils literal"><span class="pre">https://www.foo.com/bugzilla/index.cgi</span></code>,
the <span class="param">sslbase</span> should be set
to <span class="paramval">https://www.foo.com/bugzilla/</span>.</dd>
<dt>cookiepath</dt>
<dd>Defines a path, relative to the web document root, that Bugzilla
cookies will be restricted to. For example, if the
<span class="param">urlbase</span> is set to
<code class="file docutils literal"><span class="pre">http://www.foo.com/bugzilla/</span></code>, the
<span class="param">cookiepath</span> should be set to
<span class="paramval">/bugzilla/</span>. Setting it to <span class="paramval">/</span> will allow all sites
served by this web server or virtual host to read Bugzilla cookies.</dd>
</dl>
</div>
<div class="section" id="general">
<span id="param-general"></span><h2>4.1.2. General<a class="headerlink" href="#general" title="Permalink to this headline">¶</a></h2>
<dl class="docutils">
<dt>maintainer</dt>
<dd>Email address of the person
responsible for maintaining this Bugzilla installation.
The address need not be that of a valid Bugzilla account.</dd>
<dt>utf8</dt>
<dd><p class="first">Use UTF-8 (Unicode) encoding for all text in Bugzilla. Installations where
this parameter is set to <span class="paramval">off</span> should set it to <span class="paramval">on</span> only
after the data has been converted from existing legacy character
encodings to UTF-8, using the
<code class="file docutils literal"><span class="pre">contrib/recode.pl</span></code> script.</p>
<div class="last admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you turn this parameter from <span class="paramval">off</span> to <span class="paramval">on</span>,
you must re-run <code class="file docutils literal"><span class="pre">checksetup.pl</span></code> immediately afterward.</p>
</div>
</dd>
<dt>shutdownhtml</dt>
<dd>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.</dd>
<dt>announcehtml</dt>
<dd>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 <code class="docutils literal"><span class="pre"><div></span></code>
tag. Any style attributes from the CSS can be applied. For example,
to make the text green inside of a red box, add <code class="docutils literal"><span class="pre">id=message</span></code>
to the <code class="docutils literal"><span class="pre"><div></span></code> tag.</dd>
<dt>upgrade_notification</dt>
<dd>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 <span class="paramval">disabled</span>
to turn off the notification. Otherwise, choose which version of
Bugzilla you want to be notified about: <span class="paramval">development_snapshot</span> is the
latest release from the master branch, <span class="paramval">latest_stable_release</span> is the most
recent release available on the most recent stable branch, and
<span class="paramval">stable_branch_release</span> is the most recent release on the branch
this installation is based on.</dd>
</dl>
</div>
<div class="section" id="administrative-policies">
<span id="param-administrative-policies"></span><h2>4.1.3. Administrative Policies<a class="headerlink" href="#administrative-policies" title="Permalink to this headline">¶</a></h2>
<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>
<dl class="docutils">
<dt>allowbugdeletion</dt>
<dd>The pages to edit products and components can delete all associated bugs when you delete a product (or component). Since that is a pretty scary idea, you have to turn on this option before any such deletions will ever happen.</dd>
<dt>allowemailchange</dt>
<dd>Users can change their own email address through the preferences. Note that the change is validated by emailing both addresses, so switching this option on will not let users use an invalid address.</dd>
<dt>allowuserdeletion</dt>
<dd>The user editing pages are capable of letting you delete user accounts. Bugzilla will issue a warning in case you'd run into inconsistencies when you're about to do so, but such deletions still remain scary. So, you have to turn on this option before any such deletions will ever happen.</dd>
<dt>last_visit_keep_days</dt>
<dd>This option controls how many days Bugzilla will remember that users have visited specific bugs.</dd>
</dl>
</div>
<div class="section" id="user-authentication">
<span id="param-user-authentication"></span><h2>4.1.4. User Authentication<a class="headerlink" href="#user-authentication" title="Permalink to this headline">¶</a></h2>
<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>
<dl class="docutils">
<dt>auth_env_id</dt>
<dd>Environment variable used by external authentication system to store a unique identifier for each user. Leave it blank if there isn't one or if this method of authentication is not being used.</dd>
<dt>auth_env_email</dt>
<dd>Environment variable used by external authentication system to store each user's email address. This is a required field for environmental authentication. Leave it blank if you are not going to use this feature.</dd>
<dt>auth_env_realname</dt>
<dd>Environment variable used by external authentication system to store the user's real name. Leave it blank if there isn't one or if this method of authentication is not being used.</dd>
<dt>user_info_class</dt>
<dd><p class="first">Mechanism(s) to be used for gathering a user's login information. More than one may be selected. If the first one returns nothing, the second is tried, and so on. The types are:</p>
<ul class="last simple">
<li><span class="paramval">CGI</span>: asks for username and password via CGI form interface.</li>
<li><span class="paramval">Env</span>: info for a pre-authenticated user is passed in system environment variables.</li>
</ul>
</dd>
<dt>user_verify_class</dt>
<dd><p class="first">Mechanism(s) to be used for verifying (authenticating) information gathered by user_info_class. More than one may be selected. If the first one cannot find the user, the second is tried, and so on. The types are:</p>
<ul class="last simple">
<li><span class="paramval">DB</span>: Bugzilla's built-in authentication. This is the most common choice.</li>
<li><span class="paramval">RADIUS</span>: RADIUS authentication using a RADIUS server. Using this method requires additional parameters to be set. Please see <a class="reference internal" href="#param-radius"><span class="std std-ref">RADIUS</span></a> for more information.</li>
<li><span class="paramval">LDAP</span>: LDAP authentication using an LDAP server. Using this method requires additional parameters to be set. Please see <a class="reference internal" href="#param-ldap"><span class="std std-ref">LDAP</span></a> for more information.</li>
</ul>
</dd>
<dt>rememberlogin</dt>
<dd><p class="first">Controls management of session cookies.</p>
<ul class="last simple">
<li><span class="paramval">on</span> - Session cookies never expire (the user has to login only once per browser).</li>
<li><span class="paramval">off</span> - Session cookies last until the users session ends (the user will have to login in each new browser session).</li>
<li><span class="paramval">defaulton</span>/<span class="paramval">defaultoff</span> - Default behavior as described above, but user can choose whether Bugzilla will remember their login or not.</li>
</ul>
</dd>
<dt>requirelogin</dt>
<dd>If this option is set, all access to the system beyond the front page will require a login. No anonymous users will be permitted.</dd>
<dt>webservice_email_filter</dt>
<dd>Filter email addresses returned by the WebService API depending on if the user is logged in or not. This works similarly to how the web UI currently filters email addresses. If requirelogin is enabled, then this parameter has no effect as users must be logged in to use Bugzilla anyway.</dd>
<dt>emailregexp</dt>
<dd>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.
Another popular value to put here is <span class="paramval">^[^@]+</span>, which means 'local usernames, no @ allowed.'</dd>
<dt>emailregexpdesc</dt>
<dd>This description is shown to the user to explain which email addresses are allowed by the <span class="param">emailregexp</span> param.</dd>
<dt>emailsuffix</dt>
<dd>This is a string to append to any email addresses when actually sending mail to that address. It is useful if you have changed the <span class="param">emailregexp</span> param to only allow local usernames, but you want the mail to be delivered to username@my.local.hostname.</dd>
<dt>createemailregexp</dt>
<dd>This defines the (case-insensitive) regexp to use for email addresses that are permitted to self-register. The default (<span class="paramval">.*</span>) permits any account matching the emailregexp to be created. If this parameter is left blank, no users will be permitted to create their own accounts and all accounts will have to be created by an administrator.</dd>
<dt>password_complexity</dt>
<dd><p class="first">Set the complexity required for passwords. In all cases must the passwords be at least 6 characters long.</p>
<ul class="last simple">
<li><span class="paramval">no_constraints</span> - No complexity required.</li>
<li><span class="paramval">mixed_letters</span> - Passwords must contain at least one UPPER and one lower case letter.</li>
<li><span class="paramval">letters_numbers</span> - Passwords must contain at least one UPPER and one lower case letter and a number.</li>
<li><span class="paramval">letters_numbers_specialchars</span> - Passwords must contain at least one letter, a number and a special character.</li>
</ul>
</dd>
<dt>password_check_on_login</dt>
<dd>If set, Bugzilla will check that the password meets the current complexity rules and minimum length requirements when the user logs into the Bugzilla web interface. If it doesn't, the user would not be able to log in, and will receive a message to reset their password.</dd>
</dl>
</div>
<div class="section" id="attachments">
<span id="param-attachments"></span><h2>4.1.5. Attachments<a class="headerlink" href="#attachments" title="Permalink to this headline">¶</a></h2>
<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>
<dl class="docutils">
<dt>allow_attachment_display</dt>
<dd><p class="first">If this option is on, users will be able to view attachments from their browser, if their browser supports the attachment's MIME type. If this option is off, users are forced to download attachments, even if the browser is able to display them.</p>
<p class="last">If you do not trust your users (e.g. if your Bugzilla is public), you should either leave this option off, or configure and set the <span class="param">attachment_base</span> parameter (see below). Untrusted users may upload attachments that could be potentially damaging if viewed directly in the browser.</p>
</dd>
<dt>attachment_base</dt>
<dd><p class="first">When the <span class="param">allow_attachment_display</span> parameter is on, it is possible for a malicious attachment to steal your cookies or perform an attack on Bugzilla using your credentials.</p>
<p>If you would like additional security on attachments to avoid this, set this parameter to an alternate URL for your Bugzilla that is not the same as <span class="param">urlbase</span> or <span class="param">sslbase</span>. That is, a different domain name that resolves to this exact same Bugzilla installation.</p>
<p>Note that if you have set the <span class="param">cookiedomain</span> parameter, you should set <span class="param">attachment_base</span> to use a domain that would not be matched by <span class="param">cookiedomain</span>.</p>
<p class="last">For added security, you can insert <code class="docutils literal"><span class="pre">%bugid%</span></code> into the URL, which will be replaced with the ID of the current bug that the attachment is on, when you access an attachment. This will limit attachments to accessing only other attachments on the same bug. Remember, though, that all those possible domain names (such as 1234.your.domain.com) must point to this same Bugzilla instance. To set this up you need to investigate wildcard DNS.</p>
</dd>
<dt>allow_attachment_deletion</dt>
<dd>If this option is on, administrators will be able to delete the contents
of attachments (i.e. replace the attached file with a 0 byte file),
leaving only the metadata.</dd>
<dt>maxattachmentsize</dt>
<dd><p class="first">The maximum size (in kilobytes) of attachments to be stored in the database. If a file larger than this size is attached to a bug, Bugzilla will look at the <span class="param">maxlocalattachment</span> parameter to determine if the file can be stored locally on the web server. If the file size exceeds both limits, then the attachment is rejected. Setting both parameters to 0 will prevent attaching files to bugs.</p>
<p class="last">Some databases have default limits which prevent storing larger attachments in the database. E.g. MySQL has a parameter called <a class="reference external" href="http://dev.mysql.com/doc/refman/5.1/en/packet-too-large.html">max_allowed_packet</a>, whose default varies by distribution. Setting <span class="param">maxattachmentsize</span> higher than your current setting for this value will produce an error.</p>
</dd>
<dt>maxlocalattachment</dt>
<dd><p class="first">The maximum size (in megabytes) of attachments to be stored locally on the web server. If set to a value lower than the <span class="param">maxattachmentsize</span> parameter, attachments will never be kept on the local filesystem.</p>
<p>Whether you use this feature or not depends on your environment. Reasons to store some or all attachments as files might include poor database performance for large binary blobs, ease of backup/restore/browsing, or even filesystem-level deduplication support. However, you need to be aware of any limits on how much data your webserver environment can store. If in doubt, leave the value at 0.</p>
<p class="last">Note that changing this value does not affect any already-submitted attachments.</p>
</dd>
</dl>
</div>
<div class="section" id="bug-change-policies">
<span id="param-bug-change-policies"></span><h2>4.1.6. Bug Change Policies<a class="headerlink" href="#bug-change-policies" title="Permalink to this headline">¶</a></h2>
<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>
<dl class="docutils">
<dt>duplicate_or_move_bug_status</dt>
<dd>When a bug is marked as a duplicate of another one, use this bug status.</dd>
<dt>letsubmitterchoosepriority</dt>
<dd>If this is on, then people submitting bugs can choose an initial priority for that bug. If off, then all bugs initially have the default priority selected here.</dd>
<dt>letsubmitterchoosemilestone</dt>
<dd>If this is on, then people submitting bugs can choose the Target Milestone for that bug. If off, then all bugs initially have the default milestone for the product being filed in.</dd>
<dt>musthavemilestoneonaccept</dt>
<dd>If you are using Target Milestone, do you want to require that the milestone be set in order for a user to set a bug's status to IN_PROGRESS?</dd>
<dt>commenton*</dt>
<dd><p class="first">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.
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="last admonition note">
<p class="first admonition-title">Note</p>
<p class="last">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>
</div>
</dd>
<dt>noresolveonopenblockers</dt>
<dd>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.</dd>
</dl>
</div>
<div class="section" id="bug-fields">
<span id="param-bugfields"></span><h2>4.1.7. Bug Fields<a class="headerlink" href="#bug-fields" title="Permalink to this headline">¶</a></h2>
<p>The parameters in this section determine the default settings of
several Bugzilla fields for new bugs and whether
certain fields are used. For example, choose whether to use the
<span class="field">Target Milestone</span> field or the <span class="field">Status Whiteboard</span> field.</p>
<dl class="docutils">
<dt>useclassification</dt>
<dd>If this is on, Bugzilla will associate each product with a specific
classification. But you must have <span class="group">editclassification</span> permissions
enabled in order to edit classifications.</dd>
<dt>usetargetmilestone</dt>
<dd>Do you wish to use the <span class="field">Target Milestone</span> field?</dd>
<dt>useqacontact</dt>
<dd>This allows you to define an email address for each component,
in addition to that of the default assignee, that will be sent
carbon copies of incoming bugs.</dd>
<dt>usestatuswhiteboard</dt>
<dd>This defines whether you wish to have a free-form, overwritable field
associated with each bug. The advantage of the <span class="field">Status Whiteboard</span>
is that it can be deleted or modified with ease and provides an
easily searchable field for indexing bugs that have some trait in
common.</dd>
<dt>use_see_also</dt>
<dd>Do you wish to use the <span class="field">See Also</span> field? It allows you mark bugs
in other bug tracker installations as being related. Disabling this field
prevents addition of new relationships, but existing ones will continue to
appear.</dd>
<dt>defaultpriority</dt>
<dd>This is the priority that newly entered bugs are set to.</dd>
<dt>defaultseverity</dt>
<dd>This is the severity that newly entered bugs are set to.</dd>
<dt>defaultplatform</dt>
<dd>This is the platform that is preselected on the bug entry form.
You can leave this empty; Bugzilla will then use the platform that the
browser is running on as the default.</dd>
<dt>defaultopsys</dt>
<dd>This is the operating system that is preselected on the bug entry form.
You can leave this empty; Bugzilla will then use the operating system
that the browser reports to be running on as the default.</dd>
<dt>collapsed_comment_tags</dt>
<dd>A comma-separated list of tags which, when applied to comments, will
cause them to be collapsed by default.</dd>
</dl>
</div>
<div class="section" id="graphs">
<span id="param-dependency-graphs"></span><h2>4.1.8. Graphs<a class="headerlink" href="#graphs" title="Permalink to this headline">¶</a></h2>
<p>Bugzilla can draw graphs of bug-dependency relationships, using a tool called
<code class="file docutils literal"><span class="pre">dot</span></code> (from the <a class="reference external" href="http://graphviz.org/">GraphViz project</a>) or a web
service called Web Dot. This page allows you to set the location of the binary
or service. If no Web Dot server or binary is specified, then dependency
graphs will be disabled.</p>
<dl class="docutils">
<dt>webdotbase</dt>
<dd><p class="first">You may set this parameter to any of the following:</p>
<ul class="simple">
<li>A complete file path to <strong class="command">dot</strong> (part of GraphViz), which will
generate the graphs locally.</li>
<li>A URL prefix pointing to an installation of the Web Dot package, which
will generate the graphs remotely.</li>
<li>A blank value, which will disable dependency graphing.</li>
</ul>
<p class="last">The default value is blank. We recommend using a local install of
<code class="file docutils literal"><span class="pre">dot</span></code>. If you change this value to a web service, make certain that
the Web Dot server can read files from your Web Dot directory. On Apache
you do this by editing the <code class="file docutils literal"><span class="pre">.htaccess</span></code> file; for other systems the
needed measures may vary. You can run <strong class="command">checksetup.pl</strong> to
recreate the <code class="file docutils literal"><span class="pre">.htaccess</span></code> file if it has been lost.</p>
</dd>
<dt>font_file</dt>
<dd>You can specify the full path to a TrueType font file which will be used
to display text (labels, legends, ...) in charts and graphical reports.
To support as many languages as possible, we recommend to specify a
TrueType font such as Unifont which supports all printable characters in
the Basic Multilingual Plane. If you leave this parameter empty, a default
font will be used, but its support is limited to English characters only
and so other characters will be displayed incorrectly.</dd>
</dl>
</div>
<div class="section" id="group-security">
<span id="param-group-security"></span><h2>4.1.9. Group Security<a class="headerlink" href="#group-security" title="Permalink to this headline">¶</a></h2>
<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 <span class="guilabel">Groups</span> and <span class="guilabel">Product</span> pages of the
<span class="guilabel">Administration</span> area.
The options on this page control global default behavior.
For more information on Groups and Group Security, see
<a class="reference internal" href="groups.html#groups"><span class="std std-ref">Groups and Security</span></a>.</p>
<dl class="docutils">
<dt>makeproductgroups</dt>
<dd>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.</dd>
<dt>chartgroup</dt>
<dd>The name of the group of users who can use the 'New Charts' feature. Administrators should ensure that the public categories and series definitions do not divulge confidential information before enabling this for an untrusted population. If left blank, no users will be able to use New Charts.</dd>
<dt>insidergroup</dt>
<dd>The name of the group of users who can see/change private comments and attachments.</dd>
<dt>timetrackinggroup</dt>
<dd>The name of the group of users who can see/change time tracking information.</dd>
<dt>querysharegroup</dt>
<dd>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="reference internal" href="../using/preferences.html#saved-searches"><span class="std std-ref">Saved Searches</span></a>.</dd>
<dt>comment_taggers_group</dt>
<dd>The name of the group of users who can tag comments. Setting this to empty disables comment tagging.</dd>
<dt>debug_group</dt>
<dd>The name of the group of users who can view the actual SQL query generated when viewing bug lists and reports. Do not expose this information to untrusted users.</dd>
<dt>usevisibilitygroups</dt>
<dd>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="reference internal" href="groups.html#edit-groups"><span class="std std-ref">Editing Groups and Assigning Group Permissions</span></a>.</dd>
<dt>or_groups</dt>
<dd>Define the visibility of a bug which is in multiple groups. If
this is on (recommended), a user only needs to be a member of one
of the bug's groups in order to view it. If it is off, a user
needs to be a member of all the bug's groups. Note that in either
case, a user's role on the bug (e.g. reporter), if any, may also
affect their permissions.</dd>
</dl>
</div>
<div class="section" id="ldap">
<span id="param-ldap"></span><h2>4.1.10. LDAP<a class="headerlink" href="#ldap" title="Permalink to this headline">¶</a></h2>
<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 <span class="param">emailsuffix</span> parameter is appended to
the 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="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">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="file docutils literal"><span class="pre">bugzilla_ldapsync.rb</span></code>
script in the <code class="file docutils literal"><span class="pre">contrib</span></code>
directory. Another possible solution is fixing <a class="reference external" href="https://bugzilla.mozilla.org/show_bug.cgi?id=201069">bug 201069</a>.</p>
</div>
<p>Parameters required to use LDAP Authentication:</p>
<dl class="docutils">
<dt>user_verify_class (in the Authentication section)</dt>
<dd>If you want to list <span class="paramval">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
<code class="file docutils literal"><span class="pre">data/params.json</span></code> and set <span class="param">user_verify_class</span> to
<span class="paramval">DB</span>.</dd>
<dt>LDAPserver</dt>
<dd><p class="first">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.
For example: <span class="paramval">ldap.company.com</span>
or <span class="paramval">ldap.company.com:3268</span>
You can also specify a LDAP URI, so as to use other
protocols, such as LDAPS or LDAPI. If the port was not specified in
the URI, the default is either 389 or 636 for 'LDAP' and 'LDAPS'
schemes respectively.</p>
<div class="last admonition note">
<p class="first admonition-title">Note</p>
<p class="last">In order to use SSL with LDAP, specify a URI with "ldaps://".
This will force the use of SSL over port 636.
For example, normal LDAP <span class="paramval">ldap://ldap.company.com</span>, LDAP over
SSL <span class="paramval">ldaps://ldap.company.com</span>, or LDAP over a UNIX
domain socket <span class="paramval">ldapi://%2fvar%2flib%2fldap_sock</span>.</p>
</div>
</dd>
<dt>LDAPstarttls</dt>
<dd>Whether to require encrypted communication once a normal LDAP connection
is achieved with the server.</dd>
<dt>LDAPbinddn [Optional]</dt>
<dd>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 <span class="param">LDAPbinddn</span> parameter to the user account Bugzilla
should use instead of the anonymous bind.
Ex. <span class="paramval">cn=default,cn=user:password</span></dd>
<dt>LDAPBaseDN</dt>
<dd>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.
Ex. <span class="paramval">ou=People,o=Company</span></dd>
<dt>LDAPuidattribute</dt>
<dd>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.
Ex. <span class="paramval">uid</span></dd>
<dt>LDAPmailattribute</dt>
<dd>The name of the
attribute which contains the email address your users will enter
into the Bugzilla login boxes.
Ex. <span class="paramval">mail</span></dd>
<dt>LDAPfilter</dt>
<dd>LDAP filter to AND with the LDAPuidattribute for filtering the list of
valid users.</dd>
</dl>
</div>
<div class="section" id="radius">
<span id="param-radius"></span><h2>4.1.11. RADIUS<a class="headerlink" href="#radius" title="Permalink to this headline">¶</a></h2>
<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="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Most caveats that apply to LDAP authentication apply to RADIUS
authentication as well. See <a class="reference internal" href="#param-ldap"><span class="std std-ref">LDAP</span></a> for details.</p>
</div>
<p>Parameters required to use RADIUS Authentication:</p>
<dl class="docutils">
<dt>user_verify_class (in the Authentication section)</dt>
<dd>If you want to list <span class="paramval">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
<code class="file docutils literal"><span class="pre">data/params.json</span></code> and set <span class="param">user_verify_class</span> to
<span class="paramval">DB</span>.</dd>
<dt>RADIUS_server</dt>
<dd>The name (and optionally the port) of your RADIUS server.</dd>
<dt>RADIUS_secret</dt>
<dd>The RADIUS server's secret.</dd>
<dt>RADIUS_NAS_IP</dt>
<dd>The NAS-IP-Address attribute to be used when exchanging data with your
RADIUS server. If unspecified, 127.0.0.1 will be used.</dd>
<dt>RADIUS_email_suffix</dt>
<dd>Bugzilla needs an email address for each user account.
Therefore, it needs to determine the email 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 email
address.
You can specify this suffix in the <span class="param">RADIUS_email_suffix</span> parameter.
If this simple solution does not work for you, you'll
probably need to modify
<code class="file docutils literal"><span class="pre">Bugzilla/Auth/Verify/RADIUS.pm</span></code> to match your
requirements.</dd>
</dl>
</div>
<div class="section" id="email">
<span id="param-email"></span><h2>4.1.12. Email<a class="headerlink" href="#email" title="Permalink to this headline">¶</a></h2>
<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>
<dl class="docutils">
<dt>mail_delivery_method</dt>
<dd>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.
<span class="paramval">Test</span> does not send mail, but instead saves it in
<code class="file docutils literal"><span class="pre">data/mailer.testfile</span></code> for later review.
<span class="paramval">None</span> disables email sending entirely.</dd>
<dt>mailfrom</dt>
<dd>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.</dd>
<dt>use_mailer_queue</dt>
<dd>In a large Bugzilla installation, updating bugs can be very slow because Bugzilla sends all email at once. If you enable this parameter, Bugzilla will queue all mail and then send it in the background. This requires that you have installed certain Perl modules (as listed by <code class="file docutils literal"><span class="pre">checksetup.pl</span></code> for this feature), and that you are running the <code class="file docutils literal"><span class="pre">jobqueue.pl</span></code> daemon (otherwise your mail won't get sent). This affects all mail sent by Bugzilla, not just bug updates.</dd>
<dt>smtpserver</dt>
<dd>The SMTP server address, if the <span class="param">mail_delivery_method</span>
parameter is set to <span class="paramval">SMTP</span>. Use <span class="paramval">localhost</span> 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.</dd>
<dt>smtp_username</dt>
<dd>Username to use for SASL authentication to the SMTP server. Leave
this parameter empty if your server does not require authentication.</dd>
<dt>smtp_password</dt>
<dd>Password to use for SASL authentication to the SMTP server. This
parameter will be ignored if the <span class="param">smtp_username</span>
parameter is left empty.</dd>
<dt>smtp_ssl</dt>
<dd>Enable SSL support for connection to the SMTP server.</dd>
<dt>smtp_debug</dt>
<dd>This parameter allows you to enable detailed debugging output.
Log messages are printed the web server's error log.</dd>
<dt>whinedays</dt>
<dd>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 <a class="reference internal" href="../installing/optional-post-install-config.html#installation-whining"><span class="std std-ref">whining cron job</span></a> described
in the installation instructions, or set this value to "0" (never whine).</dd>
<dt>globalwatchers</dt>
<dd>This allows you to define specific users who will
receive notification each time any new bug in entered, or when
any existing bug changes, subject to the normal groupset
permissions. It may be useful for sending notifications to a
mailing list, for instance.</dd>
</dl>
</div>
<div class="section" id="query-defaults">
<span id="param-querydefaults"></span><h2>4.1.13. Query Defaults<a class="headerlink" href="#query-defaults" title="Permalink to this headline">¶</a></h2>
<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>
<dl class="docutils">
<dt>quip_list_entry_control</dt>
<dd><p class="first">Controls how easily users can add entries to the quip list.</p>
<ul class="last simple">
<li><span class="paramval">open</span> - Users may freely add to the quip list, and their entries will immediately be available for viewing.</li>
<li><span class="paramval">moderated</span> - Quips can be entered but need to be approved by a moderator before they will be shown.</li>
<li><span class="paramval">closed</span> - No new additions to the quips list are allowed.</li>
</ul>
</dd>
<dt>mybugstemplate</dt>
<dd>This is the URL to use to bring up a simple 'all of my bugs' list
for a user. %userid% will get replaced with the login name of a
user. Special characters must be URL encoded.</dd>
<dt>defaultquery</dt>
<dd>This is the default query that initially comes up when you access
the advanced query page. It's in URL-parameter format.</dd>
<dt>search_allow_no_criteria</dt>
<dd>When turned off, a query must have some criteria specified to limit the number of bugs returned to the user. When turned on, a user is allowed to run a query with no criteria and get all bugs in the entire installation that they can see. Turning this parameter on is not recommended on large installations.</dd>
<dt>default_search_limit</dt>
<dd><p class="first">By default, Bugzilla limits searches done in the web interface to returning only this many results, for performance reasons. (This only affects the HTML format of search results—CSV, XML, and other formats are exempted.) Users can click a link on the search result page to see all the results.</p>
<p class="last">Usually you should not have to change this—the default value should be acceptable for most installations.</p>
</dd>
<dt>max_search_results</dt>
<dd>The maximum number of bugs that a search can ever return. Tabular and graphical reports are exempted from this limit, however.</dd>
</dl>
</div>
<div class="section" id="shadow-database">
<span id="param-shadowdatabase"></span><h2>4.1.14. Shadow Database<a class="headerlink" href="#shadow-database" title="Permalink to this headline">¶</a></h2>
<p>This page controls whether a shadow database is used. If your Bugzilla is
not large, you will not need these options.</p>
<p>A standard large database setup involves a single master server and a pool of
read-only slaves (which Bugzilla calls the "shadowdb"). Queries which are not
updating data can be directed to the slave pool, removing the load/locking
from the master, freeing it up to handle writes. Bugzilla will switch to the
shadowdb when it knows it doesn't need to update the database (e.g. when
searching, or displaying a bug to a not-logged-in user).</p>
<p>Bugzilla does not make sure the shadowdb is kept up to date, so, if you use
one, you will need to set up replication in your database server.</p>
<p>If your shadowdb is on a different machine, specify <span class="param">shadowdbhost</span>
and <span class="param">shadowdbport</span>. If it's on the same machine, specify
<span class="param">shadowdbsock</span>.</p>
<dl class="docutils">
<dt>shadowdbhost</dt>
<dd>The host the shadow database is on.</dd>
<dt>shadowdbport</dt>
<dd>The port the shadow database is on.</dd>
<dt>shadowdbsock</dt>
<dd>The socket used to connect to the shadow database, if the host is the
local machine.</dd>
<dt>shadowdb</dt>
<dd>The database name of the shadow database.</dd>
</dl>
</div>
<div class="section" id="memcached">
<span id="admin-memcached"></span><h2>4.1.15. Memcached<a class="headerlink" href="#memcached" title="Permalink to this headline">¶</a></h2>
<dl class="docutils">
<dt>memcached_servers</dt>
<dd>If this option is set, Bugzilla will integrate with <a class="reference external" href="http://www.memcached.org/">Memcached</a>. Specify one or more servers, separated by
spaces, using hostname:port notation (for example:
<span class="paramval">127.0.0.1:11211</span>).</dd>
<dt>memcached_namespace</dt>
<dd>Specify a string to prefix each key on Memcached.</dd>
</dl>
</div>
<div class="section" id="user-matching">
<span id="admin-usermatching"></span><h2>4.1.16. User Matching<a class="headerlink" href="#user-matching" title="Permalink to this headline">¶</a></h2>
<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 assigning the bug, adding to the CC list, or
selecting a QA contact. With the <span class="param">usemenuforusers</span> parameter, it is
possible to configure Bugzilla to
display a list of users in the fields instead of an empty text field.
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>
<dl class="docutils">
<dt>usemenuforusers</dt>
<dd>If this option is set, Bugzilla will offer you a list to select from (instead of a text entry field) where a user needs to be selected. This option should not be enabled on sites where there are a large number of users.</dd>
<dt>ajax_user_autocompletion</dt>
<dd>If this option is set, typing characters in a certain user fields
will display a list of matches that can be selected from. It is
recommended to only turn this on if you are using mod_perl;
otherwise, the response will be irritatingly slow.</dd>
<dt>maxusermatches</dt>
<dd>Provide no more than this many matches when a user is searched for.
If set to '1', no users will be displayed on ambiguous
matches. This is useful for user-privacy purposes. A value of zero
means no limit.</dd>
<dt>confirmuniqueusermatch</dt>
<dd>Whether a confirmation screen should be displayed when only one user matches a search entry.</dd>
</dl>
</div>
<div class="section" id="advanced">
<span id="admin-advanced"></span><h2>4.1.17. Advanced<a class="headerlink" href="#advanced" title="Permalink to this headline">¶</a></h2>
<dl class="docutils">
<dt>cookiedomain</dt>
<dd>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="docutils literal"><span class="pre">https://bugzilla.example.com/</span></code>, setting this to
<span class="paramval">.example.com/</span> will also allow
<code class="docutils literal"><span class="pre">attachments.example.com/</span></code> to access Bugzilla cookies.</dd>
<dt>inbound_proxies</dt>
<dd>When inbound traffic to Bugzilla goes through a proxy, Bugzilla thinks that the IP address of the proxy is the IP address of every single user. If you enter a comma-separated list of IPs in this parameter, then Bugzilla will trust any <code class="docutils literal"><span class="pre">X-Forwarded-For</span></code> header sent from those IPs, and use the value of that header as the end user's IP address.</dd>
<dt>proxy_url</dt>
<dd>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="param">upgrade_notification</span> parameter. If the
proxy requires authentication, use the syntax:
<span class="paramval">http://user:pass@proxy_url/</span>.</dd>
<dt>strict_transport_security</dt>
<dd><p class="first">Enables the sending of the Strict-Transport-Security header along with HTTP responses on SSL connections. This adds greater security to your SSL connections by forcing the browser to always access your domain over SSL and never accept an invalid certificate. However, it should only be used if you have the <span class="param">ssl_redirect</span> parameter turned on, Bugzilla is the only thing running on its domain (i.e., your <span class="param">urlbase</span> is something like <span class="paramval">http://bugzilla.example.com/</span>), and you never plan to stop supporting SSL.</p>
<ul class="last simple">
<li><span class="paramval">off</span> - Don't send the Strict-Transport-Security header with requests.</li>
<li><span class="paramval">this_domain_only</span> - Send the Strict-Transport-Security header with all requests, but only support it for the current domain.</li>
<li><span class="paramval">include_subdomains</span> - Send the Strict-Transport-Security header along with the includeSubDomains flag, which will apply the security change to all subdomains. This is especially useful when combined with an <span class="param">attachment_base</span> that exists as (a) subdomain(s) under the main Bugzilla domain.</li>
</ul>
</dd>
</dl>
<hr class="docutils" />
<p>This documentation undoubtedly has bugs; if you find some, please file
them <a class="reference external" href="https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&component=Documentation">here</a>.</p>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="../index.html">
<img class="logo" src="../_static/bugzilla.png" alt="Logo"/>
</a></p>
<h3><a href="../index.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">4.1. Parameters</a><ul>
<li><a class="reference internal" href="#required-settings">4.1.1. Required Settings</a></li>
<li><a class="reference internal" href="#general">4.1.2. General</a></li>
<li><a class="reference internal" href="#administrative-policies">4.1.3. Administrative Policies</a></li>
<li><a class="reference internal" href="#user-authentication">4.1.4. User Authentication</a></li>
<li><a class="reference internal" href="#attachments">4.1.5. Attachments</a></li>
<li><a class="reference internal" href="#bug-change-policies">4.1.6. Bug Change Policies</a></li>
<li><a class="reference internal" href="#bug-fields">4.1.7. Bug Fields</a></li>
<li><a class="reference internal" href="#graphs">4.1.8. Graphs</a></li>
<li><a class="reference internal" href="#group-security">4.1.9. Group Security</a></li>
<li><a class="reference internal" href="#ldap">4.1.10. LDAP</a></li>
<li><a class="reference internal" href="#radius">4.1.11. RADIUS</a></li>
<li><a class="reference internal" href="#email">4.1.12. Email</a></li>
<li><a class="reference internal" href="#query-defaults">4.1.13. Query Defaults</a></li>
<li><a class="reference internal" href="#shadow-database">4.1.14. Shadow Database</a></li>
<li><a class="reference internal" href="#memcached">4.1.15. Memcached</a></li>
<li><a class="reference internal" href="#user-matching">4.1.16. User Matching</a></li>
<li><a class="reference internal" href="#advanced">4.1.17. Advanced</a></li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="index.html"
title="previous chapter">4. Administration Guide</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="preferences.html"
title="next chapter">4.2. Default Preferences</a></p>
<div id="searchbox" style="display: none" role="search">
<h3>Quick search</h3>
<form class="search" action="../search.html" method="get">
<div><input type="text" name="q" /></div>
<div><input type="submit" value="Go" /></div>
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="preferences.html" title="4.2. Default Preferences"
>next</a></li>
<li class="right" >
<a href="index.html" title="4. Administration Guide"
>previous</a> |</li>
<li class="nav-item nav-item-0"><a href="../index.html">Bugzilla 5.0.4 documentation</a> »</li>
<li class="nav-item nav-item-1"><a href="index.html" >4. Administration Guide</a> »</li>
</ul>
</div>
<div class="footer" role="contentinfo">
Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.6.6.
</div>
</body>
</html>
