Hello, considering all the plugins that try to hide, extend, modify or play with the custom properties of a ticket, and also reading through the resent discussion about the trac core I have a simple question to understand a design decision. If I remember correctly trac started with only one ticket type. later this was extended to distinguish between all different types with all the helper plugins showing up to manage the custom fields. While ticket types are a good idea, I find it rather interesting, that I have to hide fields in order to get other, completely unrelated types. Why don't you expose a real basic API to construct different tickets types where every type will have to add fileds in order to be useful. The Ticketing system itself would be one of the users of this API, adding the current set of fields. If this is a performance issue [1], why not having different tables for every different configured ticket type. You could reuse the current ticket page UI as a generic UI for every ticket type, but different plugins could override these with a different custom UI. The only problem with this approach is, that you can not change from one type to another. The ticketing system may still have a custom field "type" to distinguish between a bug and an enhancement. But other types, like requirements, tasks, tests, inventory and so on are generally not changed from on type into another. In these rare cases, one could still simply refer/reference to a new ticket of different type. I can't see a reason, why I should change unrelated types, esp. since we have the workflow.
The ticket numbering is the same as the subversion revision. It is a number nothing else and it should be unique between all ticket types simply for the ease of use. From what I can see, and also use in my setup, trac is exetended in many ways to include completely different types in one setup, and the common sence for all types in my setup is, that the have a number, a subject a description, the time/author fields and history of changes. Nothing else. Every other field, like resolution, severity, version milestone and so on is specific to one of multiple types. I'm not a real python / trac developer. I'm simply trying to fit trac into our process and I often come across this question. If you think about core features of trac, make the ability to manage types and tickets, crossreferencing between tickets (e.g duplicates, and references), workflows and permissions the core feature. The ticketing itself is already a module build upon the core. There are a lot of discussions about new fields. In this minimalistic approach, trac does not enforce a set of fields, even not the so called standard fields. It will mange as many fileds the user will configure. Sorry if this is already common sence between the developers. I did not follow every discussion on the list due to lack of time, but I was thinking about a new ticket type today, and hit that "hide" fields issue again. Best regards Dirk [1] I can remember a previous discussion, about the database design for custom ticket fields and performance issues. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
