On Sunday 31 October 2010 11:19:40 pm Brian Meeker wrote: > I am starting to dig into how workflows are implemented with the goal > of implementing #7709 from Trac-Hacks[1]. The end result should be > that actions not defined by the workflow will be disallowed and any > operations the action defines should be applied. I am looking at the > ITicketActionController interface and its implementation in > ConfigurableTicketWorkflow. Is there a straightforward way to ask, > given a ticket and a status, if it is valid for the ticket to be > transitioned to that status? I haven't been able to find this type of > validation being done anywhere else (and didn't really expect to).
Not directly. You could ask for each ticket, for each action available on that ticket, what the resulting status will be. Then see if there is at least one way to transition to that status. But you can't ask 'can this ticket transition to that status' directly. Also note the 'at least one way'... different actions may legitimately transition to the same status, but do different things. > Right now I have a (buggy) hack that uses the internals of > ConfigurableTicketWorkflow, but that could easily break for other > implementations of ITicketActionController. It keeps track of which > tickets have an invalid transition. If any are invalid the entire > transaction is rolled back and an error is raised describing which > tickets are invalid. > > [1]: http://trac-hacks.org/ticket/7709 Something to keep in mind is that the Trac workflow is built around _actions_, not _states_. I suspect people expect it to be state-based, and it kind of looks like it is, and so people get a bit confused. But the workflow design is intended to allow you to take actions on a ticket based on what the current state is. That action often changes the state as part of what it does, but it is not required to. The way I use Trac and Svn, I create a branch in subversion for each ticket that I work on.[1] The ticket has a 'branch' action, and once branched, it will have a 'merge' action to merge it into what it was branched from.[2] Other possible actions for tickets when using a branch-per-ticket, would be to have a 'build' or 'run tests' action. Actions like that may not change the state of the ticket. Or may trigger some automated process that will come back at some later time and take another action on the ticket. The ticket workflow code is far from perfect, and really needs a thorough re- work, but I haven't had a chance to spend time on Trac since PyCon. :( I tried to make it very extensible (the operations stuff), and allow people to nearly completely replace the way the workflow is implemented using a plugin. I don't think I succeeded in that as well as I would have liked. If you look at the bugs filed against the AdvancedTicketWorkflowPlugin on trac-hacks, you will also find that we need to have a way of describing changes to arbitrary ticket fields, and the data used for ticket previews needs to be reworked so we track both changes a user made directly as well as the changes made by a workflow action so we can handle "preview, change action, preview" correctly. HTH, Eli [1] This is using my "mergebot" plugin for Trac, which you can find on retracile.net. My coworkers _love_ this thing. It may seem odd, but it works well and makes our lives much easier. [2] The ticket action version of mergebot is not currently in production use; a prior method is, so the described functionality may currently be broken. It has been a while since I could make time for mergebot work. :( The _next_ round of layoffs may change that... :/ -----------------------. "If it ain't broke now, [email protected] \ it will be soon." -- crypto-gram http://retracile.net `-------------------------------------------- -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
