Custom workflow (almost) implemented
gerv at mozilla.org
Mon May 21 11:22:41 UTC 2007
A key point before I start: I believe it's an extremely important
principle of the custom workflow design that, aside from being
designated as "open" or "closed" (note: I am making a distinction
between "closed" and CLOSED; the former is a class of statuses, the
latter a particular status in that class), there should be no "special"
states. That is, there should be no code in Bugzilla which references
particular states by name.
Frédéric Buclin wrote:
> I have (almost) implemented custom workflow in Bugzilla 3.1. I still
> have a few lines of code to fix, but it's mostly working. One thing I
> have to think about is what to do with this UNCONFIRMED/REOPENED
> behavior when reopening a closed bug ('closed' as in
My proposal: we do not make the state of reopened bugs dependent on
their previous opened state. In other words, we abandon the
In specific terms, using the workflow we have today, that would mean
that bugs would always go to REOPENED, and never to UNCONFIRMED.
I think this is the right thing to do for several reasons.
The first is that it preserves the principle I outline at the top,
thereby simplifying both the implementation and the model in the user's
mind of how custom workflow works.
It also makes good sense. As it's now possible to change resolutions
while a bug is closed, that means that if you are reopening a bug, it
must be because you want someone to work on it some more - i.e. you have
some information that it is a bug. So UNCONFIRMED is inappropriate.
Under the current workflow, there is no way to re-enter UNCONFIRMED, and
so this feature has some possible uses. With a custom workflow, that no
longer has to be the case. If people want to be able to take occasional
bugs back to UNCONFIRMED based on the quality of the bug report, they
can enable the REOPENED -> UNCONFIRMED transition. But this decision
should be based on the information in the report, rather than the
It would be interesting to see how many bugs in b.m.o. were reopened and
set back to UNCONFIRMED by the everconfirmed flag, only for the triager
to have to go in and change it to NEW.
More information about the developers