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 -~----------~----~----~----~------~----~------~--~---
