Andy Baker wrote: > It's an area I've been dancing around for a while and not coming up > with a solution that fits well with what we're trying to do. > > At first glance http://trac-hacks.org/wiki/ChildTicketsPlugin seems > to offer closer to what we actually want, but the comments and > caveats from the author pushed us towards the more active if less > functionally rich http://trac-hacks.org/wiki/SubticketsPlugin.
I don't see that it's more active. The commit at http://github.com/itota/trac-subtickets-plugin is 5 months old. Still, I got it installed and it seems to work OK for what it does. > Similarly to Greg, there's an item on the dusty end of my to do list > where I have a dream of cherry picking elements of all three > (ChildTickets, SubTickets and MasterTickets) to create a customised > plugin that works for our implementation. At this point, I'm kind of leaning toward using MasterTickets for dependencies (obviously only FS without some changes but that's OK for now) and another plugin for parent/child relationships. > So in answer to your original question my thinking would be to > fork/patch SubTickets and build out what you specifically require. I'll have to see what I need that it doesn't have. Clearly ChildTicketsPlugin has much finer-grained support of what tickets can have children, what's inherited, what's shown in the child tickets table, etc. I sort of like the Subtickets display of greandchildren though. If one had a ticket change listener that would let me set a parent field in ticket_custom and have it update the relationships (e.g., parent,child in Subticket's subtickets field) that'd influence my decision. I guess I need to do some more research. -- 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.
