worklog 'autoreassignaccept' option leaves ticket status in 'assigned' instead of 'accepted'

[willw@…]

The 'Automatically reassign and accept (if necessary) when starting work?' option reads like it ought to leave the ticket in the accepted state, but this doesn't match the current behavior.

Even if the ticket is currently assigned and accepted, after starting work on a ticket, the status will be modified back to assigned.

[willw@…]

fix to autoreassignaccept to actually accept after assigning

[Colin Guthrie]

Correct me if I'm wrong, but I think the existence of the accepted status is actually dependant on the workflow model you have defined. In a default 0.11 install, accepted exists but in an upgrade from 0.10 it does not.

My choice of words is not ideal in the description of the ticket and the fact that the workflow is customisable now means this doesn't really work so well any more.

In actual fact, I'm in the process of changing how work log works to allow independant tracking of time spent in different states of the workflow. So you in order to track time, you would create a state called "working" or similar and track the time spent in that state (with the rounding up etc. as before).

People have asked me for different tracking for "Development" and "QA" and doing it this way will allow this.

My main problem just now is waiting for feedback from Trac folks on how to best store the kind of data I have and more fundamentally how to extend the ticket model to do so.... I need to get that more fundamental stuff sorted before I move on.

So in short, thanks for the patch, it's much appreciated, but I don't think I can safely apply it to all installs just yet. I guess if it intellegently worked out if accepted was an available state and used it if found, then checked for assigned and used it if found and then just gave up would work for everyone in the interim... I'll have a look and see if I can do that (but feel free to update the patch if you like!!)

[Colin Guthrie]

s/description of the ticket/description of the option/

[Colin Guthrie]

While this isn't fixed, this really needs to be addressed a little more holistically with the workflow! I'll therefore claim that this is a duplicate of #2107.