Page MenuHomePhabricator

Dependency tree view of tasks
Closed, DeclinedPublic


Related task upstream: Implement (tree) subtasks, as distinct from (graph) task dependencies

In Bugzilla I creates dependent bugs to form a tree of actions to do. Example for the Zuul upgrade a few months ago:

(dead link)
(See a working random example at )

Phabricator let us create sub tasks, I would love to see a deep tree representation of them.



Event Timeline

flimport raised the priority of this task from to Low.Sep 12 2014, 1:28 AM
flimport set Reference to fl162.

qgil wrote on 2014-04-18 22:13:36 (UTC)

Mmm... it looks like what you are asking for is

qgil wrote on 2014-04-18 22:25:28 (UTC)

Another factor to consider is that a tracking bug in Phabricator == a project (in many situations). Once the tasks are inside a project, you can see them all at once sorted by priority or organized in a workboard.

Any task having a dozen of dependents is a good candidate for a specific project. Most of these tracking bugs could be good and sensible Phabricator projects.

More about this at T68.

qgil wrote on 2014-04-19 15:58:21 (UTC)

◀ Merged tasks: T164.

qgil wrote on 2014-05-10 22:34:34 (UTC)

I'm not sure if/when this feature will be addressed upstream. Currently it's marked as "Wishlist".

Really a blocker for Day 1?

jdforrester wrote on 2014-05-11 07:37:11 (UTC)

Really a blocker for Day 1?

Agreed. Removing.

Qgil renamed this task from Phabricator does not provide a dependency tree view of tasks (used by us e.g. for tracking bugs) to Dependency tree view of tasks.Sep 24 2014, 2:54 PM
Qgil set Security to None.

For what is worth, there is "a five minute hack which adds a very, very rough graph view field when dropped into phabricator/src/extensions/":

I wonder if users are really missing "a deep tree representation" of tasks, now that any tracking bug or any epic task can get easily their own project with their own workboard.

In T96#973593, @Qgil wrote:

I wonder if users are really missing "a deep tree representation" of tasks, now that any tracking bug or any epic task can get easily their own project with their own workboard.

Yesterday I wanted to have a graph of a cluster of tasks because the dependency structure was messy and there was no tracking bug yet.

@adrianheine, can you link the main task here, and can you describe the scope of this cluster of tasks to understand your problem better, please?

@Qgil I reordered the dependencies, so it's probably not of much use now. It was T78006, and when I started looking at them dependencies were like this:

T86182 -> T78006
T86181 -> T78006
T78006 -> T72205
T78006 -> T85385
T78006 -> T74590
T78006 -> T74126
T78007 -> T72205
T78007 -> T74590
T78007 -> T74126

Not too complicated, but I missed the graph so much I actually built it myself in dot:

I then made T78006 the tracking task, made all bugs submitted by users depend on that one and made it depend on all subtasks I need to do. With that setup, I don't need a graph, because dependencies are simple and have only one depth. In the messed-up state, the graph was helpful, though.

Thank you! So the lack of the graph feature made the mess evident and difficult to get away with, forcing you to sort out the tasks in order to get some sense out of it. Now the dependencies are clear for everybody's benefit, and the graph feature is not needed anymore.

Hmmmm maybe there is a lesson here. ;)

No, the lack of graph feature made it more difficult for me to sort out the mess, which I planned to do in the first place.

Is there some progress on this task? I really miss the graph feature when dealing with tracking bugs and complex dependencies, which helped in bugzilla to check if all dependencies are set correctly.

There is now a "task graph" section under the description of some tasks; many just say "Task graph too large to display (this task is connected to more than 100 other tasks)". No idea how to read it, though. Its informational power is clearly very limited as it's apparently a linear list, rather than a graph.

phabricator-task-graph.png (220×647 px, 22 KB)

At least currently™ this is available, hence cl,osing as resolved as per

Aklapper claimed this task.

If you need a tree that's a WONTFIX...

If you need a tree that's a WONTFIX...

Why would it be?

Because that proposed implementation likely won't happen if I understood upstream plans correctly.

Nemo_bis changed the task status from Resolved to Declined.Jul 18 2016, 2:46 PM

Hm, I guess terminology doesn't help us here.

Still, there is clearly nothing even vaguely similar to a dependency graph which would allow to orient oneself in dependencies among multiple tasks, so it makes little sense to have this marked resolved. If someone has a clearer or more correct way to express the requirements and why they're not met, please update the title/description.