Commit d2de194a authored by travis%sedsystems.ca's avatar travis%sedsystems.ca

Bug 274173 : The Params that are listed in section 3.1 (parameters) should use a <varlist/>

Patch by Shane H. W. Travis <travis@sedsystems.ca> r=colin.ogilvie
parent c3408e72
......@@ -16,21 +16,26 @@
<primary>checklist</primary>
</indexterm>
<procedure>
<step>
<variablelist>
<varlistentry>
<term>
maintainer
</term>
<listitem>
<para>
<command>maintainer</command>:
The maintainer parameter is the email address of the person
responsible for maintaining this Bugzilla installation.
The address need not be that of a valid Bugzilla account.
</para>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
urlbase
</term>
<listitem>
<para>
<command>urlbase</command>:
This parameter defines the fully qualified domain name and web
server path to your Bugzilla installation.
</para>
......@@ -41,21 +46,27 @@
set your <quote>urlbase</quote>
to <filename>http://www.foo.com/bugzilla/</filename>.
</para>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
makeproductgroups
</term>
<listitem>
<para>
<command>makeproductgroups</command>:
This dictates whether or not to automatically create groups
when new products are created.
</para>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
useentrygroupdefault
</term>
<listitem>
<para>
<command>useentrygroupdefault</command>:
Bugzilla products can have a group associated with them, so that
certain users can only see bugs in certain products. When this
parameter is set to <quote>on</quote>, this
......@@ -66,12 +77,15 @@
can be further adjusted without interference by
this mechanism.
</para>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
shadowdb
</term>
<listitem>
<para>
<command>shadowdb</command>:
You run into an interesting problem when Bugzilla reaches a
high level of continuous activity. MySQL supports only table-level
write locking. What this means is that if someone needs to make a
......@@ -108,12 +122,15 @@
so that updates reach this readonly mirror. Consult your database
documentation for more detail.
</para>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
shutdownhtml
</term>
<listitem>
<para>
<command>shutdownhtml</command>:
If you need to shut down Bugzilla to perform administration, enter
some descriptive text (with embedded HTML codes, if you'd like)
into this box. Anyone who tries to use Bugzilla (including admins)
......@@ -132,12 +149,15 @@
else).
</para>
</note>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
passwordmail
</term>
<listitem>
<para>
<command>passwordmail</command>:
Every time a user creates an account, the text of this parameter
(with substitutions) is sent to the new user along with their
password message.
......@@ -148,59 +168,73 @@
instance, many people choose to use this box to give a quick
training blurb about how to use Bugzilla at your site.
</para>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
movebugs
</term>
<listitem>
<para>
<command>movebugs</command>:
This option is an undocumented feature to allow moving bugs
between separate Bugzilla installations. You will need to understand
the source code in order to use this feature. Please consult
<filename>movebugs.pl</filename> in your Bugzilla source tree for
further documentation, such as it is.
</para>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
useqacontact
</term>
<listitem>
<para>
<command>useqacontact</command>:
This allows you to define an email address for each component,
in addition to that of the default owner, who will be sent
carbon copies of incoming bugs.
</para>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
usestatuswhiteboard
</term>
<listitem>
<para>
<command>usestatuswhiteboard</command>:
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.
</para>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
whinedays
</term>
<listitem>
<para>
<command>whinedays</command>:
Set this to the number of days you want to let bugs go
in the NEW or REOPENED state before notifying people they have
untouched new bugs. If you do not plan to use this feature, simply
do not set up the whining cron job described in the installation
instructions, or set this value to "0" (never whine).
</para>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
commenton*
</term>
<listitem>
<para>
<command>commenton*</command>:
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
......@@ -225,12 +259,15 @@
fixed!)
</para>
</note>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
supportwatchers
</term>
<listitem>
<para>
<command>supportwatchers</command>:
Turning on this option allows users to ask to receive copies
of bug mail sent to another user. Watching a user with
different group permissions is not a way to 'get around' the
......@@ -238,22 +275,26 @@
permissions of a bug, and <quote>watchers</quote> will only be
copied on emails from bugs they would normally be allowed to view.
</para>
</step>
</listitem>
</varlistentry>
<step>
<varlistentry>
<term>
noresolveonopenblockers
</term>
<listitem>
<para>
<command>noresolveonopenblockers</command>:
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.
</para>
</step>
</listitem>
</varlistentry>
</procedure>
</variablelist>
</section>
<section id="useradmin">
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment