Accepting a ticket in enterprise workflow leaves no valid action to leave state

[spencer.wasden@…]

I started using enterprise-workflow.ini (6324). After I accept a new ticket, my Action section only has these two options:

• leave as accepted
• accept (Next status will be 'accepted')

Selecting either one (then submitting changes) results in those same two available options. From what I can see there's no way to get out of this state.

Modifying these two unrelated lines in the workflow…

 assign = new -> assigned
 test = new,assigned,in_work -> in_QA

…by changing them to:

 assign = new,accepted -> assigned
 test = new,assigned,in_work,accepted -> in_QA 

Allows you to accept a ticket without getting stuck. So the final workflow is:

[ticket-workflow]
; enterprise-workflow.ini

; assign, reassign, unassign actions
assign = new,accepted -> assigned
assign.operations = set_owner
assign.permissions = TICKET_MODIFY

reassign = assigned,in_work -> assigned
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY

reassign_closed = closed -> closed
reassign_closed.name = reassign
reassign_closed.operations = set_owner
reassign_closed.permissions = TICKET_MODIFY

unassign = assigned,in_work -> new
unassign.operations = del_owner
unassign.permissions = TICKET_MODIFY

; leave actions
leave = * -> *
leave.operations = leave_status
leave.default = 1

; test actions
test = new,assigned,in_work,accepted -> in_QA
test.permissions = TICKET_MODIFY

; resolve actions
resolve = in_QA -> closed
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY

fail = in_QA -> assigned
fail.permissions = TICKET_MODIFY

; start/stop actions
start = assigned -> in_work
start.operations = set_owner_to_self
start.permissions = TICKET_MODIFY

stop = in_work -> assigned
stop.permissions = TICKET_MODIFY

; reopen actions
reopen = closed -> new
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE

; request info actions
; For tickets with an owner, they go back to assigned
requestinfo = assigned,in_work,in_QA -> infoneeded
requestinfo.name = request info
requestinfo.permissions = TICKET_MODIFY

provideinfo = infoneeded -> assigned
provideinfo.name = provide info
provideinfo.permissions = TICKET_MODIFY
provideinfo.default = 2

; But tickets without an owner go back to new.
requestinfo_new = new -> infoneeded_new
requestinfo_new.name = request info
requestinfo_new.permissions = TICKET_MODIFY

provideinfo_new = infoneeded_new -> new
provideinfo_new.name = provide info
provideinfo_new.permissions = TICKET_MODIFY
provideinfo_new.default = 2

[Christian Boos]

Sounds simple enough… sorry for not having noticed the report earlier.

[anonymous]

No problem, but I don't know for sure if it's correct because I'm pretty new to Trac and workflows. There may be something I'm missing.

[Eli Carter]

The enterprise workflow does not have an 'accept' action to put the ticket into the 'accepted' state. So I think you have some leftover bits of the default workflow in your [ticket-workflow] section, though I don't see any in your posted config. Can you verify that?

[anonymous]

I don't know about any leftover bits. Performing a diff on this file:

​http://trac.edgewall.org/export/HEAD/trunk/contrib/workflow/enterprise-workflow.ini

…against the workflow I pasted in above shows 2 modified lines, and they happen to be the two I indicated above, namely:

assign = new,accepted → assigned test = new,assigned,in_work,accepted → in_QA

[anonymous]

(The workflow I pasted in above IS the entire contents of the workflow ini file)

[Eli Carter]

Replying to anonymous:

(The workflow I pasted in above IS the entire contents of the workflow ini file)

Then where is the 'accept' action coming from?

[anonymous]

Using enterprise-workflow.ini (revision 6324) on Trac version 0.11.6, what options do you see in your Action section after you accept a new ticket?

[Eli Carter]

If you are running enterprise-workflow, there is no 'accept' action, so your question of "what do you see in your Action section after you accept a new ticket" is invalid — you can't get to "after you accept a new ticket" in that workflow because you can't 'accept' a ticket in that workflow.

[anonymous]

What do you see when you accept a ticket in the default (original? basic? simple? not sure which it was before) workflow, then change to the enterprise workflow, then refresh that ticket?

[Eli Carter]

Ah! You changed the workflow after you already had tickets in the 'accepted' state. That isn't a bug in the enterprise workflow. You need to take all tickets in states that are not included in the enterprise workflow and move them to something in the enterprise workflow. For a quick way to do that, look at the 'contrib/workflow/migrate_original_to_basic.py' script for a bit of SQL to update all 'accepted' tickets to 'assigned'.

[anonymous]

Maybe not a bug, but I argue a deficiency in the enterprise workflow. I don't have the immediate ability to run a python script as this instance is being hosted by another party. I would have to submit a 2nd support request to make that happen. Making a couple changes in the workflow file was much nicer with our several Trac instances than having to also run a script on them all.

[Eli Carter]

No, it's not a deficiency in the enterprise workflow. Migrating from one workflow to another is going to have additional steps required, and those steps are going to vary based on both the original workflow and the new workflow. Your modifications to the workflow will let you fixup tickets on your systems, but for other users who configured the enterprise workflow from the start, or who do have access to run SQL, these changes are just cruft and add confusion.