Chapter 7 edits.
git-svn-id: svn://10.0.0.236/trunk@265744 18797224-902f-48f8-a5cc-f745e15eee43
This commit is contained in:
bzrmirror%bugzilla.org
parent
46b79c0f04
commit
0947e51be6
@ -1 +1 @@
|
||||
9270
|
||||
9271
|
||||
@ -1 +1 @@
|
||||
ba9ca333c87c1331eaac7d3a615622b00cbe3ff6
|
||||
04b84c0321807f3d7b6c3acc19fb7fe9dda97251
|
||||
@ -1,8 +1,8 @@
|
||||
.. _categorization:
|
||||
|
||||
==============================================================
|
||||
Classifications, Products, Components, Versions and Milestones
|
||||
==============================================================
|
||||
===============================================================
|
||||
Classifications, Products, Components, Versions, and Milestones
|
||||
===============================================================
|
||||
|
||||
Bugs in Bugzilla are classified into one of a set of admin-defined Components.
|
||||
Components are themselves each part of a single Product. Optionally, Products
|
||||
@ -13,8 +13,8 @@ can be part of a single Classification, adding a third level to the hierarchy.
|
||||
Classifications
|
||||
###############
|
||||
|
||||
Classifications are used in order to group several related
|
||||
products into one distinct entity.
|
||||
Classifications are used to group several related products into one
|
||||
distinct entity.
|
||||
|
||||
For example, if a company makes computer games,
|
||||
they could have a classification of "Games", and a separate
|
||||
@ -25,8 +25,8 @@ containing a few special products that represent items that are not actually
|
||||
shipping products (for example, "Website", or "Administration").
|
||||
|
||||
The classifications layer is disabled by default; it can be turned
|
||||
on or off using the useclassification parameter,
|
||||
in the *Bug Fields* section of the edit parameters screen.
|
||||
on or off using the ``useclassification`` parameter
|
||||
in the *Bug Fields* section of :ref:`parameters`.
|
||||
|
||||
Access to the administration of classifications is controlled using
|
||||
the *editclassifications* system group, which defines
|
||||
@ -74,7 +74,7 @@ It is compulsory to create at least one :ref:`component <components>` in a produ
|
||||
so you will be asked for the details of that too.
|
||||
|
||||
When editing a product you can change all of the above, and there is also a
|
||||
link to edit Group Access Controls, see :ref:`product-group-controls`.
|
||||
link to edit Group Access Controls; see :ref:`product-group-controls`.
|
||||
|
||||
.. _create-product:
|
||||
|
||||
@ -96,14 +96,13 @@ Editing Products
|
||||
================
|
||||
|
||||
To edit an existing product, click the "Products" link from the
|
||||
"Administration" page. If the 'useclassification' parameter is
|
||||
"Administration" page. If the ``useclassification`` parameter is
|
||||
turned on, a table of existing classifications is displayed,
|
||||
including an "Unclassified" category. The table indicates how many products
|
||||
are in each classification. Click on the classification name to see its
|
||||
products. If the 'useclassification' parameter is not in use, the table
|
||||
products. If the ``useclassification`` parameter is not in use, the table
|
||||
lists all products directly. The product table summarizes the information
|
||||
about the product defined
|
||||
when the product was created. Click on the product name to edit these
|
||||
defined when the product was created. Click on the product name to edit these
|
||||
properties, and to access links to other product attributes such as the
|
||||
product's components, versions, milestones, and group access controls.
|
||||
|
||||
@ -112,12 +111,12 @@ product's components, versions, milestones, and group access controls.
|
||||
Adding or Editing Components, Versions and Target Milestones
|
||||
============================================================
|
||||
|
||||
To edit existing, or add new, Components, Versions or Target Milestones
|
||||
to a Product, select the "Edit Components", "Edit Versions" or "Edit
|
||||
To add new or edit existing Components, Versions, or Target Milestones
|
||||
to a Product, select the "Edit Components", "Edit Versions", or "Edit
|
||||
Milestones" links from the "Edit Product" page. A table of existing
|
||||
Components, Versions or Milestones is displayed. Click on a item name
|
||||
Components, Versions, or Milestones is displayed. Click on an item name
|
||||
to edit the properties of that item. Below the table is a link to add
|
||||
a new Component, Version or Milestone.
|
||||
a new Component, Version, or Milestone.
|
||||
|
||||
For more information on components, see :ref:`components`.
|
||||
|
||||
@ -136,7 +135,7 @@ control the relationship of the groups to the product being edited.
|
||||
|
||||
Group Access Controls are an important aspect of using groups for
|
||||
isolating products and restricting access to bugs filed against those
|
||||
products. For more information on groups, including how to create, edit
|
||||
products. For more information on groups, including how to create, edit,
|
||||
add users to, and alter permission of, see :ref:`groups`.
|
||||
|
||||
After selecting the "Edit Group Access Controls" link from the "Edit
|
||||
@ -145,9 +144,9 @@ Bugzilla installation is displayed. The system groups that are created
|
||||
when Bugzilla is installed are not applicable to Group Access Controls.
|
||||
Below is description of what each of these fields means.
|
||||
|
||||
Groups may be applicable (e.g bugs in this product can be associated
|
||||
with this group) , default (e.g. bugs in this product are in this group
|
||||
by default), and mandatory (e.g. bugs in this product must be associated
|
||||
Groups may be applicable (i.e. bugs in this product can be associated
|
||||
with this group), default (i.e. bugs in this product are in this group
|
||||
by default), and mandatory (i.e. bugs in this product must be associated
|
||||
with this group) for each product. Groups can also control access
|
||||
to bugs for a given product, or be used to make bugs for a product
|
||||
totally read-only unless the group restrictions are met. The best way to
|
||||
@ -182,7 +181,7 @@ all products.
|
||||
|
||||
Any group having *editcomponents*
|
||||
selected allows users who are in this group to edit all
|
||||
aspects of this product, including components, milestones
|
||||
aspects of this product, including components, milestones,
|
||||
and versions.
|
||||
|
||||
Any group having *canconfirm* selected
|
||||
@ -208,7 +207,7 @@ Common Applications of Group Controls
|
||||
The use of groups is best explained by providing examples that illustrate
|
||||
configurations for common use cases. The examples follow a common syntax:
|
||||
*Group: Entry, MemberControl, OtherControl, CanEdit,
|
||||
EditComponents, CanConfirm, EditBugs*. Where "Group" is the name
|
||||
EditComponents, CanConfirm, EditBugs*, where "Group" is the name
|
||||
of the group being edited for this product. The other fields all
|
||||
correspond to the table on the "Edit Group Access Controls" page. If any
|
||||
of these options are not listed, it means they are not checked.
|
||||
@ -219,7 +218,7 @@ Basic Product/Group Restriction
|
||||
Suppose there is a product called "Bar". The
|
||||
"Bar" product can only have bugs entered against it by users in the
|
||||
group "Foo". Additionally, bugs filed against product "Bar" must stay
|
||||
restricted to users to "Foo" at all times. Furthermore, only members
|
||||
restricted to users in "Foo" at all times. Furthermore, only members
|
||||
of group "Foo" can edit bugs filed against product "Bar", even if other
|
||||
users could see the bug. This arrangement would achieved by the
|
||||
following:
|
||||
@ -345,7 +344,7 @@ often makes sense to divide Components in Bugzilla according to the
|
||||
natural divisions of responsibility within your Product or
|
||||
company.
|
||||
|
||||
Each component has a default assignee and (if you turned it on in the parameters),
|
||||
Each component has a default assignee and, if you turned it on in the :ref:`parameters`,
|
||||
a QA Contact. The default assignee should be the primary person who fixes bugs in
|
||||
that component. The QA Contact should be the person who will ensure
|
||||
these bugs are completely fixed. The Assignee, QA Contact, and Reporter
|
||||
@ -358,13 +357,13 @@ a bug's life.
|
||||
To create a new Component:
|
||||
|
||||
#. Select the ``Edit components`` link
|
||||
from the ``Edit product`` page
|
||||
from the ``Edit product`` page.
|
||||
|
||||
#. Select the ``Add`` link in the bottom right.
|
||||
|
||||
#. Fill out the ``Component`` field, a
|
||||
short ``Description``, the
|
||||
``Default Assignee``, ``Default CC List``
|
||||
``Default Assignee``, ``Default CC List``,
|
||||
and ``Default QA Contact`` (if enabled).
|
||||
The ``Component Description`` field may contain a
|
||||
limited subset of HTML tags. The ``Default Assignee``
|
||||
@ -382,7 +381,7 @@ the bug.
|
||||
|
||||
To create and edit Versions:
|
||||
|
||||
#. From the "Edit product" screen, select "Edit Versions"
|
||||
#. From the "Edit product" screen, select "Edit Versions".
|
||||
|
||||
#. You will notice that the product already has the default
|
||||
version "undefined". Click the "Add" link in the bottom right.
|
||||
@ -396,14 +395,14 @@ Milestones
|
||||
##########
|
||||
|
||||
Milestones are "targets" that you plan to get a bug fixed by. For
|
||||
example, you have a bug that you plan to fix for your 3.0 release, it
|
||||
example, if you have a bug that you plan to fix for your 3.0 release, it
|
||||
would be assigned the milestone of 3.0.
|
||||
|
||||
.. note:: Milestone options will only appear for a Product if you turned
|
||||
on the "usetargetmilestone" parameter in the "Bug Fields" tab of the
|
||||
"Parameters" page.
|
||||
:ref:`parameters` page.
|
||||
|
||||
To create new Milestones, and set Default Milestones:
|
||||
To create new Milestones and set Default Milestones:
|
||||
|
||||
#. Select "Edit milestones" from the "Edit product" page.
|
||||
|
||||
@ -413,5 +412,5 @@ To create new Milestones, and set Default Milestones:
|
||||
can optionally set the "sortkey", which is a positive or negative
|
||||
number (-32768 to 32767) that defines where in the list this particular
|
||||
milestone appears. This is because milestones often do not
|
||||
occur in alphanumeric order For example, "Future" might be
|
||||
occur in alphanumeric order; for example, "Future" might be
|
||||
after "Release 1.2". Select "Add".
|
||||
|
||||
@ -5,7 +5,7 @@ Custom Fields
|
||||
|
||||
Custom Fields are fields defined by the administrator, in addition to those
|
||||
which come with Bugzilla by default. Custom Fields are treated like any other
|
||||
field - they can be set in bugs and used for search queries.
|
||||
field—they can be set in bugs and used for search queries.
|
||||
|
||||
Administrators should keep in mind that
|
||||
adding too many fields can make the user interface more complicated and
|
||||
@ -39,8 +39,8 @@ The following attributes must be set for each new custom field:
|
||||
be automatically added to the name entered.
|
||||
|
||||
- *Description:*
|
||||
A brief string which is used as the label for this Custom Field.
|
||||
That is the string that users will see, and should be
|
||||
A brief string used as the label for this Custom Field.
|
||||
That is the string that users will see, and it should be
|
||||
short and explicit.
|
||||
|
||||
- *Type:*
|
||||
@ -100,7 +100,7 @@ The following attributes must be set for each new custom field:
|
||||
- *Is mandatory:*
|
||||
Boolean that determines whether this field must be set.
|
||||
For single and multi-select fields, this means that a (non-default)
|
||||
value must be selected, and for text and date fields, some text
|
||||
value must be selected; for text and date fields, some text
|
||||
must be entered.
|
||||
|
||||
- *Field only appears when:*
|
||||
@ -119,9 +119,9 @@ The following attributes must be set for each new custom field:
|
||||
``valueY`` is only available when the bug status
|
||||
is RESOLVED while the value ``valueX`` should
|
||||
always be listed.
|
||||
Once you have selected the field which should control the
|
||||
Once you have selected the field that should control the
|
||||
availability of the values of this custom field, you can
|
||||
edit values of this custom field to set the criteria, see
|
||||
edit values of this custom field to set the criteria; see
|
||||
:ref:`edit-values-list`.
|
||||
|
||||
.. _edit-custom-fields:
|
||||
@ -130,7 +130,7 @@ Editing Custom Fields
|
||||
=====================
|
||||
|
||||
As soon as a Custom Field is created, its name and type cannot be
|
||||
changed. If this field is a drop down menu, its legal values can
|
||||
changed. If this field is a drop-down menu, its legal values can
|
||||
be set as described in :ref:`edit-values-list`. All
|
||||
other attributes can be edited as described above.
|
||||
|
||||
@ -139,11 +139,11 @@ other attributes can be edited as described above.
|
||||
Deleting Custom Fields
|
||||
======================
|
||||
|
||||
Only custom fields which are marked as obsolete, and which never
|
||||
have been used, can be deleted completely (else the integrity
|
||||
Only custom fields that are marked as obsolete, and that have never
|
||||
been used, can be deleted completely (else the integrity
|
||||
of the bug history would be compromised). For custom fields marked
|
||||
as obsolete, a "Delete" link will appear in the ``Action``
|
||||
column. If the custom field has been used in the past, the deletion
|
||||
will be rejected. But marking the field as obsolete is sufficient
|
||||
will be rejected. Marking the field as obsolete, however, is sufficient
|
||||
to hide it from the user interface entirely.
|
||||
|
||||
|
||||
@ -4,11 +4,11 @@ Field Values
|
||||
############
|
||||
|
||||
Legal values for the operating system, platform, bug priority and
|
||||
severity, custom fields of type ``Drop Down`` and
|
||||
severity, and custom fields of type ``Drop Down`` and
|
||||
``Multiple-Selection Box`` (see :ref:`custom-fields`),
|
||||
as well as the list of valid bug statuses and resolutions can be
|
||||
customized from the same interface. You can add, edit, disable and
|
||||
remove values which can be used with these fields.
|
||||
as well as the list of valid bug statuses and resolutions, can be
|
||||
customized from the same interface. You can add, edit, disable, and
|
||||
remove the values that can be used with these fields.
|
||||
|
||||
.. _edit-values-list:
|
||||
|
||||
@ -17,7 +17,7 @@ Viewing/Editing Legal Values
|
||||
|
||||
Editing legal values requires ``admin`` privileges.
|
||||
Select "Field Values" from the Administration page. A list of all
|
||||
fields, both system fields and Custom Fields, for which legal values
|
||||
fields, both system and Custom, for which legal values
|
||||
can be edited appears. Click a field name to edit its legal values.
|
||||
|
||||
There is no limit to how many values a field can have, but each value
|
||||
|
||||
@ -7,7 +7,7 @@ If you have the :group:`editcomponents` permission, you can
|
||||
edit Flag Types from the main administration page. Clicking the
|
||||
:guilabel:`Flags` link will bring you to the :guilabel:`Administer
|
||||
Flag Types` page. Here, you can select whether you want
|
||||
to create (or edit) a Bug flag, or an Attachment flag.
|
||||
to create (or edit) a Bug flag or an Attachment flag.
|
||||
|
||||
The two flag types have the same administration interface, and the interface
|
||||
for creating a flag and editing a flag have the same set of fields.
|
||||
@ -27,13 +27,13 @@ Description
|
||||
The description describes the flag in more detail. It is visible
|
||||
in a tooltip when hovering over a flag either in the :guilabel:`Show Bug`
|
||||
or :guilabel:`Edit Attachment` pages. This field can be as
|
||||
long as you like, and can contain any character you want.
|
||||
long as you like and can contain any character you want.
|
||||
|
||||
Category
|
||||
You can set a flag to be visible or not visible on any combination of
|
||||
products and components.
|
||||
|
||||
Default behaviour for a newly-created flag is to appear on
|
||||
Default behaviour for a newly created flag is to appear on all
|
||||
products and all components, which is why ``__Any__:__Any__``
|
||||
is already entered in the :guilabel:`Inclusions` box.
|
||||
If this is not your desired behaviour, you must either set some
|
||||
@ -50,30 +50,30 @@ Category
|
||||
Selections made, press :guilabel:`Include`, and your
|
||||
Product/Component pairing will show up in the :guilabel:`Inclusions` box on the right.
|
||||
|
||||
To create an Exclusion, the process is the same; select a Product from the
|
||||
To create an Exclusion, the process is the same: select a Product from the
|
||||
top drop-down box, select a specific component if you want one, and press
|
||||
:guilabel:`Exclude`. The Product/Component pairing will show up in the
|
||||
:guilabel:`Exclusions` box on the right.
|
||||
|
||||
This flag *will* and *can* be set for any
|
||||
products/components that appearing in the :guilabel:`Inclusions` box
|
||||
This flag *will* appear and *can* be set for any
|
||||
products/components appearing in the :guilabel:`Inclusions` box
|
||||
(or which fall under the appropriate ``__Any__``).
|
||||
This flag *will not* appear (and therefore cannot be set) on
|
||||
This flag *will not* appear (and therefore *cannot* be set) on
|
||||
any products appearing in the :guilabel:`Exclusions` box.
|
||||
*IMPORTANT: Exclusions override inclusions.*
|
||||
|
||||
You may select a Product without selecting a specific Component,
|
||||
but you can't select a Component without a Product, or to select a
|
||||
Component that does not belong to the named Product. If you do so,
|
||||
but you cannot select a Component without a Product. If you do so,
|
||||
Bugzilla will display an error message, even if all your products
|
||||
have a component by that name.
|
||||
have a component by that name. You will also see an error if you
|
||||
select a Component that does not belong to the selected Product.
|
||||
|
||||
*Example:* Let's say you have a product called
|
||||
``Jet Plane`` that has thousands of components. You want
|
||||
to be able to ask if a problem should be fixed in the next model of
|
||||
plane you release. We'll call the flag ``fixInNext``.
|
||||
But, there's one component in ``Jet Plane,``
|
||||
called ``Pilot.`` It doesn't make sense to release a
|
||||
However, one component in ``Jet Plane`` is
|
||||
called ``Pilot``, and it doesn't make sense to release a
|
||||
new pilot, so you don't want to have the flag show up in that component.
|
||||
So, you include ``Jet Plane:__Any__`` and you exclude
|
||||
``Jet Plane:Pilot``.
|
||||
@ -85,25 +85,26 @@ Sort Key
|
||||
sort key. Flags that have the same sort key will be sorted alphabetically.
|
||||
|
||||
Active
|
||||
Sometimes, you might want to keep old flag information in the
|
||||
Bugzilla database, but stop users from setting any new flags of this type.
|
||||
Sometimes you might want to keep old flag information in the
|
||||
Bugzilla database but stop users from setting any new flags of this type.
|
||||
To do this, uncheck :guilabel:`active`. Deactivated
|
||||
flags will still show up in the UI if they are ``?``, ``+``, or ``-``, but
|
||||
they may only be cleared (unset), and cannot be changed to a new value.
|
||||
they may only be cleared (unset) and cannot be changed to a new value.
|
||||
Once a deactivated flag is cleared, it will completely disappear from a
|
||||
bug/attachment, and cannot be set again.
|
||||
bug/attachment and cannot be set again.
|
||||
|
||||
Requestable
|
||||
New flags are, by default, "requestable", meaning that they
|
||||
offer users the ``?`` option, as well as ``+``
|
||||
and ``-``.
|
||||
To remove the ? option, uncheck "requestable".
|
||||
To remove the ``?`` option, uncheck "requestable".
|
||||
|
||||
Specifically Requestable
|
||||
By default this box is checked for new flags, meaning that users may make
|
||||
flag requests of specific individuals. Unchecking this box will remove the
|
||||
text box next to a flag; if it is still requestable, then requests may
|
||||
only be made "to the wind". Removing this after specific
|
||||
text box next to a flag; if it is still requestable, then requests
|
||||
cannot target specific users and are open to anyone (called a
|
||||
request "to the wind" in Bugzilla). Removing this after specific
|
||||
requests have been made will not remove those requests; that data will
|
||||
stay in the database (though it will no longer appear to the user).
|
||||
|
||||
@ -116,7 +117,7 @@ Multiplicable
|
||||
|
||||
CC List
|
||||
If you want certain users to be notified every time this flag is
|
||||
set to ``?``, ``-``, ``+``, or unset, add them here. This is a comma-separated
|
||||
set to ``?``, ``-``, or ``+``, or is unset, add them here. This is a comma-separated
|
||||
list of email addresses that need not be restricted to Bugzilla usernames.
|
||||
|
||||
Grant Group
|
||||
|
||||
@ -40,7 +40,7 @@ the bug. For information on granting read-only access to certain people and
|
||||
full edit access to others, see :ref:`product-group-controls`.
|
||||
|
||||
.. note:: By default, bugs can also be seen by the Assignee, the Reporter, and
|
||||
by everyone on the CC List, regardless of whether or not the bug would
|
||||
everyone on the CC List, regardless of whether or not the bug would
|
||||
typically be viewable by them. Visibility to the Reporter and CC List can
|
||||
be overridden (on a per-bug basis) by bringing up the bug, finding the
|
||||
section that starts with ``Users in the roles selected below...``
|
||||
@ -77,7 +77,7 @@ To create a new group, follow the steps below:
|
||||
to match the regular expression. If their email address changes
|
||||
and no longer matches the regular expression, they will be removed
|
||||
from the group. Versions 2.16 and older of Bugzilla did not automatically
|
||||
remove users who's email addresses no longer matched the RegExp.
|
||||
remove users whose email addresses no longer matched the RegExp.
|
||||
|
||||
.. warning:: If specifying a domain in the regular expression, end
|
||||
the regexp with a "$". Otherwise, when granting access to
|
||||
@ -103,13 +103,13 @@ you wish to edit or control permissions for.
|
||||
|
||||
The "Edit Groups" page contains the same five fields present when
|
||||
creating a new group. Below that are two additional sections, "Group
|
||||
Permissions," and "Mass Remove". The "Mass Remove" option simply removes
|
||||
Permissions" and "Mass Remove". The "Mass Remove" option simply removes
|
||||
all users from the group who match the regular expression entered. The
|
||||
"Group Permissions" section requires further explanation.
|
||||
|
||||
The "Group Permissions" section on the "Edit Groups" page contains four sets
|
||||
of permissions that control the relationship of this group to other
|
||||
groups. If the 'usevisibilitygroups' parameter is in use (see
|
||||
groups. If the ``usevisibilitygroups`` parameter is in use (see
|
||||
:ref:`parameters`) two additional sets of permissions are displayed.
|
||||
Each set consists of two select boxes. On the left, a select box
|
||||
with a list of all existing groups. On the right, a select box listing
|
||||
@ -142,13 +142,13 @@ Each of the six permissions is described below.
|
||||
|
||||
*Groups That Can See This Group*
|
||||
Members of any selected group can see the users in this group.
|
||||
This setting is only visible if the 'usevisibilitygroups' parameter
|
||||
This setting is only visible if the ``usevisibilitygroups`` parameter
|
||||
is enabled on the Bugzilla Configuration page. See
|
||||
:ref:`parameters` for information on configuring Bugzilla.
|
||||
|
||||
*Groups That This Group Can See*
|
||||
Members of this group can see members in any of the selected groups.
|
||||
This setting is only visible if the 'usevisibilitygroups' parameter
|
||||
This setting is only visible if the ``usevisibilitygroups`` parameter
|
||||
is enabled on the the Bugzilla Configuration page. See
|
||||
:ref:`parameters` for information on configuring Bugzilla.
|
||||
|
||||
@ -164,7 +164,7 @@ A User can become a member of a group in several ways:
|
||||
from the "Administration" page. Use the search form to find the user
|
||||
you want to edit group membership for, and click on their email
|
||||
address in the search results to edit their profile. The profile
|
||||
page lists all the groups, and indicates if the user is a member of
|
||||
page lists all the groups and indicates if the user is a member of
|
||||
the group either directly or indirectly. More information on indirect
|
||||
group membership is below. For more details on User Administration,
|
||||
see :ref:`users`.
|
||||
|
||||
@ -6,10 +6,10 @@ Keywords
|
||||
The administrator can define keywords which can be used to tag and
|
||||
categorise bugs. For example, the keyword "regression" is commonly used.
|
||||
A company might have a policy stating all regressions
|
||||
must be fixed by the next release - this keyword can make tracking those
|
||||
must be fixed by the next release—this keyword can make tracking those
|
||||
bugs much easier.
|
||||
|
||||
Keywords are global, rather than per-product. If the administrator changes
|
||||
Keywords are global, rather than per product. If the administrator changes
|
||||
a keyword currently applied to any bugs, the keyword cache must be rebuilt
|
||||
using the :ref:`sanity-check` script.
|
||||
|
||||
@ -17,7 +17,7 @@ using the :ref:`sanity-check` script.
|
||||
|
||||
Currently keywords cannot be marked obsolete to prevent future usage.
|
||||
|
||||
Keywords can be created, edited or deleted by clicking the "Keywords"
|
||||
link in the admin page. There are two fields for each keyword - the keyword
|
||||
Keywords can be created, edited, or deleted by clicking the "Keywords"
|
||||
link in the admin page. There are two fields for each keyword—the keyword
|
||||
itself and a brief description.
|
||||
|
||||
|
||||
@ -101,12 +101,12 @@ announcehtml
|
||||
upgrade_notification
|
||||
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 :paramval:`disabled`,
|
||||
notification is only visible to administrators. Choose :paramval:`disabled`
|
||||
to turn off the notification. Otherwise, choose which version of
|
||||
Bugzilla you want to be notified about: :paramval:`development_snapshot` is the
|
||||
latest release on the trunk:paramval:`latest_stable_release` is the most
|
||||
recent release available on the most recent stable branch;
|
||||
:paramval:`stable_branch_release` the most recent release on the branch
|
||||
latest release from the master branch, :paramval:`latest_stable_release` is the most
|
||||
recent release available on the most recent stable branch, and
|
||||
:paramval:`stable_branch_release` is the most recent release on the branch
|
||||
this installation is based on.
|
||||
|
||||
.. _param-administrative-policies:
|
||||
@ -163,7 +163,7 @@ user_verify_class
|
||||
|
||||
* :paramval:`DB`: Bugzilla's built-in authentication. This is the most common choice.
|
||||
* :paramval:`RADIUS`: RADIUS authentication using a RADIUS server. Using this method requires additional parameters to be set. Please see :ref:`param-radius` for more information.
|
||||
* :paramval:`LDAP1: LDAP authentication using an LDAP server. Using this method requires additional parameters to be set. Please see :ref:`param-ldap` for more information.
|
||||
* :paramval:`LDAP`: LDAP authentication using an LDAP server. Using this method requires additional parameters to be set. Please see :ref:`param-ldap` for more information.
|
||||
|
||||
rememberlogin
|
||||
Controls management of session cookies.
|
||||
@ -192,7 +192,7 @@ emailsuffix
|
||||
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 :param:`emailregexp` param to only allow local usernames, but you want the mail to be delivered to username\@my.local.hostname.
|
||||
|
||||
createemailregexp
|
||||
This defines the (case-insensitive) regexp to use for email addresses that are permitted to self-register. The default (.*) 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.
|
||||
This defines the (case-insensitive) regexp to use for email addresses that are permitted to self-register. The default (:paramval:`.*`) 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.
|
||||
|
||||
password_complexity
|
||||
Set the complexity required for passwords. In all cases must the passwords be at least 6 characters long.
|
||||
@ -270,7 +270,7 @@ musthavemilestoneonaccept
|
||||
|
||||
commenton*
|
||||
All these fields allow you to dictate what changes can pass
|
||||
without comment, and which must have a comment from the
|
||||
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
|
||||
@ -299,7 +299,7 @@ Bug Fields
|
||||
==========
|
||||
|
||||
The parameters in this section determine the default settings of
|
||||
several Bugzilla fields for new bugs, and also control whether
|
||||
several Bugzilla fields for new bugs and whether
|
||||
certain fields are used. For example, choose whether to use the
|
||||
:field:`Target Milestone` field or the :field:`Status Whiteboard` field.
|
||||
|
||||
@ -313,15 +313,15 @@ usetargetmilestone
|
||||
|
||||
useqacontact
|
||||
This allows you to define an email address for each component,
|
||||
in addition to that of the default assignee, who will be sent
|
||||
in addition to that of the default assignee, that will be sent
|
||||
carbon copies of incoming bugs.
|
||||
|
||||
usestatuswhiteboard
|
||||
This defines whether you wish to have a free-form, overwritable field
|
||||
associated with each bug. The advantage of the :field:`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.
|
||||
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.
|
||||
|
||||
use_see_also
|
||||
Do you wish to use the :field:`See Also` field? It allows you mark bugs
|
||||
@ -346,7 +346,7 @@ defaultopsys
|
||||
that the browser reports to be running on as the default.
|
||||
|
||||
collapsed_comment_tags
|
||||
A comma separated list of tags which, when applied to comments, will
|
||||
A comma-separated list of tags which, when applied to comments, will
|
||||
cause them to be collapsed by default.
|
||||
|
||||
.. _param-dependency-graphs:
|
||||
@ -354,7 +354,7 @@ collapsed_comment_tags
|
||||
Graphs
|
||||
======
|
||||
|
||||
Bugzilla can draw graphs of bug dependency relationships, using a tool called
|
||||
Bugzilla can draw graphs of bug-dependency relationships, using a tool called
|
||||
:file:`dot` (from the `GraphViz project <http://graphviz.org/>`_) 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
|
||||
@ -365,13 +365,13 @@ webdotbase
|
||||
|
||||
* A complete file path to :command:`dot` (part of GraphViz), which will
|
||||
generate the graphs locally.
|
||||
* A URL prefix pointing to an installation of the webdot package, which
|
||||
* A URL prefix pointing to an installation of the Web Dot package, which
|
||||
will generate the graphs remotely.
|
||||
* A blank value, which will disable dependency graphing.
|
||||
|
||||
The default value is blank. We recommend using a local install of
|
||||
:file:`dot`. If you change this value to a web service, make certain that
|
||||
the webdot server can read files from your webdot directory. On Apache
|
||||
the Web Dot server can read files from your Web Dot directory. On Apache
|
||||
you do this by editing the :file:`.htaccess` file; for other systems the
|
||||
needed measures may vary. You can run :command:`checksetup.pl` to
|
||||
recreate the :file:`.htaccess` file if it has been lost.
|
||||
@ -398,7 +398,7 @@ Several parameters are described in more detail below. Most of the
|
||||
configuration of groups and their relationship to products is done
|
||||
on the :guilabel:`Groups` and :guilabel:`Product` pages of the
|
||||
:guilabel:`Administration` area.
|
||||
The options on this page control global default behaviour.
|
||||
The options on this page control global default behavior.
|
||||
For more information on Groups and Group Security, see
|
||||
:ref:`groups`.
|
||||
|
||||
@ -425,7 +425,7 @@ querysharegroup
|
||||
saved searches, see :ref:`saved-searches`.
|
||||
|
||||
comment_taggers_group
|
||||
The name of the group of users who can tag comment. Setting this to empty disables comment tagging.
|
||||
The name of the group of users who can tag comments. Setting this to empty disables comment tagging.
|
||||
|
||||
debug_group
|
||||
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.
|
||||
@ -439,7 +439,12 @@ usevisibilitygroups
|
||||
restrictions) see :ref:`edit-groups`.
|
||||
|
||||
or_groups
|
||||
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, if the user has a role on the bug (e.g. reporter) that may also affect their permissions.
|
||||
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.
|
||||
|
||||
.. _param-ldap:
|
||||
|
||||
@ -451,7 +456,7 @@ authentication architecture. This page contains all the parameters
|
||||
necessary to configure Bugzilla for use with LDAP authentication.
|
||||
|
||||
The existing authentication
|
||||
scheme for Bugzilla uses email addresses as the primary user ID, and a
|
||||
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
|
||||
@ -459,7 +464,7 @@ 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 :param:`emailsuffix` parameter is appended to
|
||||
attribute is used; otherwise, the :param:`emailsuffix` 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
|
||||
@ -496,15 +501,15 @@ LDAPserver
|
||||
For example: :paramval:`ldap.company.com`
|
||||
or :paramval:`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
|
||||
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.
|
||||
|
||||
.. note:: 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:
|
||||
:paramval:`ldap://ldap.company.com`, LDAP over SSL:
|
||||
:paramval:`ldaps://ldap.company.com` or LDAP over a UNIX
|
||||
For example, normal LDAP
|
||||
:paramval:`ldap://ldap.company.com`, LDAP over SSL
|
||||
:paramval:`ldaps://ldap.company.com`, or LDAP over a UNIX
|
||||
domain socket :paramval:`ldapi://%2fvar%2flib%2fldap_sock`.
|
||||
|
||||
LDAPstarttls
|
||||
@ -576,11 +581,11 @@ RADIUS_NAS_IP
|
||||
RADIUS server. If unspecified, 127.0.0.1 will be used.
|
||||
|
||||
RADIUS_email_suffix
|
||||
Bugzilla needs an e-mail address for each user account.
|
||||
Therefore, it needs to determine the e-mail address corresponding
|
||||
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 e-mail
|
||||
a suffix to the RADIUS user name to convert it into an email
|
||||
address.
|
||||
You can specify this suffix in the RADIUS_email_suffix parameter.
|
||||
If this simple solution does not work for you, you'll
|
||||
@ -608,16 +613,16 @@ mail_delivery_method
|
||||
mailfrom
|
||||
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
|
||||
servers require mail to be from a valid email address; therefore,
|
||||
it is recommended to choose a valid email address here.
|
||||
|
||||
use_mailer_queue
|
||||
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 :file:`checksetup.pl` for this feature), and that you are running the :file:`jobqueue.pl` daemon (otherwise your mail won't get sent). This affects all mail sent by Bugzilla, not just bug updates.
|
||||
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 :file:`checksetup.pl` for this feature), and that you are running the :file:`jobqueue.pl` daemon (otherwise your mail won't get sent). This affects all mail sent by Bugzilla, not just bug updates.
|
||||
|
||||
smtpserver
|
||||
The SMTP server address, if the :param:`mail_delivery_method`
|
||||
parameter is set to :paramval:`SMTP`. Use :paramval:`localhost` if you have a local MTA
|
||||
running, otherwise use a remote SMTP server. Append ":" and the port
|
||||
running; otherwise, use a remote SMTP server. Append ":" and the port
|
||||
number if a non-default port is needed.
|
||||
|
||||
smtp_username
|
||||
@ -648,7 +653,7 @@ globalwatchers
|
||||
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.
|
||||
mailing list, for instance.
|
||||
|
||||
.. _param-querydefaults:
|
||||
|
||||
@ -665,22 +670,25 @@ quip_list_entry_control
|
||||
Controls how easily users can add entries to the quip list.
|
||||
|
||||
* :paramval:`open` - Users may freely add to the quip list, and their entries will immediately be available for viewing.
|
||||
* :paramval:`moderated` - quips can be entered, but need to be approved by a moderator before they will be shown.
|
||||
* :paramval:`closed` - no new additions to the quips list are allowed.
|
||||
* :paramval:`moderated` - Quips can be entered but need to be approved by a moderator before they will be shown.
|
||||
* :paramval:`closed` - No new additions to the quips list are allowed.
|
||||
|
||||
mybugstemplate
|
||||
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.
|
||||
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.
|
||||
|
||||
defaultquery
|
||||
This is the default query that initially comes up when you access the advanced query page. It's in URL parameter format.
|
||||
This is the default query that initially comes up when you access
|
||||
the advanced query page. It's in URL-parameter format.
|
||||
|
||||
search_allow_no_criteria
|
||||
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.
|
||||
|
||||
default_search_limit
|
||||
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.
|
||||
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.
|
||||
|
||||
Usually you should not have to change this - the default value should be acceptable for most installations.
|
||||
Usually you should not have to change this—the default value should be acceptable for most installations.
|
||||
|
||||
max_search_results
|
||||
The maximum number of bugs that a search can ever return. Tabular and graphical reports are exempted from this limit, however.
|
||||
@ -702,7 +710,7 @@ 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).
|
||||
|
||||
Bugzilla does not make sure the shadowdb is kept up to date so if you use
|
||||
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.
|
||||
|
||||
If your shadowdb is on a different machine, specify :param:`shadowdbhost`
|
||||
@ -729,12 +737,12 @@ Memcached
|
||||
|
||||
memcached_servers
|
||||
If this option is set, Bugzilla will integrate with `Memcached
|
||||
<http://www.memcached.org/>`_. Specify one of more server, separated by
|
||||
<http://www.memcached.org/>`_. Specify one or more servers, separated by
|
||||
spaces, using hostname:port notation (for example:
|
||||
:paramval:`127.0.0.1:11211`).
|
||||
|
||||
memcached_namespace
|
||||
Specify a string to prefix to each key on Memcached.
|
||||
Specify a string to prefix each key on Memcached.
|
||||
|
||||
.. _admin-usermatching:
|
||||
|
||||
@ -743,7 +751,7 @@ User Matching
|
||||
|
||||
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
|
||||
when assigning the bug, 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.
|
||||
@ -755,12 +763,16 @@ usemenuforusers
|
||||
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.
|
||||
|
||||
ajax_user_autocompletion
|
||||
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, because otherwise the response will be irritatingly slow.
|
||||
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.
|
||||
|
||||
maxusermatches
|
||||
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.
|
||||
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.
|
||||
|
||||
confirmuniqueusermatch
|
||||
Whether a confirmation screen should be displayed when only one user matches a search entry.
|
||||
|
||||
@ -4,31 +4,30 @@ Quips
|
||||
#####
|
||||
|
||||
Quips are small user-defined messages (often quotes or witty sayings) that
|
||||
can be configured to appear at the top of thesearch results. Each Bugzilla
|
||||
can be configured to appear at the top of search results. Each Bugzilla
|
||||
installation has its own specific quips. Whenever a quip needs to be
|
||||
displayed, a random selection is made from the pool of already existing quips.
|
||||
|
||||
Quip submission is controlled by the *quip_list_entry_control*
|
||||
parameter. It has several possible values: open, moderated, or closed.
|
||||
In order to enable quips approval you need to set this parameter to
|
||||
"moderated". In this way, users are free to submit quips for addition
|
||||
"moderated". In this way, users are free to submit quips for addition,
|
||||
but an administrator must explicitly approve them before they are
|
||||
actually used.
|
||||
|
||||
In order to see the user interface for the quips, it is enough to click
|
||||
on a quip when it is displayed together with the search results. Or
|
||||
it can be seen directly in the browser by visiting the quips.cgi URL
|
||||
In order to see the user interface for the quips, you can
|
||||
click on a quip when it is displayed together with the search
|
||||
results. You can also go directly to the quips.cgi URL
|
||||
(prefixed with the usual web location of the Bugzilla installation).
|
||||
Once the quip interface is displayed, it is enough to click the
|
||||
"view and edit the whole quip list" in order to see the administration
|
||||
page. A page with all the quips available in the database will
|
||||
be displayed.
|
||||
Once the quip interface is displayed, the "view and edit the whole
|
||||
quip list" link takes you to the quips administration page, which
|
||||
lists all quips available in the database.
|
||||
|
||||
Next to each quip there is a checkbox, under the
|
||||
"Approved" column. Quips who have this checkbox checked are
|
||||
"Approved" column. Quips that have this checkbox checked are
|
||||
already approved and will appear next to the search results.
|
||||
The ones that have it unchecked are still preserved in the
|
||||
database but they will not appear on search results pages.
|
||||
database but will not appear on search results pages.
|
||||
User submitted quips have initially the checkbox unchecked.
|
||||
|
||||
Also, there is a delete link next to each quip,
|
||||
|
||||
@ -8,11 +8,11 @@ Users
|
||||
Creating Admin Users
|
||||
====================
|
||||
|
||||
When you first run checksetup.pl after installing Bugzilla, it
|
||||
will prompt you for the administrative username (email address) and
|
||||
password for the first admin user. If for some reason you delete
|
||||
all the admin users, re-running checksetup.pl will again prompt
|
||||
you for a username and password and make a new admin.
|
||||
When you first run checksetup.pl after installing Bugzilla, it will
|
||||
prompt you for the username (email address) and password for the first
|
||||
admin user. If for some reason you delete all the admin users,
|
||||
re-running checksetup.pl will again prompt you for a username and
|
||||
password and make a new admin.
|
||||
|
||||
If you wish to add more administrative users, add them to the "admin" group.
|
||||
|
||||
@ -76,10 +76,10 @@ fields:
|
||||
|
||||
- *Disable Text*:
|
||||
If you type anything in this box, including just a space, the
|
||||
user is prevented from logging in, or making any changes to
|
||||
user is prevented from logging in and from making any changes to
|
||||
bugs via the web interface.
|
||||
The HTML you type in this box is presented to the user when
|
||||
they attempt to perform these actions, and should explain
|
||||
they attempt to perform these actions and should explain
|
||||
why the account was disabled.
|
||||
Users with disabled accounts will continue to receive
|
||||
mail from Bugzilla; furthermore, they will not be able
|
||||
@ -89,8 +89,8 @@ fields:
|
||||
``Bugmail Disabled`` checkbox above.
|
||||
|
||||
.. note:: Even users whose accounts have been disabled can still
|
||||
submit bugs via the e-mail gateway, if one exists.
|
||||
The e-mail gateway should *not* be
|
||||
submit bugs via the email gateway, if one exists.
|
||||
The email gateway should *not* be
|
||||
enabled for secure installations of Bugzilla.
|
||||
|
||||
.. warning:: Don't disable all the administrator accounts!
|
||||
@ -120,17 +120,16 @@ fields:
|
||||
|
||||
- *editcomponents*:
|
||||
This flag allows a user to create new products and components,
|
||||
as well as modify and destroy those that have no bugs associated
|
||||
with them. If a product or component has bugs associated with it,
|
||||
those bugs must be moved to a different product or component
|
||||
before Bugzilla will allow them to be destroyed.
|
||||
modify existing products and components, and destroy those that have
|
||||
no bugs associated with them. If a product or component has bugs
|
||||
associated with it, those bugs must be moved to a different product
|
||||
or component before Bugzilla will allow them to be destroyed.
|
||||
|
||||
- *editkeywords*:
|
||||
If you use Bugzilla's keyword functionality, enabling this
|
||||
feature allows a user to create and destroy keywords. As always,
|
||||
the keywords for existing bugs containing the keyword the user
|
||||
wishes to destroy must be changed before Bugzilla will allow it
|
||||
to die.
|
||||
feature allows a user to create and destroy keywords. A keyword
|
||||
must be removed from any bugs upon which it is currently set
|
||||
before it can be destroyed.
|
||||
|
||||
- *editusers*:
|
||||
This flag allows a user to do what you're doing right now: edit
|
||||
@ -167,9 +166,9 @@ Self-Registration
|
||||
By default, users can create their own user accounts by clicking the
|
||||
``New Account`` link at the bottom of each page (assuming
|
||||
they aren't logged in as someone else already). If you want to disable
|
||||
this self-registration, or if you want to restrict who can create his
|
||||
this self-registration, or if you want to restrict who can create their
|
||||
own user account, you have to edit the ``createemailregexp``
|
||||
parameter in the ``Configuration`` page, see
|
||||
parameter in the ``Configuration`` page; see
|
||||
:ref:`parameters`.
|
||||
|
||||
.. _user-account-creation:
|
||||
@ -201,9 +200,9 @@ can create user accounts for other users:
|
||||
Deleting Users
|
||||
==============
|
||||
|
||||
If the ``allowuserdeletion`` parameter is turned on, see
|
||||
:ref:`parameters`, then you can also delete user accounts.
|
||||
Note that this is most of the time not the best thing to do. If only
|
||||
If the ``allowuserdeletion`` parameter is turned on (see
|
||||
:ref:`parameters`) then you can also delete user accounts.
|
||||
Note that, most of the time, this is not the best thing to do. If only
|
||||
a warning in a yellow box is displayed, then the deletion is safe.
|
||||
If a warning is also displayed in a red box, then you should NOT try
|
||||
to delete the user account, else you will get referential integrity
|
||||
|
||||
@ -5,8 +5,8 @@ Whining
|
||||
|
||||
Whining is a feature in Bugzilla that can regularly annoy users at
|
||||
specified times. Using this feature, users can execute saved searches
|
||||
at specific times (i.e. the 15th of the month at midnight) or at
|
||||
regular intervals (i.e. every 15 minutes on Sundays). The results of the
|
||||
at specific times (e.g. the 15th of the month at midnight) or at
|
||||
regular intervals (e.g. every 15 minutes on Sundays). The results of the
|
||||
searches are sent to the user, either as a single email or as one email
|
||||
per bug, along with some descriptive text.
|
||||
|
||||
@ -17,7 +17,7 @@ per bug, along with some descriptive text.
|
||||
the quotes).
|
||||
|
||||
Also worth noting is the bz_canusewhineatothers group. Members of this
|
||||
group can create whines for any user or group in Bugzilla using a
|
||||
group can create whines for any user or group in Bugzilla using an
|
||||
extended form of the whining interface. Features only available to
|
||||
members of the bz_canusewhineatothers group will be noted in the
|
||||
appropriate places.
|
||||
@ -117,7 +117,7 @@ opportunity to create one (see :ref:`list`).
|
||||
|
||||
.. note:: When running searches, the whining system acts as if you are the user
|
||||
executing the search. This means that the whining system will ignore
|
||||
bugs that match your search, but that you cannot access.
|
||||
bugs that match your search but that you cannot access.
|
||||
|
||||
Once you have chosen the saved search to be executed, give the search a
|
||||
descriptive title. This title will appear in the email, above the
|
||||
@ -135,7 +135,7 @@ email, or if each bug should appear in its own email.
|
||||
Saving Your Changes
|
||||
===================
|
||||
|
||||
Once you have defined at least one schedule, and created at least one
|
||||
Once you have defined at least one schedule and created at least one
|
||||
search, go ahead and "Update/Commit". This will save your Event and make
|
||||
it available for immediate execution.
|
||||
|
||||
|
||||
@ -3,17 +3,16 @@
|
||||
Workflow
|
||||
########
|
||||
|
||||
The bug status workflow - which statuses are valid transitions from which
|
||||
other statuses - can be customized.
|
||||
The bug status workflow—which statuses are valid transitions from which
|
||||
other statuses—can be customized.
|
||||
|
||||
You need to begin by defining the statuses and resolutions you want to use
|
||||
(see :ref:`field-values`). By convention, these are capitalized.
|
||||
(see :ref:`field-values`). By convention, these are in all capital letters.
|
||||
|
||||
Only one bug status, UNCONFIRMED, can never be renamed nor deleted. However,
|
||||
it can be disabled entirely on a per-product basis (see :ref:`categorization`).
|
||||
One other status may be
|
||||
marked as undeletable, because it's the value of the
|
||||
:param:`duplicate_or_move_bug_status` parameter. To make it deletable,
|
||||
The status referred to by the :param:`duplicate_or_move_bug_status` parameter, if
|
||||
set, is also undeletable. To make it deletable,
|
||||
simply set the value of that parameter to a different status.
|
||||
|
||||
Aside from the empty value, two resolutions, DUPLICATE and FIXED, cannot be
|
||||
@ -22,8 +21,8 @@ renamed or deleted. (FIXED could be if we fixed
|
||||
|
||||
Once you have defined your statuses, you can configure the workflow of
|
||||
how a bug moves between them. The workflow configuration
|
||||
page displays all existing bug statuses twice, first on the left for the
|
||||
starting status and on the top for the target status in the transition.
|
||||
page displays all existing bug statuses twice: first on the left for the
|
||||
starting status, and on the top for the target status in the transition.
|
||||
If the checkbox is checked, then the transition from the left to the top
|
||||
status is legal; if it's unchecked, that transition is forbidden.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user