My intention was not to obviate the need for ticket types, with custom fields, workflow, etc. attached to a type (I was not intending to do ticket types). I think there is a clear need for them, with one default type where trac would perform identically as now, but for more types it would become necessary to use JS or have a two-part ticket creation step, and then there is the difficulty if ticket types are allowed to change (a simple answer would be "no"). I haven't look at the source enough yet to see how difficult it would to be a type an extension point though.
jeff P.S. There's also no reason you couldn't use TicketSubmitPolicy to hide, require, etc. fields within a particular type is there was a need for that as well. On Tue, June 3, 2008 19:35, [EMAIL PROTECTED] wrote: > > Hello Jeff, > >> Coincidentally in time, I have been working on a plugin that enforces a >> ticket submission policy based upon field values (ticket type being one >> of the obvious choices): >> http://trac-hacks.org/wiki/TicketSubmitPolicyPlugin . >> > This sounds interesting. I can really see a use for this, esp. in > different states of the workflow, where specific fields are not neccessary. > Additionally this is good to distinguish different types (in > the same ticket domain) also. For example a bug could be treated > differently than a feature request. But I wouldn't extend this into > different ticket domains. As Erik pointed out in his post, consider to > completely unrelated domains, like People and software issues. It is of no > sense to hide away all unsued fields. Additionally in the changelog of the > ticket you will see everytime, that some unused fields where changed [1], > simply because they where added to the ticket system. > > Your approach is very good. It will extend trac to provide some magic in > order to ease things for users having problems that specific fields are > visible, even if the current workflow state does not require them. Polish > the UI to make it simple for the user in his current position. > > My post was more to understand, why trac is not providing the core > routines to create ticket domains but requires plugins to restrict the one > existing ticket system. > > Again, again and again, no offend to the core developers. They did a > hard work, and their software is now out in the public facing lot's of > people telling them what they should do better. > > Best regards > Dirk > > > > [1] If the tickets hsitory will only contain changes in the fields, and > one wants to understand the evolution of the ticket, I found myself already > dsitracted by the display of unused new fields. > > > > > > !DSPAM:4014,4845d5c5310553362379201! > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
