This avoids the performance implications of rendering very large
task graphs. This also allows parent tasks and subtasks to be
discoverable when the graph cannot be displayed efficiently.
Details
Details
- Reviewers
epriestley - Group Reviewers
Blessed Reviewers
viewed a task with a large number of subtasks, saw the
old-fashioned list of subtasks instead of a graph.
Diff Detail
Diff Detail
- Branch
- wmf/stable
- Lint
Lint Passed - Unit
Tests Passed - Build Status
Buildable 13092 Build 16737: arc lint + arc unit
Event Timeline
| src/applications/maniphest/controller/ManiphestTaskDetailController.php | ||
|---|---|---|
| 68 | Was ManiphestTaskHasCommitEdgeType removed intentionally? I've restored it because I find a list of commits to be quite useful but maybe upstream has other ideas? | |
| 82–87 | This is the part that restores the pre-graph behavior. | |
| 307 | I moved this to the caller, passing it as a parameter instead of hard-coding it here. I think there is only one call site for this particular function so it should be safe to refactor it a bit. | |
| 310 | I also noticed that ManiphestTaskHasCommitEdgeType seems to have gone missing, I am not sure if that was intentional. | |
Comment Actions
I misplaced the end of the if (!$task_graph->isEmpty()) block
Also, fix the lint error about a long line.
Comment Actions
I misplaced the end of the if (!$task_graph->isEmpty()) block
Thanks to @Danny_B for catching that!
Comment Actions
I think the commit stuff is working properly already -- the code is a little tangled, but we try to merge revisions into that section if we can, and only render it separately if we need to. That is, we attempt to render:
Commits: Dxxxx / rXyyyy Blah blah
...if possible, which is both a revision and the associated commit, like this:
That seems to be working correctly? That is, I see "Revisions", "Commits" and the combined/merged section properly in the UI, as far as I can tell. Did the code just look wrong or was there an actual UI issue you hit?
Otherwise, I think D16343 + D16344 now solve this problem reasonably? Basically:
- If you have a few connected tasks, we show the whole graph.
- If you have a lot of connected tasks, we show the nearby parts of the graph (direct parents / subtasks).
- If you have a ton of tasks, we don't show anything.
- But, you can always get to the full list via Search... → Search Subtasks, introduced in D16343. My assumption is that this is probably better for cases where a parent task is being used to collect 100+ subtasks, since now you can paginate the list, filter by status/projects, save the query, etc.