3.1. Bugzilla Configuration

Email address of the person responsible for maintaining this Bugzilla installation. The address need not be that of a valid Bugzilla account.

Defines the fully qualified domain name and web server path to this Bugzilla installation.

For example, if the Bugzilla query page is http://www.foo.com/bugzilla/query.cgi, the "urlbase" should be set to http://www.foo.com/bugzilla/.

Defines path to the Bugzilla documentation. This can be a fully qualified domain name, or a path relative to "urlbase".

For example, if the "Bugzilla Configuration" page of the documentation is http://www.foo.com/bugzilla/docs/html/parameters.html, set the "docs_urlbase" to http://www.foo.com/bugzilla/docs/html/.

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 https://www.foo.com/bugzilla/index.cgi, the "sslbase" should be set to https://www.foo.com/bugzilla/.

If enabled, Bugzilla will force HTTPS (SSL) connections, by automatically redirecting any users who try to use a non-SSL connection.

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 https://www.foo.com/, setting this to .foo.com/ will also allow bar.foo.com/ to access Bugzilla cookies.

Defines a path, relative to the web server root, that Bugzilla cookies will be restricted to. For example, if the urlbase is set to http://www.foo.com/bugzilla/, the cookiepath should be set to /bugzilla/. Setting it to "/" will allow all sites served by this web server or virtual host to read Bugzilla cookies.

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 contrib/recode.pl script.

If you turn this parameter from "off" to "on", you must re-run checksetup.pl immediately afterward.

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.

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 editparams.cgi (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).

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 "<div>" tag. Any style attributes from the CSS can be applied. For example, to make the text green inside of a red box, add "id=message" to the "<div>" tag.

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 upgrade_notification parameter (below). If the proxy requires authentication, use the syntax: http://user:pass@proxy_url/.

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.

Defines the regular expression used to validate email addresses used for login names. The default attempts to match fully qualified email addresses (i.e. 'user@example.com'). Some Bugzilla installations allow only local user names (i.e 'user' instead of 'user@example.com'). In that case, the emailsuffix parameter should be used to define the email domain.

This string is appended to login names when actually sending email to a user. For example, If emailregexp has been set to allow local usernames, then this parameter would contain the email domain for all users (i.e. '@example.com').

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.

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!)

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.

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.

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.

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.

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 Section 3.15.2.

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 Saved Searches.

If you want to list "LDAP" 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 data/params and set user_verify_class to "DB".

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: "ldap.company.com" or "ldap.company.com:3268"

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.

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: "ldap://ldap.company.com", LDAP over SSL: "ldaps://ldap.company.com" or LDAP over a UNIX domain socket "ldapi://%2fvar%2flib%2fldap_sock".

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.

Ex. "cn=default,cn=user:password"

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.

Ex. "ou=People,o=Company"

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.

Ex. "uid"

The LDAPmailattribute parameter should be the name of the attribute which contains the email address your users will enter into the Bugzilla login boxes.

Ex. "mail"

If you want to list "RADIUS" 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 data/params and set user_verify_class to "DB".

This parameter should be set to the name (and optionally the port) of your RADIUS server.

This parameter should be set to the RADIUS server's secret.

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.

If this simple solution does not work for you, you'll probably need to modify Bugzilla/Auth/Verify/RADIUS.pm to match your requirements.

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 data/mailer.testfile for later review. "None" disables email sending entirely.

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.

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).

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.