Correct TracTickets diagram (reassign -> new)

[anonymous]

About Diagram on TracTickets page, I think that reassigned ticket's status is "new".

[anonymous]

Can I make a comment to this:

The picture in the documentation makes sense. A ticket should only be NEW, if it was created. With the first change it must leave the status NEW.

If I reassign a new person, the ticket is not used, it is only new for the assigned person. I request, that the status shall be (re)assign.

[Humberto Diógenes <humberto---digi.com.br>]

Well, I personally think that reassigned tickets should be kept as assigned (not be reverted to new), but there's already a NewWorkflow proposal (#869) that keeps the same behavior as today.

The conclusion is that the TracTickets diagram isn't correct - the arrow points in the wrong direction, so I'm changing this ticket's title. Further discussion about the workflow should be directed to the right ticket.

[Humberto Diógenes <humberto@…>]

I've uploaded a new image and replaced the old one in TracTickets, so I'd like someone to review it and close the ticket. http://projects.edgewall.com/trac/attachment/wiki/TracTickets/Trac%20Ticket%20State%20Chart%2020060603DF.png?format=raw

[cboos]

The proposed diagram is more correct, I'm not sure it's less confusing though, because of the "assigned -> (reassign) -> new" transition, which seems at first counter-intuitive. But that's not the diagram's fault.

This is because "assigned" state would have been better named "accepted", as the transition "new -> (accept) -> assigned" suggests. Also the "assigned" and "reopened" states are different ones, and the transition "new -> (reassign) -> new" is still missing.

See also the related discussion about accept/assigned/accepted on #2045.

In milestone:0.11, with the WorkFlow merge, we will probably pick a better/clearer default scheme (at least rename "assigned" to "accepted").

But the particular (reassign -> new) issue that this ticket wanted to address is fixed, yes.