Custom workflow (almost) implemented

Hi all,

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 
RESOLVED/VERIFIED/CLOSED).

In Bugzilla 3.0 and older, if a bug has never been
confirmed, reopening 
it will set its state to UNCONFIRMED, else to REOPENED. Now
that you can 
set your own workflow, you could decide that RESOLVED ->
REOPENED is 
allowed, but RESOLVED -> UNCONFIRMED is not. In this
case, the UI in 
show_bug.cgi should display "Change status to
REOPENED" even for bugs 
which have never been confirmed.

On the other hand, if both -> UNCO and -> REOP are
allowed, should the 
UI behave in the old way and only display the
"correct" one based on 
everconfirmed, or assume that both should be displayed as
both are 
present in the workflow?

For consistency with Bugzilla 3.0 and older, I added a hack
in the UI to 
only display the "correct" one (either UNCO or
REOP, but not both). So 
if an admin disable RESOLVED -> UNCONFIRMED from the
workflow and a bug 
has never been confirmed, nothing will be displayed in the
UI to reopen 
it (because the status it expected to display (UNCO) is
forbidden by the 
workflow). On the other hand, you could say: if one
transition is 
forbidden, display the other one. But this is an even bigger
hack. Also, 
if both transitions are allowed, how does Bugzilla know if
you really 
expect the old behavior (select the correct one between UNCO
and REOP) 
or if you want to see both (display both UNCO and REOP)?

I thought it may be a good idea to have a new parameter to
choose if you 
want the old or new behavior. If you select 'old', then
Bugzilla will 
choose between UNCO and REOP. If you select 'new', Bugzilla
will display 
*all* allowed transitions (so you could see both UNCO and
REOP at the 
same time if your workflow says so). What is your opinion on
it?

LpSolit
-
To view or change your list settings, click here:
<http:
//bugzilla.org/cgi-bin/mj_wwwusr?user=bondyahoo.com>

On Sun, 20 May 2007 00:04:18 +0200 Frédéric Buclin
<lpsolitgmail.com>
wrote:
> I thought it may be a good idea to have a new parameter
to choose if
> you want the old or new behavior. If you select 'old',
then Bugzilla
> will choose between UNCO and REOP. If you select 'new',
Bugzilla will
> display *all* allowed transitions (so you could see
both UNCO and
> REOP at the same time if your workflow says so). What
is your opinion
> on it?

	Yeah, I think it will have to be a separate parameter on
the
same page. Something like:

	When a bug is "reopened":
	(a) Set it to UNCONFIRMED if it was previously UNCONFIRMED,
and
REOPENED otherwise.
	(b) Set it to whatever its previous status was.

	And instead of having REOPENED as a status transition, we
can
have an action called "reopen" in the workflow,
and what it does can be
defined as above. And then people can also specify
transitions to NEW
and so on.

	"reopen" should only be allowed from closed
states.

	Having a system like this, where certain status transitions
are
actually defined by a separate parameter, will allow us to
have an even
more flexible system.

	-Max
-- 
http://www.everythin
gsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else,
too.
-
To view or change your list settings, click here:
<http:
//bugzilla.org/cgi-bin/mj_wwwusr?user=bondyahoo.com>

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 
> RESOLVED/VERIFIED/CLOSED).

My proposal: we do not make the state of reopened bugs
dependent on 
their previous opened state. In other words, we abandon the

"everconfirmed" flag.

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 
previous state.

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.

Gerv
-
To view or change your list settings, click here:
<http:
//bugzilla.org/cgi-bin/mj_wwwusr?user=bondyahoo.com>