On Jun 26, 7:18 am, Jani Tiainen <[EMAIL PROTECTED]> wrote: > Eleonore DUVELLE kirjoitti: > > > > > Eleonore DUVELLE kirjoitti: > >> Hi, > >>> I was wondering if this ticket (#886) had been continued.. Does > > anyone > >>> knows about a way to hierarchise tickets in trac? I've seen a page on > >>> Trac about this (http://trac.edgewall.org/wiki/SubTickets) but there > >>> doesn't seem to have any concrete plugin. > >> Master Tickets plugin is closest one > >>http://trac-hacks.org/wiki/MasterTicketsPlugin > > >> But there is nothing that provides strict hierarchy. > > >> -- > >> Jani Tiainen > > Thank you, > > > Yes, I've seen this plugin. But as you say, that's not what I want... So > > isn't anyone there working on this hierarchy between tickets? > > I doubt. Not even Trac favourite competitor Redmine doesn't have ticket > relations - it just provides what master ticket does - you can link > tickets but there is nothing more special about them. (Even one of those > related tickets stated that Redmine does support hierachical tickets) > > Changes to ticketsystem itself (even ui) could be done by using new > streaming capabilities so that's not a problem, but how to handle > roadmap and milestones. > > Also how to detect when ticket is closed or when all tickets are closed? > Resolution list is actually just user configurable list that has not > status indicator. > > Specially this kind of things comes very important in 0.12 which is > planned to support l10n... > > -- > Jani Tiainen
I have looked at this kind of "need" myself, and here is the issue I see with it, what I need is similar, but different from what is asked in that thread as well. In reality, I believe what I am after is a creative use of the MasterTickets Plugin, the BlackMagic plugin, and a workflow action handler. What I decided in my case, was to use the TracForms plugin, since in reality, I have no NEED to force additional "slave" actions, but remind the developers to at least consider if the ticket requires: Req. doc update, or design doc update, code review, validation run, user manual revisions....etc. initially, I was going to perform the following: - once a ticket was "assigned" in my workflow, and if the owner was viewing the ticket, show a bunch of fields normally hidden that were all check boxes: update this? update that? retest? etc.. - on the Accept action of my workflow, this would then generate a blocking ticket for each item checked with a canned summary of "do whatever - <summary of current ticket: #>" ie. "update unit test - Fix the BSOD bug ticket #10" - pre-fill the description with generic actions related to that task type then hide all those fields again. Then the dependency graph become very useful. However, we realized, we really want to utilze the master/slave relationship in a different way: "Fix the GUI" as the top ticket, and sub tickets like :"implement menus per marketings request", and "Install new font", "Get icons from graphics guy and integrate" So, then I found the forms plugin, which doesn't force the dependencies, but works in our scenario. ok, so the point is, this particular topic is very implementation specific, and I suspect creating a plugin that is generic enough would be tough. the "close all children" option proposed could be done with creative use of the BatchModify plugin, for example, but I don't want that feature, you might.....There is probably an implementation that could make use of the TicketValidator as well, etc... The other side of the coin is, in theory, it could be done, with already existing plugins for the most part, and creative implementation points. (can you tell I'm an Assembly guy at heart?) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
