Accepted ticket is set to Assigned status when starting work

[Ryan J Ollos]

When starting work on a ticket with status Accepted, the ticket status is set to Assigned and the following message is displayed:

[Colin Guthrie]

Yeah, this used to work in 0.10 days when the workflow was fixed, but now it's quite configurable so it doesn't really hold true any more.

It still works for me (as I still use the old workflow).

If you can think of better ways to deal with this I'd be interested. This behaviour can be prevented via the setting: "Automatically reassign and accept (if necessary) when starting work?" but turning it off would loose some useful functionality (and I appreciate the irony in the wording of that option considering it's very much not "accepting" the ticket!)

[Ryan J Ollos]

Thanks for your comments on the issue.

I haven't studied the source code yet, but it seems like we could initially modify this for the 0.11 and 0.12 branches only, implementing transitions for the default workflow, such as Assigned -> Accepted, New -> Accepted, ... as it appears the current workflow transition is * -> Assigned, when the associated option is set to true.

To your point of supporting custom workflows, that seems much more challenging, and plugins can be found all over t-h.o that have tickets filed for defects when used with custom workflows. I'll keep that in mind though and hopefully we can come up with a better solution down the road.

I should be able to provide a patch for this within the next few weeks.

[Colin Guthrie]

I guess one fairly simple approach to deal with 95% of use cases is to just give a drop down in the config page for the state you want to make the ticket when you are working on it. We could then do one of two things:

1. Jump straight to that state, even if it's an invalid state transition from the current state (aka the "sod it, it'll do" approach).
2. Work out the simplest series of state transitions to get from the current state to the desired state (aka the "do it properly" approach).

I do try to take the "do it properly" approach just now, but it's hard coded and thus quite simple. I don't think any really bad things would happen with the "sod it" approach tho', so perhaps it's fine (especially for the initial fixup)?

[Ryan J Ollos]

(In [9893]) For the default workflow (1) in Trac >= 0.11, the status should be set to accepted (not assigned) when starting work on a ticket. Refs #8406.

(1) ​http://trac.edgewall.org/wiki/TracWorkflow#Environmentscreatedwith0.11

[Ryan J Ollos]

(In [9894]) Merged [9893] into 0.12 branch. Fixes #8406.

[Ryan J Ollos]

Replying to coling:

This behaviour can be prevented via the setting: "Automatically reassign and accept (if necessary) when starting work?" but turning it off would loose some useful functionality (and I appreciate the irony in the wording of that option considering it's very much not "accepting" the ticket!)

Since I've been testing this out tonight, I just wanted to add my findings here. I've found that the option you describe above, when false, prevents starting work on a ticket when you are not the ticket owner. However, if you are the ticket owner, the status is still changed to assigned when starting work on a ticket (prior to [9893]).

[Ryan J Ollos]

Replying to coling:

I do try to take the "do it properly" approach just now, but it's hard coded and thus quite simple. I don't think any really bad things would happen with the "sod it" approach tho', so perhaps it's fine (especially for the initial fixup)?

Following [9893] and [9894] we have compatibility with the default workflow in Trac 0.11 and 0.12. So, basically I think this plugin now works just as well with Trac 0.11 and 0.12 as it does with 0.10, in terms of default workflow compatibility.

Handling arbitrary custom workflows seems like a nice feature, but I have no motivation (and thus time) to do this until I implement a custom workflow. I might be doing that down the road, in order to add review and testing steps to my workflow. If I get to that point, I'll open another ticket and work on the more challenging task of handling custom workflow. I think you had some good ideas in comment:3.

The patch in [9893] was fairly simple, but please let me know if you have any comments. Thanks!

[Colin Guthrie]

Replying to rjollos:

Since I've been testing this out tonight, I just wanted to add my findings here. I've found that the option you describe above, when false, prevents starting work on a ticket when you are not the ticket owner. However, if you are the ticket owner, the status is still changed to assigned when starting work on a ticket (prior to [9893]).

Clearly an awesome implementation from me then! I think I deliberately didn't allow the work to start if you were not the owner, but the change of state is probably bogus...

I think this will do fine for now :)