> -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] > Sent: Monday, June 02, 2008 4:21 PM > To: [email protected] > Subject: [Trac] ticket types and custom fields > > > 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
Huge fundamental problem: At the time the ticket UI is loaded, we have no idea what type the ticket is. Either you need to put a screen before the main ticket UI where you select a type, or you do the whole thing client-side with JavaScript. Trac maintains a policy of not requiring JavaScript for actual functionality (just makes existing functions faster), so #2 is right out. This leaves #1, which would be annoying as all get out. If you have another option please share it though. --Noah --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
