On Monday 07 May 2007, Christian Boos wrote: > 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.
The workflow/DeleteTicket plugin is definitely an abuse of the workflow system. However, having a delete operation available in workflow may prove useful; something like the workflow/CodeReview plugin in combination with a delete_ticket operation could be helpful for fighting spam in a semi-distributed fashion. For workflows that include automation of some tasks, side-effects (such as builds, code analysis, etc.) are necessary. An ideal workflow system fades into the background; you should be able to instruct the system to take developer-centric actions, and have the workflow states transition more as a by-product than as the direct action taken. Achieving that will need the side-effect capability. > 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) I'm trying to avoid feature creep so that workflow gets merged to trunk instead of dying again. But yes, I do want workflow tooltips. > - 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 It should only show the actions that the user can do. Can you provide an example where that is not the case? > - 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 > | ... Keep in mind that the list of state transitions may become rather lengthy and include cycles. It may be useful, but it would have to be optional. > Instead of things like "needinfo_new" and "infoprovided_new", the title > of the state should be provided (once we have them). Yeah, this was discussed on #trac. I will look into this; my main concern is that we don't want two different states to look like a single state... it will cause deeper confusion than the "ugly" state names. > Of course, all those are refinements that will be better done on trunk, now. Thanks, 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 -~----------~----~----~----~------~----~------~--~---
