"fixed" is NOT the same as "closed"

[Daevid Vincent]

Wait a minute!

I just realized that when a developer resolves a ticket as "fixed", Trac
sets the status to "closed"!

Those two things are NOT the same. "fixes" SHOULD mean that a tester can now
go and verify the fix.
ONLY the tester should be able to "close" a ticket.

* status changed from new to closed.
* resolution set to fixed.

In fact, I don't even see a "status" field that I can manipulate. Where the
heck did status come from?

How can we prevent this non-standard behavior?

[Samuel A. Falvo II]

On Mon, Jun 9, 2008 at 4:45 PM, Daevid Vincent <dae...@daevid.com> wrote:
> I just realized that when a developer resolves a ticket as "fixed", Trac
> sets the status to "closed"!

Ouch.

> ONLY the tester should be able to "close" a ticket.

In our organization (NOT using Trac, unfortunately), we use a 3-way handshake:

* Developer sets bug to Fixed.
* QA, upon proper verification, sets the bug to Verified.
* Then either the original developer or the release manager sets it to Closed.

When the bug is marked Verified, we know that it hasn't been
deployed/released yet. When it's Closed, we know that it's been
"shipped."

--
Samuel A. Falvo II

[Chris Mulligan]

That is the standard behavior.

If you'd like to modify it check out the TracWorkflow features in 0.11 at http://trac.edgewall.org/wiki/TracWorkflow

[Noah Kantrowitz]

While one can argue the semantics of a "standard" workflow, the TracWorkflow
page has details on setting up a custom workflow using either the included
(and simple) trac.ini-based syntax, or developing a more complex plugin to
provide ticket actions. You cannot alter the status of a ticket directly, it
is manipulated by workflow actions.

--Noah

[Me Myself]

you also might want to look at the enterprise workflow add-on someone created and I don't have the link atm.  it adds the workflow you are after, plus a handler to prevent the resolver from moving the ticket out of qa to closed.  someone else, with the associated new permission(and did not "fix" it) can QA a ticket and approve it.  I modified this work flow a bit and like it.  It is a big workflow, but I was able to pare it down with a little trial and tweaking, didn't even need to read on how the new ticket workflow worked, but did eventually.

--
There are 10 kinds of people, those that understand binary, and those who don't.

[lfrancis]

Looks like we're going to use this:
http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin

I also took a look at the Enterprise workflow, but the
AdvancedTicketWorkflow Plugin seemed a better match for our process.