On Thu, Jun 26, 2008 at 11:54:02AM +0300, Jani Tiainen wrote: > > Christian Boos kirjoitti: > > Lucas Eisenzimmer wrote: > >> I was just wondering whether you have a rough date in mind when Trac 0.12 > >> might be stable. We are using Trac for requirements engineering and we > >> would > >> need 'real' ticket type depending workflows. Theoretically, the triage > >> function of the AdvancedTicketWorkflowPlugin would do it, but for several > >> ticket types with own, separated workflows it starts to get confusing and > >> buggy very fast. > >> > > > > Granted, I also think that separated workflows for each ticket type are > > clearer when you need them, which leaves open the problem of how to > > transition from one such workflow to another when the type changes. > > For example Redmine (that get's referred lot nowadays) has very > "complex" workflow engine. You can have per issue type, per role > configurations. But Redmine _doesn't_ allow change of issue type. But > instead there is copy option where you have possibility to change type. > > This leads to very philosophical question: > > Is ticket, once issued, on the system locked to type it has? Currently > Trac is very liberate in this sense and allows change of issue type > which fits well to "staying away" philosophy. > > Restrictions like different workflows pushes Trac usage to more "getting > in a way" philosophy. > > I see following solutions to this: > * Don't allow type change > > * Require default state for each ticket type and set that in > case of change > > * Add change-on-copy functionality (similiar to Redmine) > > * Complex rules translating between states. > > Translation is not even trivial. If you think of following: > > If we have enhancement states like: > > 'new', 'accepted', 'rejected' and 'implemented' > > And bug states like: > 'new', 'accepted', 'invalid', 'testing', 'fixed' > > There is not much common... So it would lead to one more factor: You > need to be able to restrict type to change depending on current state. > > This would be ultimate solution but might require more than just a plugin... > > >> In http://trac.edgewall.org/ticket/6548 I read that this functionality has > >> been assigned to milestone 0.12. Is this up to date and do you think you > >> could make a rough point about a release date for Trac 0.12? > >> > > > > No, it's not up to date. Like for many other tickets, a rescheduling > > will be done in the coming days. > > > > Besides, take http://trac.edgewall.org/ticket/6548#comment:3 to be an > > idea for implementing an alternative to the ConfigurableTicketWorkflow > > component (i.e. the main default ITicketActionController), which can be > > done as a plugin. > > So I've cleared the milestone for this ticket ("no milestone" means for > > us "unseen so far", "2.0" means "eventually later"). > > But if this can be done in a plugin, it should be done as one and later > on migrate to Trac. > > -- > Jani Tiainen
Just to throw in my late $0.02, if ticket types with different workflows, fields, etc are allowed, I would prefer the option of allowing complex transitions from one workflow to another (a workflow workflow, if you will). This could be kept simple from a user perspective when ticket type changes: 1. if nothing else, put it in the new state 2. allow (but don't required) transitions based on state names. that is, if 'assigned' is in both the from and to workflow then put the ticket in this state in the same named state upon type transitions 3. allow rules mapping from states to to states on ticket type changes I think 1 + 2 could be setup as a default and handle maybe 80% of real world cases, the annoyance being for the other 20% the ticket would have to be manually put in the right state after transitions. That's where 3 comes in to fill in that gap. Of course, 3. could be used verbosely to do whatever was wanted if more complex transitions were desired. I realize this isn't completely trivial, but neither are other aspects of adding ticket types, and IMHO this is the right way to do it. Ticket types will change, so that can't be ignored. Going from "assigned" to "new" when there is a parallel "assigned" in the to state is annoying if avoidable. jeff --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
