Edgewall Software
Modify

Opened 11 years ago

Last modified 5 months ago

#31 new enhancement

Bug dependencies/relations feature

Reported by: daniel Owned by: cboos
Priority: high Milestone: next-major-releases
Component: ticket system Version: devel
Severity: normal Keywords: dependencies block duplicate field links relations
Cc: wkornewald, robert.pollak@…, chris@…, somekool@…, dimitrisp-lists@…, vyt@…, radek@…, mrovner@…, trac@…, trac@…, shishz@…, jorvis@…, mjhweb-trac-tickets@…, trac-spam@…, peter.merel@…, kveretennicov@…, nick+trac@…, ccidral.newsbox@…, mark81@…, gustavo.noronha@…, carwyn@…, mark@…, hwinkel@…, bfults@…, trac@…, e@…, me3xxx@…, mikd454@…, lukas@…, dicianno@…, zeph.gillen@…, n00spam-developer@…, thomas@…, pphaneuf@…, henry78@…, louie@…, mikepan@…, alon.barlev@…, przemjaskier@…, nruffel@…, cjunge@…, braden@…, hoessler@…, trac@…, mian.hasan.khalil@…, n-roeser@…, hongqn@…, leho@…, itamarost@…, kirean@…, hoff.st@…, mikko.rantalainen@…, alex@…, joao.antunes@…, cv.mail@…, brad-trac@…, david@…, ethan.jucovy@…, net147@…, mrelbe, marcus@…, franz.mayer@…, vladimir.chebotarev@…, jaywir3@…
Release Notes:
API Changes:

Description

A simple list of related bugs without logical/implicit constraints might be useful. It'd be nice to be able to relate bugs and issues in a useful manner.

It would also thus allow for reports showing "a bug and all related bugs" in some fashion, which could be neat.

This would also require checking for circular dependencies/relations.

Attachments (4)

trac-0.8.1-ticket-relations.patch (18.3 KB) - added by havarden@… 9 years ago.
Another implementation for ticket relations. Quick and dirty, but can be extended to support backlinks. Added to show the design ideas rather than the implementation.
trac_r7937_ticket_relations.patch (26.7 KB) - added by Joachim Hoessler <hoessler@…> 5 years ago.
Another implementation for links between tickets
ticket_relations-jh.png (9.9 KB) - added by cboos 4 years ago.
Displays Blocking/Blocked by relations (using patch from Joachim Hoessler updated for trunk [39beeca9d168/ticket-links])
ticket_relations-redmine.png (27.5 KB) - added by cboos 4 years ago.
Example alternative UI (snapshot from http://www.redmine.org/issues/1189)

Download all attachments as: .zip

Change History (186)

comment:1 Changed 11 years ago by daniel

  • Version set to 2.0

comment:2 Changed 11 years ago by daniel

  • Milestone set to 2.0
  • Version changed from 2.0 to devel

comment:3 Changed 11 years ago by daniel

I'm ambivalent regarding this one… Plain comments with TracLinks are quite useful on their own… Maybe we should avoid this feature to avoid complexities.

People who need more strict relationships between issues are probably better off using some dedicated issue tracker, like roundup or bugzilla or something… Just my two.

After all, informal is our game :)

/DanielLundin

comment:4 Changed 10 years ago by bill@…

I think a simple ticket_relations table with a schema like this would be simple and useful:

  • ticket1 (int)
  • relation (text)
  • ticket2 (int)

where relation could be (ideas):

  • 'blocks': implement bugzilla-style dependencies
  • 'is duplicate of': track duplicates
  • 'is related to': track related tickets
  • 'is subtask of': we often break down large tasks into smaller ones, this would be useful to associate the subtask with the main task

Then, on the ticket page, you could have a separate section that lists ticket relations, in both directions! (e.g. where ticketid == ticket1 or ticketid == ticket2)

comment:5 Changed 10 years ago by scapo

  • Owner changed from jonas to anonymous
  • Priority changed from lowest to highest
  • Severity changed from enhancement to major
  • Status changed from new to assigned

essai de gestion de projet

comment:6 Changed 10 years ago by anonymous

Here's a use case I consider reasonably important: show only tickets that are "actionable", that is, either do not depend on any ticket, or depend on closed tickets only.

comment:7 Changed 10 years ago by anonymous

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:8 Changed 10 years ago by jonas

  • Resolution fixed deleted
  • Status changed from closed to reopened

Why was this ticket closed?

comment:9 Changed 10 years ago by cmlenz

  • Owner changed from anonymous to jonas
  • Status changed from reopened to new

#226 has been marked as duplicate of this ticket. See that ticket for a proposed patch and further comments, but add anything new here.

Also: resetting assignee to component owner.

comment:10 Changed 10 years ago by Tristan Seligmann <mithrandi@…>

  • Severity changed from major to enhancement

comment:11 Changed 10 years ago by anonymous

  • Priority changed from highest to normal

This certainly isn't highest priority.

comment:12 Changed 10 years ago by robert.pollak@…

  • Cc robert.pollak@… added

comment:13 Changed 10 years ago by david@…

This is definitely something I would like to see. The "search for all actionable" idea is an excellent one, and the concept of subtasks is also very useful; Mozilla's use of "metabugs" for tracking large projects is something that seems like quite an effective organizational tool.

comment:14 Changed 10 years ago by chris@…

I would also like this. I would like 3 items based off this though:

1) child tickets. I can create a parent ticket, then create a child ticket which would allow me to link it. Say I need something done, but I need something else done in another ticket first, I can make a child.

2) Linking similar issues. I would like to be able to say x and y are similar, and when I close x, I'd like to close y with the same resolution code.

3) Hot issues. Pretty much like 2, but basically saying that there is a real issue. I can then notify all the ticket owners who related their ticket to the hot issue, but their ticket will not close.

These would make tickets with trac a lot easier to work with. Thanks a bunch for the great software so far. :D

Changed 9 years ago by havarden@…

Another implementation for ticket relations. Quick and dirty, but can be extended to support backlinks. Added to show the design ideas rather than the implementation.

comment:15 Changed 9 years ago by cboos

  • Milestone changed from 2.0 to 0.9
  • Owner changed from jonas to cboos
  • Status changed from new to assigned

The original intent of this ticket was:

  • A simple list of related bugs without logical/implicit constraints …
  • It would also thus allow for reports showing "a bug and all related bugs" in some fashion, which could be neat.
  • This would also require checking for circular dependencies/relations.

This is fully implemented in TracCrossReferences, so I'll be able to close the ticket when this is merged in the trunk (some cleanups are still needed before that happens).

However, there are other points raised in the comments for this ticket:

  • duplicate tickets: I plan to do it like this: when one selects the duplicate resolution, an input field for filling the duplicate-of relation will be enabled.
  • child tickets: see #886 for this topic
  • linking similar issues: Trac handle this by closing the duplicate ticket with the duplicate resolution (see above)
  • hot tickets? (point 3. in the comment above): sorry, I don't get it.

comment:16 Changed 9 years ago by robert.pollak@…

  • Cc robert.pollak@… added; robert.pollak@… removed

comment:17 Changed 9 years ago by chris@…

  • Cc chris@… added

On linking, sometimes they are similar but not the same. I have a few tickets where one thing is similar to another, and if one ticket was resolved it would really help the other ticket, but overall they are different issues. If I could relate the two it would just be a more beneficial situation.

On hot tickets, this is before I saw the ticket priorities. I guess I overlooked them or something, I withdraw this request.

comment:18 Changed 9 years ago by cboos

On linking as you expressed it: well, that would be just a normal cross-reference from one ticket to the other. You can infer the semantic by looking at the context (cross-references are listed along with a fragment of the context in which they were made).

I'll soon start the merging process, a.k.a have a chat with cmlenz :)

comment:19 Changed 9 years ago by Florent Guillaume <fg@…>

  • Cc fg@… added

comment:20 Changed 9 years ago by Christian Parpart <trapni@…>

  • Cc trapni@… added

what's the current state of development of this features? Is it already merged to trunk?

I'd really like to migrate from bugzilla/mediawiki completely to trac, but I can't unless it doesn't support ticket dependencies :)

besides, would it be possible to automatically get generated a tree-view describing current dependencies? (would be a neat feature though)

comment:21 Changed 9 years ago by cboos

I first want to have 2 other, less complex, branches merged in the /trunk:

  • the category-branch (a.k.a ticket types, #919)
  • the intertrac-branch (see InterTrac)

After that, it's the turn of the xref-branch (see TracCrossReferences), for which I plan to add, besides what's currently done:

  • adding a time information in the xref table, so that the xrefs can be listed from the most recently created xref to the oldest.
  • adding a depends_on field/facet to the ticket table, so that the textual context in which the reference to the dependent ticket was entered can be remembered

About tree-view describing current dependencies?: I could add that, see Xref.get_dag.

comment:22 Changed 9 years ago by cmlenz

#1540 has been marked as duplicate of this ticket.

comment:23 Changed 9 years ago by anonymous

  • Cc mathieu@… added

comment:24 Changed 9 years ago by cmlenz

  • Milestone changed from 0.9 to 1.0

Postponed.

comment:25 Changed 9 years ago by dimitrisp <dimitrisp.lists@…>

  • Cc dimitrisp-lists@… added

comment:26 Changed 9 years ago by Gunnar Wagenknecht <gunnar@…>

  • Cc gunnar@… added

comment:27 Changed 9 years ago by anonymous

  • Cc vyt@… added

comment:28 Changed 9 years ago by anonymous

  • Cc wjl@… added

comment:29 Changed 9 years ago by Gunnar Wagenknecht <gunnar@…>

  • Cc changed from robert.pollak@gmail.com, chris@growl.info, fg@nuxeo.com, trapni@gentoo.org,mathieu@ubertor.com, dimitrisp-lists@gmail.com,gunnar@wagenknecht.org, vyt@vzljot.ru, wjl@icecavern.net to robert.pollak@gmail.com, chris@growl.info, fg@nuxeo.com, trapni@gentoo.org, mathieu@ubertor.com, dimitrisp-lists@gmail.com, gunnar@wagenknecht.org, vyt@vzljot.ru, wjl@icecavern.net

comment:30 Changed 9 years ago by anonymous

  • Cc radek@… added

comment:31 Changed 9 years ago by dragisha@…

  • Cc dragisha@… added

comment:32 Changed 9 years ago by anonymous

  • Cc mrovner@… added

comment:33 Changed 9 years ago by chris@…

This ticket is a good example of what we need with ticket dependencies:

http://trac.growl.info/trac/ticket/114

comment:34 Changed 9 years ago by brianlsmith@…

  • Cc brianlsmith@… added

comment:35 Changed 9 years ago by anonymous

  • Cc trac@… added

comment:36 Changed 9 years ago by Russell Hind <rhind@…>

  • Cc rhind@… added

comment:37 Changed 9 years ago by cboos

  • Keywords xref added

Proposed UI

+----------------------------------------+
|                        |               |
|depends on: #123 #213   |  blocks: #456 |
|                                        |
|     ...  ticket description      ...   |
|                                        |
+----------------------------------------+

Attachment:

Change History:
 ....

Change Properties

 ...
 Cc:
 Depends on: _#123 #213________________

Action
  ...

Implementation detail

Until I find a good data model for generalized facets and properties, I've thought there can be an acceptable interim measure: storing the dependency information in the xref.context field. This means that whenever we have xref.facet == xref.relation, the xref.context is actually the full information, instead of an excerpt of some other source.

comment:38 Changed 9 years ago by anonymous

  • Cc trac@… added

comment:39 Changed 9 years ago by anonymous

  • Cc somekool@… added; mathieu@… removed

comment:40 Changed 9 years ago by earle

  • Cc trac@… added

comment:41 Changed 9 years ago by anonymous

  • Cc fg@… removed

comment:42 Changed 9 years ago by anonymous

  • Cc shishz@… added

comment:43 Changed 9 years ago by anonymous

  • Cc jorvis@… added

comment:44 Changed 9 years ago by anonymous

  • Cc mjhweb-trac-tickets@… added

comment:45 Changed 9 years ago by anonymous

  • Cc trac-spam@… added

comment:46 Changed 9 years ago by anonymous

  • Cc mrovner@… added; mrovner@… removed

comment:47 Changed 9 years ago by anonymous

  • Cc peter.merel@… added

comment:48 Changed 9 years ago by Bruce Christensen <trac@…>

  • Cc trac@… removed

comment:49 Changed 8 years ago by anonymous

  • Cc kveretennicov@… added

comment:50 Changed 8 years ago by anonymous

  • Cc nick+trac@… added

comment:51 Changed 8 years ago by anonymous

  • Cc ccidral.newsbox@… added

comment:52 Changed 8 years ago by anonymous

  • Cc zoogie@… added

comment:53 Changed 8 years ago by anonymous

  • Cc dlawson@… added

comment:54 Changed 8 years ago by anonymous

  • Cc mark81@… added

comment:55 Changed 8 years ago by anonymous

  • Cc gustavo.noronha@… added

comment:56 Changed 8 years ago by anonymous

  • Cc carwyn@… added

comment:57 Changed 8 years ago by anonymous

  • Cc jay@… added

comment:58 Changed 8 years ago by anonymous

  • Cc mark@… added

comment:59 Changed 8 years ago by anonymous

  • Cc gunnar@… removed

comment:60 Changed 8 years ago by anonymous

  • Cc hwinkel@… added; brianlsmith@… robert.pollak@… chris@… trapni@… somekool@… dimitrisp-lists@… vyt@… wjl@… radek@… dragisha@… mrovner@… trac@… rhind@… trac@… shishz@… jorvis@… mjhweb-trac-tickets@… trac-spam@… peter.merel@… kveretennicov@… nick+trac@… ccidral.newsbox@… zoogie@… dlawson@… mark81@… gustavo.noronha@… carwyn@… jay@… mark@… removed

comment:61 Changed 8 years ago by Russell Hind <rhind@…>

  • Cc brianlsmith@… robert.pollak@… chris@… trapni@… somekool@… dimitrisp-lists@… vyt@… wjl@… radek@… dragisha@… mrovner@… trac@… rhind@… trac@… shishz@… jorvis@… mjhweb-trac-tickets@… trac-spam@… peter.merel@… kveretennicov@… nick+trac@… ccidral.newsbox@… zoogie@… dlawson@… mark81@… gustavo.noronha@… carwyn@… jay@… mark@… added

hwinkel you removed everyone elses 'cc', not just added yours! Was this intended? If not, please can you cut and paste the cc's above and add them back in again?

comment:62 Changed 8 years ago by Russell Hind <rhind@…>

Sorry, looks like I added them back in, didn't mean to do that.

Russell

comment:63 Changed 8 years ago by bfults@…

  • Cc bfults@… added

+1 for this feature.

comment:64 Changed 8 years ago by trac@…

  • Cc trac@… added

Akismet

comment:65 Changed 8 years ago by anonymous

  • Cc e@… added

comment:66 Changed 8 years ago by anonymous

  • Cc me3xxx@… added

comment:67 follow-up: Changed 8 years ago by wkornewald

What about this:

Instead of adding fields for dependencies you just link to the related tickets as you do now. The ticket details shows non-editable "Refers to:" and "Referred from:" fields with the ticket numbers that were mentioned in this ticket and tickets that mentioned this ticket. A link "Track relations" could give you a detailed overview page that shows the *comments* which related to/from the tickets, so you can immediately get a quick overview of the relevant information including its context in the affected tickets.

That way, you don't track dependencies using an extra field, but directly with the comments which has the following advantages:

  • simpler (no need to take care of extra fields)
  • more intuitive (you just type the description)
  • you can't forget to fill in a dependency field
  • it works instantly with existing Trac installations
  • you automatically connect the relation with a comment

comment:68 in reply to: ↑ 67 Changed 8 years ago by cboos

Replying to wkornewald:

What about this: <snip>

Well, that's great, you just reinvented TracCrossReferences ;) It did just that, including showing a relevant fragment of the comments around the reference, to quickly grasp the context.

I should have produced snapshots at that time, but generalized cross-references were working great ;)

That way, you don't track dependencies using an extra field,

… but it also had provision for explicit linking (the relations part), though that part was never implemented in the UI.

comment:69 Changed 8 years ago by wkornewald

Ouch, you're right. I misunderstood TracCrossReferences. I thought it would require a special new link format, but the spec also speaks about general relations. Well, then I perfectly agree your solution! :)

Sorry for the noise…

comment:70 Changed 8 years ago by mgood

#4477 has been marked as a duplicate.

comment:71 Changed 8 years ago by mikd454@…

  • Cc mikd454@… added

comment:72 Changed 8 years ago by Waldemar Kornewald <wkornewald>

  • Cc wkornewald added

comment:73 follow-up: Changed 8 years ago by Noah Kantrowitz <coderanger@…>

Can some people please try out this plugin. Just install it and add a custom text field named "blocking". If you have any ideas for it, please let me know.

comment:74 Changed 8 years ago by anonymous

  • Cc with@… added

comment:75 Changed 7 years ago by Lukáš Petrovický <lukas@…>

  • Cc lukas@… added

comment:76 Changed 7 years ago by anonymous

Is it possible to explain the plan here? A lot of people are watching this ticket now, which should say something about the interest in it. I would personally love to use Trac but must stick with Bugzilla until this very fundamental feature is added.

comment:77 Changed 7 years ago by anonymous

  • Cc brianlsmith@… removed

comment:78 Changed 7 years ago by apexsutherland@…

  • Cc apexsutherland@… added

comment:79 Changed 7 years ago by anonymous

  • Cc dicianno@… added

comment:80 Changed 7 years ago by anonymous

  • Cc zeph.gillen@… added

comment:81 Changed 7 years ago by anonymous

  • Cc wkornewald removed

comment:82 Changed 7 years ago by anonymous

  • Cc wkornewald added

comment:83 Changed 7 years ago by anonymous

  • Cc dilshod@… added

comment:84 Changed 7 years ago by anonymous

  • Cc n00spam-developer@… added

comment:85 Changed 7 years ago by ThurnerRupert

so currently there is:

marked #5197 as dupl…

comment:86 Changed 7 years ago by Thomas Vander Stichele <thomas@…>

  • Cc thomas@… added

comment:87 Changed 7 years ago by anonymous

  • Cc al.barrett@… added

comment:88 Changed 7 years ago by Pierre Phaneuf <pphaneuf@…>

  • Cc pphaneuf@… added

comment:89 Changed 7 years ago by anonymous

  • Cc henry78@… added

cc changed: added henry78

comment:90 in reply to: ↑ 73 Changed 7 years ago by anonymous

Replying to Noah Kantrowitz <coderanger@yahoo.com>:

Can some people please try out this plugin. Just install it and add a custom text field named "blocking". If you have any ideas for it, please let me know.

Noah's plugin is working great for me so far and was a trivial install. Copy to Libs, add custom ticket type, and off you go.

(As an aside, throw my hat into the "Why isn't this a default feature?!" pile.)

comment:91 Changed 7 years ago by anonymous

  • Cc louie@… added

comment:92 Changed 7 years ago by anonymous

  • Cc mikepan@… added

comment:93 Changed 7 years ago by anonymous

  • Cc alon.barlev@… added

comment:94 Changed 7 years ago by anonymous

  • Cc przemjaskier@… added

Is there a time schedule for this task completion? Lack of this feature in the core cripples Trac and prevents it's better adoption…

comment:95 Changed 7 years ago by anonymous

Mylyn allows grouping by sub-tasks. Lack of this feature is degrading user experience from PM-perspective…

comment:96 Changed 6 years ago by alon.barlev@…

Hello,

I've read all related bugs, and could not figure out how this feature can be available using TracCrossReferences.

I don't care how it is called, master, dependency, blocker, relates.

What I require: bug A and bug B should be handled when bug C is completed. The tree bugs are assigned to different people. When bug C is closed, bug A and bug B CC list should be notified, so they know to perform whatever needed.

If I write #31 in bug text, say "This bug is depended on bug #31", and this bug is closed, then I the text is modified, example "This bug is depended on bug #30", this change in the status/text may trigger notification as if someone changed the bug text.

As far as I understand, changing the status of TracCrossReferences, does not cause all the references to be modified and treated as changed, so that subscribers get notification.

So any solution within current Trac features? I am afraid to install external plugins as it would break future migration.

I don't know how people may be expected to manage bug repository without relationship, how do you do this?

Thank you

comment:97 Changed 6 years ago by nruffel@…

  • Cc nruffel@… added

This is definitely a must have feature!

comment:98 Changed 6 years ago by rhind@…

  • Cc rhind@… removed

comment:99 Changed 6 years ago by nkantrowitz

Any objections to closing this now that MasterTickets is stable and usable? It could be further generalized to support mutliple types of relations, but I think that should be left as a feature request on the plugin.

comment:100 follow-up: Changed 6 years ago by anonymous

Using third-party plugin for such essential functionality looks risky. What about migration path and compatibility issues? There is no guarantee on the future compatibility of MasterTickets? and Trac. Besides, MasterTickets? looks quite limited. Trac is great, I bet you can do better than that.

I can't believe that Trac team avoided implementation of such essential feature for so long (this ticket is 4+ years old). I love Trac but it's unusable in large projects because of things like this. Sad.

comment:101 in reply to: ↑ 100 Changed 6 years ago by cboos

  • Milestone 1.0 deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

Replying to anonymous:

Using third-party plugin for such essential functionality looks risky…

See googlegroups:trac-dev:31612a1978ef2609 for a follow-up on this.

comment:102 Changed 6 years ago by alon.barlev@…

I cannot believe this! So trac is not going to be decent bug tracking system… OK, I will wait for some better solution. This is sad, as the trac project is so close to provide proper functionality.

comment:103 Changed 6 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Me neither. Why is this bug closed? If the use of an external plugin isn't satisfying, then this bug should be just a feature request, but not closed. (see type: enhancement)

comment:104 Changed 6 years ago by armando@…

cboos — that google link is interesting, but doesn't really defend closing this bug (if anything it just reiterates that the feature is sorely missed).

I think that for most of us, this has sealed the deal for continuance of use of Trac. There's no point anymore, it seems. For 4 years, people have been saying "Hey, we need this feature," and the core team has decided to ignore the desires of it's users, in the end. Honestly, I find it quite depressing. I mostly like Trac, but now that this issue has been tabled indefinitely, I'm officially giving up.

It's sad that a mish-mash of Wiki and Bugzilla can be more useful than the otherwise quite elegant Trac.

Also, I don't understand the purist idealogy that makes one /not/ want this feature in Trac, and I suppose I never will.

My 2¢, armando

comment:105 Changed 6 years ago by just use redmine

just use redmine www.redmine.org it is not as full-featured as trac but it is so much easier to set up and maintain. It's also catching up quickly. I believe it is less than 6 months old.

comment:106 Changed 6 years ago by anonymous

I agree with others here that the lack of this feature is what made me not use Trac. I was so unhappy with the available choices out there (integrated bug tracking, task tracking, wiki, timelines, etc.) that a group of developers and me created a new SF.net project from scratch to do all this. We've been working on it for about 6 months, and one of the key design goals is that it be visually appealing and have a great interface. Trac was so close but some key features like this one made it unusable for us.

I'll post again when we have our first release, though we've been using our new one internally for the last 2 months for testing. :)

comment:107 Changed 6 years ago by armando@…

On cursory examination redmine seems pretty great. I hate that RoR apps tend to take a lot of memory, but if it delivers what it claims (I especially like the multiple SCM integration), I'll be pleased.

Thanks for all the fish, Trac.

comment:108 Changed 6 years ago by anonymous

We (software development department of a major .eu telco) have migrated from Trac to Redmine recently after a long decision. Trac is a very, very good piece of software, but when it comes to a multiproject tracking, dependencies, time tracking - Trac looses the game.

We are using redmine for about two weeks for now and we love it.

Still, we'll keep on pulse of Trac because we love it, too and wish the best to the project:)

comment:109 Changed 6 years ago by nkantrowitz

To anyone who thinks we are ignoring the request: I am both a developer of Trac itself, and the creator of the plugin. The issue of having the feature is not being debated, nor will I stop maintaining the feature in either location. The location of the code is what is up for discussion, I personally would rather keep it in a small-standalone plugin rather than tie it directly to the Trac codebase (as mentioned in the thread). To say that "it doesn't count if its not in core" is counter to many of the ideals Trac is based on IMO. The basic feature is there, it works well and and provides a flexible way to work with ticket dependencies. I am not saying it is finished, just that I think it would help everyone to move more specific requests (multiple link types, non-blocking links, better reporting views, etc) over to the plugin where they can be dealt with directly. I should have been more clear about my intentions with this.

comment:110 Changed 6 years ago by ThurnerRupert

what would be interesting:

comment:111 Changed 6 years ago by cmlenz

This ticket should not have been closed, so thanks anonymous for reopening it. There certainly is no consensus that Trac shouldn't have ticket dependencies, or that it should be in a plugin instead of in core.

So why hasn't this been implemented yet after such a long time? That's due to how open source projects works, in particular when they are not backed by a company that provides financial backing or resources, and how such projects depend on people who need features to step up and help implement them. Unfortunately this particular feature has seen very little of that.

comment:112 follow-ups: Changed 6 years ago by anonymous

cmlenz, nkantrowitz

Problem with Trac and this dependency extension is that I'm aware of a few such plugins/extensions/whatevers: xrefs, MasterTickets?, and others listed on wiki. Trac starts to become a mess! A lot of effort is lost for duplicated, malfunctioning modules scattered around instead of being brought to the core.

If someone chooses ticket system, even in case of a small opensource project it IS an investment in the future. Hawing so many similar solutions, none of these being actually fully implemented satisfactory solution for such a basic need as dependencies is ridiculous. Migration? Maintenance? Upgrades? Come on…

Plugins have sense for very rarely used stuff or niche, third party integration modules, but popular SCMs and model should be supported by the core, assuring consistency in development.

If this was what cboos was fighting for, I've lost hope in Trac now, as cboos made a statement he quits.

It's incredible that Redmine in 6 months has implemented features which didn't make into Trac for 4+ years (poorly developed modules do not count): http://www.redmine.org/wiki/redmine

I'm migrating as soon as Redmine stabilizes. AFAIK they provide a migration tool for Trac users.

Thanks guys, anyway.

comment:113 in reply to: ↑ 112 Changed 6 years ago by anonymous

Replying to anonymous:

It's incredible that Redmine in 6 months has implemented features which didn't make into Trac for 4+ years (poorly developed modules do not count): http://www.redmine.org/wiki/redmine

I'm migrating as soon as Redmine stabilizes. AFAIK they provide a migration tool for Trac users.

The trac import does work well. I've migrated 2 trac systems to redmine without issue.

comment:114 in reply to: ↑ 112 Changed 6 years ago by ebray <hyugaricdeau@…>

Replying to anonymous:

cmlenz, nkantrowitz

Problem with Trac and this dependency extension is that I'm aware of a few such plugins/extensions/whatevers: xrefs, MasterTickets?, and others listed on wiki. Trac starts to become a mess! A lot of effort is lost for duplicated, malfunctioning modules scattered around instead of being brought to the core.

I've encountered very few Trac plugins that are incompatible with each other or that make things "messy". I suppose that partially depends on just how many plugins you're using at once though.

If someone chooses ticket system, even in case of a small opensource project it IS an investment in the future. Hawing so many similar solutions, none of these being actually fully implemented satisfactory solution for such a basic need as dependencies is ridiculous. Migration? Maintenance? Upgrades? Come on…

We've been using Trac heavily for a couple years now, and though we do sometimes have ticket dependencies, we simply write in the ticket, "This ticket depends on #a #b #c" or somesuch. I'm not saying that's anywhere near ideal for everyone—some people need stronger dependency tracking. But the MasterTicketsPlugin provides this pretty well—especially the 0.11 version. It's really not such a pain to install most Trac plugins.

comment:115 follow-up: Changed 6 years ago by druid@…

I recently started having tickets that were blocked until others are completed and started looking for this feature, so consider this another vote to properly implement this in Trac. The primary use I was looking for was to help weight blockers for priority based on how many other tickets were blocked by them, so a dependency tree graph or even a simple dependency count would be extremely useful.

comment:116 in reply to: ↑ 115 Changed 6 years ago by nkantrowitz

Replying to druid@caughq.org:

I recently started having tickets that were blocked until others are completed and started looking for this feature, so consider this another vote to properly implement this in Trac. The primary use I was looking for was to help weight blockers for priority based on how many other tickets were blocked by them, so a dependency tree graph or even a simple dependency count would be extremely useful.

You mean like the depgraph MasterTickets generates?

comment:117 Changed 6 years ago by cjunge@…

  • Cc cjunge@… added

comment:118 Changed 6 years ago by trapni@…

  • Cc trapni@… removed

i've given up using trac in favor of redmine, which has this feature implemented. i'll continue to watch the progress of trac of course, but currently, redmine is by far the more powerfull tool, supports multiple projects in not the hackish way, supports even GIT repositories officially, and - of course - knows about ticket relations/dependancies.

comment:119 Changed 6 years ago by jaylward@…

  • Cc jaylward@… added

comment:120 Changed 6 years ago by rblank

  • Milestone set to 1.0
  • Owner cboos deleted
  • Status changed from reopened to new

Re-scheduling to latest milestone in ticket history.

comment:121 follow-up: Changed 6 years ago by anonymous

I've read the entire comments discussion multiple times. I think there's more to this than just master tickets (#886 or the external plugin). There's also more to it than just using "duplicate" to express a relationship and TracCrossReferences doesn't quite get us all the way there.

I'd like to see something like this (keep in mind, I don't know the database schema, and I don't know python, just throwing out an idea here):

  • A ticket_relationship_types table that lets me configure different relationship types in the web admin.
    • The able contains left hand side text and associated right hand side text.
    • Built in types would be "blocks / is blocked by", "is related to / is related to", "is a sub-task of / has sub-task", "precedes / follows".
    • Since this would be configurable I can add my own custom types for my project, such as "is a user story of / has user story"
  • A ticket_relationship table that matches a left-hand-side ticket with a right-hand-side ticket and a certain relationship type.
  • When I view a ticket, the left-hand-side ticket gets the "blocks" text in its properties and the right-hand-side ticket gets the "is blocked by" in its properties.

I think this sort of system would fit the bill. It's completely flexible, and it's opt-in (no need to use it, but for those of that do it would be great if the option was there). I think this covers everything from a ticket standpoint, but to make it more powerful, obvisouly we would want to have reports.

The precedes/follows relationship type would be great for making gantt charts to give an idea of the ticket order of completion within a milestone (block/blocked by is precedes/follows in disguise).

Hopefully this discussion isn't dead. I think ticket relationships is a really important features, and I'd like to see it be part of the core itself.

comment:122 in reply to: ↑ 121 Changed 6 years ago by osimons

Replying to anonymous:

I've read the entire comments discussion multiple times. I think there's more to this than just master tickets (#886 or the external plugin). There's also more to it than just using "duplicate" to express a relationship and TracCrossReferences doesn't quite get us all the way there.

I'd like to see something like this (keep in mind, I don't know the database schema, and I don't know python, just throwing out an idea here):

snip… snip… snip… (see above)

That was more or less my thoughts as well, and your ideas I think fit quite well with my TracDev/Proposals/TracRelations proposal. I'd like a general API in Trac for relationships that would allow code/plugins to build any kind of mechanism enforcing structure and dependencies.

comment:123 Changed 6 years ago by al.barrett@…

  • Cc al.barrett@… removed

comment:124 Changed 6 years ago by braden@…

  • Cc braden@… added

comment:125 Changed 5 years ago by anonymous

  • Priority changed from normal to low

comment:126 Changed 5 years ago by anonymous

  • Priority changed from low to normal

Changed 5 years ago by Joachim Hoessler <hoessler@…>

Another implementation for links between tickets

comment:127 follow-ups: Changed 5 years ago by Joachim Hoessler <hoessler@…>

  • Cc hoessler@… added

This patch against source:trunk@7937 is another shot at this issue. It implements configurable relationships between tickets in a rather straight forward way. It includes

  • a new database that stores source, destination and the type of a link
  • a new extension point in the ticket api that allows other components to provide information on links
  • an component that uses this extension point to create links as specified in trac.ini in the form of
    [trac-links]
    blocker = blocking, blockedby
    blocking.label = Blocking
    blockedby.label = Blocked By
    blocker.validator = no_cycle
    
  • the implementation supports bidirectional links (the opposite direction is set automatically), unidirectional links and reflective links
  • validation is implemented through the ITicketManipulater interfaces
  • links are edited and rendered in the ticket view as text fields in the format "#1, #2, #5"

The basic stuff works so far. However, it doesn't implement ticket "blocking" or other workflow related impact of links yet, but this could be easily added, either in this implementation, or in a plugin. Also, any visualization of dependencies isn't included yet.

I know that there are suggestions in this ticket thread for a more advanced approach, but I think this implementation should be sufficient for most of the use cases.

comment:128 Changed 5 years ago by trac@…

  • Cc trac@… added

comment:129 Changed 5 years ago by Sebastian Heuchler <sheuchler@…>

  • Cc sheuchler@… added

comment:130 Changed 5 years ago by apexsutherland@…

  • Cc apexsutherland@… removed

comment:131 Changed 5 years ago by koen2@…

  • Cc koen2@… added

comment:132 Changed 5 years ago by dragisha@…

  • Cc dragisha@… removed

No hope to see some change here, as far as I can see from some year being on list :)

comment:133 Changed 5 years ago by anonymous

I'm not sure why the proposed patches aren't getting reviewed. I don't know enough about Trac core myself to understand it.

In the meantime, I ported my http://trac-hacks.org/wiki/TracDupPlugin to 0.11 We use that just fine at work, and the important parts there are being able to duplicate easily (closing the ticket as such), and reports on duplicate counts.

comment:134 Changed 5 years ago by Drops <drop_s@…>

+1

comment:135 in reply to: ↑ 127 Changed 5 years ago by Drops <drop_s@…>

Replying to Joachim Hoessler <hoessler@…>:

[trac-links]
blocker = blocking, blockedby
blocking.label = Blocking
blockedby.label = Blocked By
blocker.validator = no_cycle

I have patched my Trac 0.12dev(source:trunk@8552) demo site and found that instead of [trac-links] has to be [ticket-links].

comment:136 Changed 5 years ago by Hasan Khalil <mian.hasan.khalil@…>

  • Cc mian.hasan.khalil@… added

comment:137 Changed 5 years ago by n-roeser@…

  • Cc n-roeser@… added

comment:138 Changed 5 years ago by hongqn@…

  • Cc hongqn@… added

comment:139 Changed 4 years ago by cboos

  • Milestone changed from 1.0 to unscheduled

Milestone 1.0 deleted

comment:140 Changed 4 years ago by anonymous

Just a note that I'd also really like this feature. Quite often you have one or more user-visible features (each with a bunch of discussion about how it should work) that depends on a major core feature. The latter will have its own discussion about how it should be implemented. I'd like to have separate bugs, with a note about the dependency, and possibly priority inheritance.

I'm a brand new Trac user, started installing on Monday, and already Wednesday morning I want this feature. We're just using it for sysadmin type tasks, and I need a way to explain that "set up database mirroring" depends on "install new server". Conceptually, they're separate things (one set of comments is about performance and recovery procedures, while the other is about parts selection and rack space), but there's a dependency…

This two-level milestone/ticket thing is too limiting.

comment:141 follow-up: Changed 4 years ago by anonymous

  • Resolution set to fixed
  • Status changed from new to closed

Found a solution! The th:wiki:MasterTicketsPlugin provides this feature. You can see it in use at http://trac.xbmc.org/

comment:142 in reply to: ↑ 141 Changed 4 years ago by dilshod@…

Replying to anonymous:

Found a solution! The th:wiki:MasterTicketsPlugin provides this feature. You can see it in use at http://trac.xbmc.org/

Shouldn't this ticket be closed by the owner of the ticket instead of an anonymous user? What's the official word on this?

comment:143 Changed 4 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

It should not be closed… The way Trac team is aproaching this subject and because it takes so long, made me drop Trac. Featurewise, Redmine leaves Trac far, far behind.

comment:144 Changed 4 years ago by sheuchler@…

  • Cc sheuchler@… removed

removing mail… have to add a comment so it won't be branded as spam >_>

comment:145 in reply to: ↑ 127 Changed 4 years ago by cboos

  • Keywords dependencies block duplicate added; xref removed
  • Milestone changed from triaging to next-major-0.1X

Replying to Joachim Hoessler <hoessler@…>:

First, sorry for not having reviewed the patch earlier…

This patch against source:trunk@7937 is another shot at this issue. It implements configurable relationships between tickets in a rather straight forward way. It includes

  • a new database that stores source, destination and the type of a link
  • a new extension point in the ticket api that allows other components to provide information on links
  • an component that uses this extension point to create links as specified in trac.ini in the form of
    [trac-links]
    blocker = blocking, blockedby
    blocking.label = Blocking
    blockedby.label = Blocked By
    blocker.validator = no_cycle
    
  • the implementation supports bidirectional links (the opposite direction is set automatically), unidirectional links and reflective links
  • validation is implemented through the ITicketManipulater interfaces
  • links are edited and rendered in the ticket view as text fields in the format "#1, #2, #5"

The basic stuff works so far.

This looks good, both in terms of functionality and code.

However, it doesn't implement ticket "blocking" or other workflow related impact of links yet, but this could be easily added, either in this implementation, or in a plugin.

If someone wants to get this integrated, it would be nice to refresh the patch against trunk, to perform a clean-up along the lines of TracDev/CodingStyle and, in a second step, to add a "blocker" ITicketManipulator.

Also, any visualization of dependencies isn't included yet.

This isn't necessary, but could always be added later as a tracopt component.

I know that there are suggestions in this ticket thread for a more advanced approach, but I think this implementation should be sufficient for most of the use cases.

Agreed. It seems that a better handling of duplicates could also be easily added on top of this, even possibly a parent/child relationship, yet this keeps the approach reasonably simple.

comment:146 Changed 4 years ago by koen2@…

  • Cc koen2@… removed

[Removing e-mail address from CC]

Thanks for the great product nonetheless :)

comment:147 Changed 4 years ago by cboos

I've updated the patch for trunk, and the patch seems to work fine. However, the UI is a bit rudimentary:

Displays //Blocking/Blocked by// relations (using patch from Joachim Hoessler updated for trunk [39beeca9d168/ticket-links])

I prefer the way it looks in RedMine:

Example alternative UI (snapshot from http://www.redmine.org/issues/1189)

(from #1189 at redmine.org)

Time for a topic clone ;-)

Changed 4 years ago by cboos

Displays Blocking/Blocked by relations (using patch from Joachim Hoessler updated for trunk [39beeca9d168/ticket-links])

Changed 4 years ago by cboos

Example alternative UI (snapshot from http://www.redmine.org/issues/1189)

comment:148 Changed 4 years ago by cboos

I just added the ticket-links Mercurial clone. There, you'll find the ticket-links branch which corresponds to the original patch on r7937, and the ticket-links-trunk which is that branch merged on latest trunk (r9982), plus a few fixes of mine.

If you want to try it out, please read comment:135, the configuration section name in the TracIni is [ticket-links]. This patch upgrades the database to version 27, so either use a copy of your environment before upgrading or create a fresh environment to play with, as there's no guarantee that this step 27 will be the definitive one.

Testing, feedback and further patches welcomed.

comment:149 Changed 4 years ago by cboos

  • Keywords field links relations added
  • Owner set to cboos
  • Priority changed from normal to high
  • Status changed from reopened to new

I've made a few progress yesterday, it works a bit better but I also see a few issues or difficulties with this approach. As the notes in this comment grew bigger, I've moved it in a TicketLinks page describing the work in progress.

comment:150 Changed 4 years ago by lkraav <leho@…>

  • Cc leho@… added

comment:151 Changed 4 years ago by itamaro

  • Cc itamarost@… added

comment:152 Changed 4 years ago by Erik Andersson <kirean@…>

  • Cc kirean@… added

comment:153 Changed 4 years ago by Michael Imamura <zoogie@…>

  • Cc zoogie@… removed

comment:154 Changed 4 years ago by dlawson@…

  • Cc dlawson@… removed

comment:155 Changed 4 years ago by hasienda <hoff.st@…>

  • Cc hoff.st@… added

Once again I learned a lot about (past) Trac development (culture) by reading through this top-down plus the linked trac-dev thread.

But I've lost more than one hour for Trac (plugin) development and got another task I'd love to help finishing it up, if only I had more free time to throw in. Anyway, I really hope the approach will a) be somewhat superior to existing solutions and b) materialize soon into trunk to save many more people from spending 1+ hour of their time too, so they could spend it on Trac development instead, right?

comment:156 Changed 4 years ago by jay@…

  • Cc jay@… removed

remove

comment:157 Changed 4 years ago by DT <dilshod@…>

  • Cc dilshod@… removed

comment:158 Changed 4 years ago by Mikko Rantalainen <mikko.rantalainen@…>

  • Cc mikko.rantalainen@… added

comment:159 Changed 4 years ago by Alex Willmer <alex@…>

  • Cc alex@… added

My extensions to cboos branch is reaching a conclusion. The code is on Bitbucket http://bitbucket.org/moreati/trac-ticketlinks/ (just a convenient place to publish a Mercurial branch).

Current features are display of linked tickets, configurable blocking and create linked ticket with configured fields pre-populated. Please feel free ask questions regarding the branch on the TracDev or TracUsers list and I would be happy to answer them. Also I'm in IrcChannel as moreati.

comment:160 follow-up: Changed 4 years ago by cboos

Thanks for your contributions! This looks very interesting but I still didn't have time to go through the changes to give you proper feedback. This will come ;-) I've nevertheless brought them in my clone on t.e.o, for easier inspection by others.

There are several branches there, maybe you could shortly summarize what's to be found in each (on the TicketLinks page).

I've myself paused the work on the ticket-links branch as after exploring a bit the way the relations were stored, I was not satisfied with the way to store ticket properties, which brought its own share of issues (notably in the custom query module - let's see how you dealt with that). So my current feeling is that I really need to progress first on the GenericTrac API and storage model, to see how this can benefit to this feature (and related ones like #886). I suppose most of what you've done will still be reusable even if the storage changes.

comment:161 in reply to: ↑ 160 Changed 4 years ago by Alex Willmer <alex@…>

Replying to cboos:

Thanks for your contributions!

You're most welcome, and thank you.

There are several branches there, maybe you could shortly summarize what's to be found in each (on the TicketLinks page).

There are only two branches of consequence:

  • ticket-links-trunk - Direct continuation of your work, intended for incorporation into Trac mainline.
  • remote-tickets - Variation of TicketSystem.parse_links() to ignore name:#n links to work with a th:RemoteTicketPlugin I'm writing.

I've myself paused the work on the ticket-links branch as after exploring a bit the way the relations were stored, I was not satisfied with the way to store ticket properties, which brought its own share of issues (notably in the custom query module - let's see how you dealt with that).

I didn't I'm afraid, and I hadn't considered it. Are you referring to "specialized queries […] like showing all the duplicates by getting the transitive closure of the duplicate-of link"?

So my current feeling is that I really need to progress first on the GenericTrac API and storage model, to see how this can benefit to this feature (and related ones like #886). I suppose most of what you've done will still be reusable even if the storage changes.

Yes, it should be reusable. Data access, validation routines and behaviour are quite loosely coupled. There's unit test coverage throughout. The weak points I see are i18n, UI/formatting and maybe functional tests.

comment:162 Changed 4 years ago by joao.antunes@…

  • Cc joao.antunes@… added

comment:163 Changed 3 years ago by cv.mail@…

  • Cc cv.mail@… added

comment:164 Changed 3 years ago by brad-trac@…

  • Cc brad-trac@… added

comment:165 Changed 3 years ago by Dave Heston <david@…>

  • Cc david@… added

comment:166 Changed 3 years ago by with@…

  • Cc with@… removed

comment:167 Changed 3 years ago by alex@…

I have merged the 0.12-stable branch in to the ticket-links branch on bitbucket https://bitbucket.org/moreati/trac-ticketlinks. All unit tests and functional tests pass, but note that the ticket-links changes only have unit test coverage.

comment:168 Changed 2 years ago by Ethan Jucovy <ethan.jucovy@…>

  • Cc ethan.jucovy@… added

comment:169 Changed 2 years ago by net147@…

  • Cc net147@… added

comment:170 Changed 23 months ago by mrelbe

  • Cc mrelbe added

comment:171 Changed 22 months ago by marcus@…

  • Cc marcus@… added

comment:172 Changed 22 months ago by franz.mayer@…

  • Cc franz.mayer@… added

comment:173 follow-up: Changed 20 months ago by lkraav <leho@…>

I'm liking the lightweightish markup approach to subtasklists Github published today. I was already doing something similar before, just keeping track of "subtickets" as a simple list inside Description and sort of manually linking them to comment numbers. Too much manual work, of course, but now I'm a bit more confident that I was on the right path and if well implemented, it could work.

comment:174 in reply to: ↑ 173 Changed 20 months ago by Ryan J Ollos <ryan.j.ollos@…>

Replying to lkraav <leho@…>:

I'm liking the lightweightish markup approach to subtasklists Github published today.

That looks really nice. Thanks for sharing!

comment:175 Changed 20 months ago by wjl@…

  • Cc wjl@… removed

comment:176 Changed 18 months ago by vladimir.chebotarev@…

  • Cc vladimir.chebotarev@… added

comment:177 Changed 16 months ago by jaywir3@…

  • Cc jaywir3@… added

comment:178 Changed 5 months ago by anonymous

Is anyone reviewing one of the patches suggested above? Or is the Trac MasterLinks? plugin still the only realistic option? (I'm waiting for its web site to load while writing this…)

comment:179 Changed 5 months ago by jaylward@…

  • Cc jaylward@… removed

comment:180 Changed 5 months ago by rjollos

There are several ticket relations plugins on trac-hacks, including th:MasterTicketPlugin (trac-hacks.org is down at the moment). They all have significant shortcomings from what I've seen. In the future we might consider back-porting BloodhoundRelationsPlugin, but that will take some time.

comment:181 follow-up: Changed 5 months ago by mmalmeida

Not sure if it is directly related to this, but it would be cool to have a github-like feature of adding comment links on referenced tickets.

Eg: Ticket #2 new comment: This is related with #1! Triggers new comment in #1: Comment in #2 references this ticket: This is related with #1!

comment:182 in reply to: ↑ 181 Changed 5 months ago by ejucovy@…

Replying to mmalmeida:

Not sure if it is directly related to this, but it would be cool to have a github-like feature of adding comment links on referenced tickets.

Eg: Ticket #2 new comment: This is related with #1! Triggers new comment in #1: Comment in #2 references this ticket: This is related with #1!

There's a plugin th:TracBacksPlugin which provides the feature you're describing.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new The owner will remain cboos.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from cboos to anonymous. Next status will be 'assigned'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.