Hello, > 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 > >
In another post I suggested to support ticket domains. Esp. in your case (and some of my cases also) the "requirements" and the "bug/enhancement/whatever" tickets have nothing in common, except probably the name "ticket". The don't share a common workflow, they don't have the same fields, in short they don't have anything in common on the user interface side, but they have the same implementation logic attached to it. If my opinion creating an enhancement from a requirement is also an additional step in the workflow and should be treated in exakt this way: create a new ticket in another domain (If you want you could think of subtickets to retain the numbering). Ticket domains will let users create any possible domain they need and you can attach any workflow to it. They are kept in different tables in the database and it should be easy to cross reference between different ticket domains. They also can have a different layout, The currently used type is simply a field for the "issue ticket domain". The current usage of this field is over stressed to support different unrelated ticket domains. And the net benefit is: all new ticket domains (e.g. requirements management, test amangement, and so on) can be implemented as a plugin ;-) Best regards Dirk --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
