ticket relationships

john.kurkowski's Avatar

john.kurkowski

20 Jan, 2009 07:35 AM

Great simplicity in this app. If it doesn't overcomplicate it though, I'd like to see custom relationships between 2 tickets. For example, noting that ticket 1 is duplicated by ticket 2, or that ticket 3 is a requirement for ticket 4.

  1. 1 Posted by Will Duncan on 20 Jan, 2009 10:10 AM

    Will Duncan's Avatar

    This is something we've been discussing a great deal between ourselves and several users. Demand hasn't been extremely high for it, so if/when we do implement such a feature, we want to do it right, and not clutter anything up. The core goal is simplicity, as while tickets may be dependent on one to another, the simplest way was to originally allow for sorting in milestones, which curbed the need for many.

    Thanks for the input though, I'll bring it up when I speak with the team.

  2. 2 Posted by Steve on 20 Jan, 2009 09:54 PM

    Steve's Avatar

    +1 for related tickets

  3. 3 Posted by Eric on 24 Jan, 2009 06:58 PM

    Eric's Avatar

    I would like to see this as well.

  4. 4 Posted by leonardo on 28 Jan, 2009 12:15 AM

    leonardo's Avatar

    This is a feature that could help to organize a development & testing cycles in a better way. I would like to see it in future versions.

  5. 5 Posted by Anthony Constan... on 02 Feb, 2009 07:06 AM

    Anthony Constantino's Avatar

    We had this feature in Mingle and used it, but it wasn't particularly useful.

  6. 6 Posted by Bastian Kuberek on 03 Feb, 2009 09:34 PM

    Bastian Kuberek's Avatar

    +1 on that. Would also want to add:

    Tickets should be able to be moved from one project to another.

  7. 7 Posted by System on 11 Mar, 2009 06:52 PM

    System's Avatar

    A Lighthouse ticket was created for this discussion

  8. 8 Posted by Niels Meersscha... on 15 Feb, 2010 04:52 PM

    Niels Meersschaert's Avatar

    +1 on related tickets. Dependency tracking is my biggest gripe with Lighthouse. Also a way to mark & merge duplicate tickets would be extremely helpful.

  9. 9 Posted by Timothy Kay on 03 Mar, 2010 06:44 PM

    Timothy Kay's Avatar

    Assigning to milestones works very well for me and simplifies things a great deal.

    I have one suggestion. Each ticket should be able to block multiple milestones.

    Suppose, for example, I defer a milestone (push it out a week or two). All dependent tickets then get pushed out as well. But what if one of those tickets also blocked another milestone that is now due first? I have no way to express these dependencies, so the ticket priority gets lost.

    If I could select multiple milestones for a given ticket, then I can capture the dependencies. And it doesn't add any complexity.

    (The UI could be as simple as having a link next to the Milestone drop down that turns it into a multi-select.

  10. 10 Posted by Rick on 03 Mar, 2010 10:32 PM

    Rick's Avatar

    If you push out a milestone, you can push out future milestones by the same amount on the milestones page.

    I'm not really sure what putting a ticket in multiple milestones with competing due dates gets you. It's very unlikely we'll be adding ticket dependencies, multiple milestones, or multiple due dates.

    Bi-directional ticket links are a possibility, however. I don't have a timeframe yet, but we are starting to plan some major changes to Lighthouse.

  11. 11 Posted by Timothy Kay on 03 Mar, 2010 11:08 PM

    Timothy Kay's Avatar

    Rick,

    > If you push out a milestone, you can push out future milestones by the
    same amount on the
    > milestones page.

    You are assuming that my milestones depend on each other, which isn't
    necessarily the case. Suppose I slip milestone A past milestone B.
    Unfortunately, feature X blocks both of them, but we can't express that in
    Lighthouse. If I had A as the milestone for X, then slip A past B, I have
    to change X to now have B as a milestone. Otherwise, we think B is finished,
    but it's not!

    I'd like to say that X blocks both A and B, so that X keeps a high priority
    even if one of the projects slips past the other.

    -- Tim

  12. 12 Posted by Rick on 03 Mar, 2010 11:42 PM

    Rick's Avatar

    We're looking into better ways of managing tickets in milestones that
    should help in these cases. If X was really a blocker on both A and
    B, then you couldn't really complete either. It should be easier to
    move tickets around without forcing you into specifying relationships
    and dependencies. That's an aspect of Lighthouse that we're currently
    putting though into.

  13. 13 Posted by Timothy Kay on 04 Mar, 2010 04:20 AM

    Timothy Kay's Avatar

    Thanks for the feedback. I'll reiterate that the current model works very
    well for us. We like the tickets being ordered by the milestones (with the
    one issue I mentioned).

    As long as I have your attention, I'll suggest:

       - The milestone should list its Resolved tickets. (For example, I want to
       look up a ticket that I remember resolving on behalf of a milestone, so I go
       to that milestone, but it's not there because it's resolved.)
       - I'd like to be able to see all tickets via the Scheduled Milestones
       view. I don't get to see the ones that aren't listed. As a work around, I
       created milestone named High Priority and Low Priority with dates way in the
       past and future. It works pretty well for me.
       - Given that I'm working from the Milestones view, after I resolve a
       ticket, I want to end up back on the Milestones view.
       - I don't really care about dates on the Milestones view, but I do care
       about order. It would be great if I could change the order by drag'n'drop.
       That way, you could get rid of the distinction between Scheduled and
       Unscheduled.

    Excellent product! Thanks!

    -- Tim

  14. 14 Posted by Timothy Kay on 04 Mar, 2010 04:34 AM

    Timothy Kay's Avatar

    Two more things about milestones:

       - I'd like to see completed milestones on the same screen as the
       overdue/active ones. After all, if somebody resolves the last ticket,
       suddenly the milestone seems to disappear. (Maybe milestones could be marked
       as Completed, at which point they move to the other screen.)

    I guess the theme of my suggestions is to give me a better milestones-based
    launch point.

    -- Tim

  15. 15 Posted by Rick on 04 Mar, 2010 06:49 AM

    Rick's Avatar

    Thanks for the feedback. Milestones are one area that we've been talking about a lot lately. We have some big changes coming up. It's hard to say when though, since we have to balance it with ongoing support and some other things coming up.

  16. 16 Posted by Steve on 04 Mar, 2010 07:31 AM

    Steve's Avatar

    We use Milestones as related buckets of work, and it is often not the case that we have a "current" milestone. E.g., Web Page Design Done and HTML Complete are two different buckets of work that tend to run in parallel, though it's usually the case that the former completes before the ladder ;).

  17. 17 Posted by Bastian Kuberek on 04 Mar, 2010 03:06 PM

    Bastian Kuberek's Avatar

    We use Milestones as "Feature Release Dates". e.g. most our tickets are tagged bug or feature, bugs we try to release as they are fixed, and features get bundled into milestones that we release once a month.

  18. 18 Posted by Rick on 04 Mar, 2010 07:28 PM

    Rick's Avatar

    We're constantly tweaking our workflow internally. Right now, I throw tickets in feature milestones, and move them to weekly iteration milestones when those are ready to be worked on.

    I love hearing how everyone's using Lighthouse though. I think this is where a lot of our thought is going to go for our next set of updates.

  19. 19 Posted by Brian Koehler on 15 Jun, 2010 05:31 PM

    Brian Koehler's Avatar

    I like how you can link tickets by putting the "#" before the number so the user can click to the other ticket. I think the related/linked ticket numbers should be listed on the ticket by the milestone field. To search in the history field to find them is cumbersome,
    Also if the related ticket is closed it should have a line through it.

    Maybe have the fields "tickets this is related to" if you create the link from this ticket to another. And "other tickets relating to this one" if the link was created from the other ticket.

    That way we can create child/parent relationships on our own without having you change lighthouse work flow. Also we can control how/when we close a ticket. Ideally if it could be across projects, but not a necessity.

  20. Support Staff 20 Posted by Tiger Team on 15 Jun, 2010 05:41 PM

    Tiger Team's Avatar

    Yes, this is something we've considered - we're currently undergoing a
    design refresh and will look at how that fits in. (As a side note, the
    closed tickets already should have a strikethrough. I'm not sure why
    that's broken for you)

    Thanks for the suggestion (in the mean time, I'm sure that half of
    this could be achieved with GreaseMonkey).

  21. Support Staff 21 Posted by Tiger Team on 22 Sep, 2011 12:03 AM

    Tiger Team's Avatar

    Hey Everyone,

    Just deployed Ticket References. Watch http://hoth.entp.com for a blog post real soon on how it works.

  22. Tiger Team closed this discussion on 22 Sep, 2011 12:03 AM.

Discussions are closed to public comments.
If you need help with Lighthouse please start a new discussion.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac