On Mon, Jun 2, 2008 at 7:21 PM, <[EMAIL PROTECTED]> wrote: > > 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.
Well, I'm someone you should talk to if you're interested in something like this, as it's something I've been given a lot of time to work on for my company. I've been maintaining essentially a fork of the Trac ticket system that's partially based on the old Workflow sandbox, but updated to work with the current workflow implementation. It includes a UI for designing different "ticket types" from scratch. There's also an API for adding custom field types, and for adding custom "Enums" similar to Version and Component. Much of it is built to specific internal requirements, but a lot of it I suspect would also be beneficial to others. Unfortunately I can't share any of the code yet--it's hard enough in my company to even get open source software in use, and people don't understand that one of the main strengths of open source is allowing the community to make improvements. But at any rate, we've solved, or at least partially solved some of the issues involved with this, though it's still far from perfect. Point being, I might be able to add some insight. Much of what you described is how it's been implemented, though there's not much yet as far as separate "ticket domains" as you mentioned downthread. This is the next step. Many of the remaining problems have to do with tickets that are just far too dissimilar. For example, we still use the query module the same way for all tickets, and it still has the same columns selected (component, version, and others that are mostly related to defect tickets). But we have a project that's using tickets to track People, and that has completely different fields. And at that point it doesn't even make sense to call it a "ticket", because it's more like a custom DB table. It's starting to be more like ClearQuest, but is sort of halfway between, and at this point feels sloppy. As for the problem of selecting a ticket type in the new ticket UI, we just use JavaScript to swap the forms. This is, as Noah said, far from ideal. But since it's currently only used internally, we sort of have control over the situation, and can get away with requiring JavaScript, as much as I don't like to. But the long term goal is to have a custom "Record" system, of which BTS tickets would just be an optional instance. The "People" example would be a separate "record domain" with its own pages for creating and viewing records. Though there would certainly be ways to reference between domains. We already have something sort of like that in use. It's possible to designate a specific field in a ticket type as its "key" (currently only one field). This is a separate key from the ticket id which is still used the same way as in normal Trac. Rather, it can be something such as the employee ID in the "Person" ticket. Then in a different ticket type it's possible to designate a sort of "foreign key" field that knows that its value is an employee ID, and links back to the "Person" ticket that belongs to the employee with that ID, if it exists. This system hasn't been made generic, and is implemented through a plugin I wrote specifically for that environment. But making it generic is another major part of my long term goals. Erik --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
