> 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.
I'm not looking into "ticket type magic detection and adopting the user interface". And in general I'm also not looking into the ability to change from a testresult into a bug. This can be done by referencing and workflow, e.g. "If a bug is encountered during a test, file a new ticket and close the test with the reference to the ticket". I'm looking into clearly seperated ticket domains. The core API should allow to support different ticket domains, with different UIs that are distinguished e.g. in the URL handler, like you do with /wiki, /ticket, /timeline and so on. Why not have a subspace /testing that is a ITicketProvider but will have a completely different set of custom ticket fields than /ticket. They have nothing in common, but share the same infrastructure, to create manage and update tickets. Or for example /requirements, /tasks.... If one needs to change the type, than this must be done by opening another ticket in another ticket domain and these tickets needs to be crossreferenced. It is the task of the workflwo to allow which types can be created from which state in the workflow: e.g. Consider testing: You have a testing ticket domain, that will file a bug in the issue ticket domain if a bug is encountered during the test. The Test case is closed, but the issue lives longer until it is closed to. From the test result you can see, that issues where created and that they are cross referenced. One could also think of using the same ticket number in order to show relationsships, e.g. #117 is the testcase that created #117.1 as an issue ticket. Following the discussions about tickets you always get the request to add specific files to the base Ticket API, since people want to bend the current ticket type away from "software related issue" management into different fields, like project management, test case tracking, requirements management and so on. But one important thing for me is that these are different problem domains and that these should be handled as different ticket domains. Trac should provide the foundation for this. I already mentioned in an earlier message, that I need to have multiple close states of tickets in order to track which bugs are closed in which software version. Currently it is very painful to track that the same bug is closed in two different maintenance lines. For me a bug is open, as long as it is not closed or verified to be not exitant in every branch of the software starting from the point, the bug was encountered. So the close state / resolution is only related to the ticket. In my opininon the core should allow to manage such relationsships and build a clever database model in order to reference every possible (or any configurational) item in trac, and it is the ticket(or issue or whatever) module that build upon it to provide the functionality for the user. In my case I would abandon the ticket module that comes with trac and would start to write my own in order to support multiple close states. I would use the core API to generate and mange the dependencies, but my ticket module would be completely different to yours. the core of Trac should abstract away all database modeling, everything related to management of the database, like remove, rename, corss referencing should be build into the trac core and should present a Datamodel to the modules in order to build different ticketing domains upon it. Again, I'm not a python / web developer and there might be technical problems, that I completely overlook here, e.g. the inability of HTML to transmit specific requests. So this is only my opinion and knowledge from other system build with C++. Best regards Dirk --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
