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.
Yes, seems nice. > 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. > Let's take the example of bugs vs. enhancements. I'd say among tickets, 40% are clearly bugs, 40% are clearly enhancements requests and 20% could be seen as either one or the other, depending on the point of view. So I think it really makes sense to be able to requalify a ticket from bug to enhancement and vice versa, if the point of view changes (e.g. it could be up to the "owner" to have the final say on this). > Restrictions like different workflows pushes Trac usage to more "getting > in a way" philosophy. > For most workflows, I think it makes sense to treat an enhancement or a bug the same, even for the "enterprise workflow" we ship as an example. But a mere "task" probably doesn't need to go through Q&A, for example. Some teams may want to have relaxed or different rules for some types of tickets, it's all about the flexibility to add /adapted/ constraints. I would rephrase what you said in the above by saying "the ticket workflow allows you to adapt Trac to *your* way of doing things". If the workflow is not adapted, it will get in your way, even if it's a simple one. If having different workflows for different ticket types is really what's adapted for you, then by definition it doesn't go in the way. > I see following solutions to this: > * Don't allow type change > No, for the reasons exposed above. > * Require default state for each ticket type and set that in > case of change > Might work (reset to "new"). > * Add change-on-copy functionality (similiar to Redmine) > Unnecessarily complex for now. If one day different ticket types will map to different kind of ticket resources (sub-classes, with different fields as well), then this should be reconsidered. Even then, I'd favor being able to do a smoother conversion if possible. > * Complex rules translating between states. > The most flexible solution. > 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. > Well, according to the idea exposed in the ticket, you could have something like: [ticket-type-workflow] # old type . old state => new type . new state enhancement.rejected = defect.invalid enhancement.implemented = defect.testing enhancement.* = defect.* defect.invalid -> enhancement.rejected defect.testing -> enhancement.implemented defect.fixed -> enhancement.implemented defect.* = enhancement.* > 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. > > Eventually :-) -- 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 -~----------~----~----~----~------~----~------~--~---
