On Oct 23, 9:30 pm, Felix Collins <[EMAIL PROTECTED]> wrote: > > There is a plugin for custom tickets, i believe it's called > > TracTicketsCustomFields. You can define custom tickets fields. Also the > > Hours > > plugin could help if you want time estimates. > > I made a patch to create numerical fields including a cumulative field > and a set once (new ticket) field. The approach was to use javascript > to do client side validation and modify the templates to display the > custom fields as required. > See:http://trac.edgewall.org/attachment/wiki/TimeTracking/CustomFieldsRev... > > This patch is for the old clearsilver templates. Let me know if you > need the Genshi version.
you don't need a plugin for custom ticket field, you can add them directly in the .ini file. The customFields plugin is nice to admin those fields directly in the admin interface though. For some reason it's buggy for me, I think because I inhereit some of my fields, then overried/renumber some per project you can also use a text field for numerics, but if you're asking about forcing/validating numeric, then you can use a plugin such as TicketValidator plugin, or something else. There are also some approaches to 1 repo/multi-projects out there. Depends on your use, but it's by no means a "show stopper" or non- acheivable, it does seem to depend on your approach however. particularly to how your subversion repo is set up. I don't use the 1 repo mult-project approach, so I don't see the desire. If anything we use multiple repos's with externals for shared/common code branches. It is however, probably a little more work and you might get less groups support as it's a less common model. The TimingandEsitmation pluign, or the TracHours plugin are of interest. MasterTickets might fit in here. as for you custom workflow with "QA" step and permissions, the "enterprise-workflow" in the contrib directory on Trac source has a plugin that implements the "QA" permission required to move a ticket from "QA" to closed, and adds an enterprise workflow ta boot. (resloved->InQA->closed if permissions permit). while you can certainly roll your own permissions as mentioned here, you could also use this as a starting point. multi-project searches can be done with a plugin there is a plugin for multi-project queries as well. going back to your "multi-repo" scenario, if your model is truly a single repo, there is nothing to prevent you from pointing multiple project at the same repo, just that if you use a post-commit script, you need to make it smarter. There are more complicated models though, and I can't attest to any of them, as we use a 1 repo per project model. yes, you need to create a different trac instance for each project. but you can do multi-project searches and queries via pluigns, and create references between them with inter-trac links. per your "first disappointment", but I think that is just a matter of not having all the options out there. you can use the default "parent dir" type model, or create a custom base page that links to all your project tracks, in a frame for example. but you will have multiple ticket #1's, your tickets won't increment across projects, which is a traceability nightmare anyway, so for my particular job would be considered voodoo :D if they are small enough, you may consider using "components" to differentiate "projects" not sure of the context here though. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
