During reading your discussion idea born in my head. It will be very cool to draw history of state changes as graph or state diagram.
2007/5/7, Christian Boos <[EMAIL PROTECTED]>: > > > Jonas Borgström wrote: > > Eli Carter wrote: > > > >> On Monday 30 April 2007, Alec Thomas wrote: > >> > >>> Err, in case this wasn't clear, I'm suggesting we delay the merge > >>> until more people have reviewed it. > >>> > >>> On 5/1/07, Alec Thomas <[EMAIL PROTECTED]> wrote: > >>> > >>>> On 5/1/07, Christian Boos <[EMAIL PROTECTED]> wrote: > >>>> > >>>>> Eli has put the WorkFlow branch in a good shape, and it has been > quite > >>>>> usable for a while now. I've taken a look, tested it and all seems > well > >>>>> for me for shifting the work on trunk where it could gain some wider > >>>>> exposure. So I'd like to call a vote for the merge. > >>>>> > >>>>> The ideal situation would be to get a few +1 besides mine and Eli's, > >>>>> till tomorrow afternoon, as it's the 1st of May and I'll have some > time > >>>>> to work on the merge together with Eli. But otherwise, it's not a > big > >>>>> deal, as I've got plenty of other areas to hack on ;-) > >>>>> > >>>> This is not picking on Eli at all, but can we get more review before > >>>> doing major merges? I'd personally like to see at least one of > cmlenz, > >>>> jborg or mgood comment on major merges *before* they go in. The more > >>>> people that look at the code the better it will be. Different minds > >>>> pick up different issues. > >>>> > >> Agreed. Review is definitely welcome. The problem is it seems to > require a > >> threat of merging before it happens. :( > >> > >> > > > > I've been looking at the code now and this branch seems to be in pretty > > good shape. I've just found some minor code formatting issues but > > nothing that can't be addressed in trunk later. > > > > So +1 from me. > > > > One thing I'm not sure anymore about is the > apply_ticket_side_effects(req, ticket, action) part. > I'd prefer to have the "actions" focused on the workflow part, and the > operations limited to field changes. > For example, there's #4686 (Ticket duplication using Trac): I don't see > this being done using an "action" for example, but rather triggered by a > "Clone" button somewhere in the yellow box. Likewise for ticket delete, > I prefer the way it is done with the current TicketDelete plugin. This > is not to say that we shouldn't eventually come up with an interface and > common UI for these kind of things, but rather that the workflow > interface and UI shouldn't be "abused" (TM) for this. > > In a related way, I feel that we should be able to do better on the > self-explaining quality of the workflow transitions. > - Tooltips explaining what an action will do (I think everybody already > agrees on this one, eli wants to postpone this to after trunk integration) > - show only the actions that can actually be performed by the user; > currently all are shown and selecting one which is not permitted results > in an error > - show where we stand in the workflow; ideally, that would be a summary > of the transitions already taken, and what's possible to do next: > > > ,-- Workflow: ----------------------------------- > | > | new -> needinfo_new -> infoprovided_new -> assigned -> accepted -> > *started* > | > | action: > | (o) leave as started > | ( ) close as ... -> closed > | ( ) reassign _____ -> assigned > | ( ) info needed -> needinfo > | ... > > Instead of things like "needinfo_new" and "infoprovided_new", the title > of the state should be provided (once we have them). > > Of course, all those are refinements that will be better done on trunk, > now. > > -- Christian > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
