35 lines
1.6 KiB
ReStructuredText
35 lines
1.6 KiB
ReStructuredText
.. _workflow:
|
|
|
|
Workflow
|
|
########
|
|
|
|
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 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`).
|
|
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
|
|
renamed or deleted. (FIXED could be if we fixed
|
|
`bug 1007605 <https://bugzilla.mozilla.org/show_bug.cgi?id=1007605>`_.)
|
|
|
|
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.
|
|
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.
|
|
|
|
The status used as the :param:`duplicate_or_move_bug_status` parameter
|
|
(normally RESOLVED or its equivalent) is required to be a legal transition
|
|
from every other bug status, and so this is enforced on the page.
|
|
|
|
The "View Comments Required on Status Transitions" link below the table
|
|
lets you set which transitions require a comment from the user.
|