On Monday 12 March 2007, Christian Boos wrote: > > Eli Carter wrote: > > Each transition can have a list of operations: > > owner_del - clears the owner > > owner_set - sets the owner to the selected user > > owner_set_to_self -sets the owner to the logged-in user > > resolution_del - clear the resolution > > resolution_set - set the resolution > > > > Interesting - "action" tokens that can be associated to a state > transition. Probably something similar could be done for permissions > (addendum: just realized you did).
I'm also planning on a .description so we can add a tooltip or something to explain the purpose of each action. > > The opensource workflow is based on the description that Christian gave on > > March 6th, but with some differences. > > - assigning to yourself != accepting. You have an accept action, use it. > > > > Well, this was essentially meant to be a shortcut for (new -> accepted), > but your statement implies that the accept action is present for the new > state, so that would work as well. It is. It's easier to see from the graph. Use contrib/workflow_parser.py & graphviz, or the showworkflow script. > > - reassigning a started ticket puts it in assigned state; it needs to be > > accepted or started by the new owner > > Well, the more I think about it, the more I think that for conveying the > idea that "I've started to work on the ticket", a progress field (#1084) > would be more appropriate. This would have the advantage to show at a > glance what issues are currently being worked on, see > http://bugs.flyspray.org/ for an example. Plus it's somewhat orthogonal > to the workflow. Work on a ticket "accumulate", whatever happens to the > ticket (especially if it's reassigned from one developer to the next). A > new ticket submitted with a patch could be said "in progress" as well. Hmmm.... good point... but I think there's something missing there. There is also the concept of "intent", that is, "I intend to work on this", and that is not addressed by a progress field. If the "started" state is instead "in_work", that indicates that effort is being made on that ticket. accepted state - Yes, I'll work on it at some point in_work state - I'm working on it now progress field - how much was done, how much is left > Also, when I made my initial proposal, I've already pondered about the > "needinfo" status, but thought that the workflow was already complex > enough. Getting rid of the "started" state would make room for the > "needinfo" state, as proposed by Manu and Alec (we could alternatively > use the "feedback" status name, as Mantis does). > > Even better, the progress bar could be grayed out or shown in red if the > ticket is stalled because in "needinfo" state... I like the idea... but I'm not going to implement that yet; it'll come after the customizable states. > > The enterprise workflow adds a QA step for validating things are correct. And > > it drops the "accepted" state. > > > > Why? I think it's important to get the "ack" from the assignee > ("acknowledged" could be an alternative name for the "accepted" state, > again in reference to Mantis). Well, because my boss didn't see the point in it. ;) > > ... > > > > Second, I don't like the way it looks in the .ini; it's very verbose. > > Reasonable defaults would probably help a lot here, but it still feels > > awkward. I do like having all of it in one section instead of two, though. > > > > You're talking of the proposed ...-workflow.ini files? Yeah, even the > trivial-workflow.ini is scary :-), we should come up with something simpler. I don't think it can be simpler without being too simple... but there's got to be a way to make it more readable. Hmm... an example from opensource-workflow.ini: ; resolve actions resolve.newstate = closed resolve.oldstates = new,assigned,accepted,started resolve.operations = resolution_set resolve.permissions = TICKET_MODIFY We could combine the state transitions to one line like this: resolve.statechange = new,assigned,accepted,started -> closed but that invents new syntax for the .ini, and only saves 1 line.... so I don't think it's worth it. It may be that we need to focus on a UI for creating/modifying workflows and leave the .ini config as verbose. Eli --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
