@rrfeng: You already brought this up in T11680 - please see and follow the reply you received there. No need to add comments in numerous places to decentralize any conversations about the (currently unclear) underlying issue you're perceiving. Please stick to T11680 - thanks!

I think the "graph trace" UI is not suitable for task graph.
The most scene which has problem is 1 task has too many sub tasks. And then the graph-status takes too much spaces of the page(It is so wide).

@ksmith it's a Python script that you would run on your local machine. If you have arcanist setup for development it should be pretty simple to get it working. Ideally it would just be a plugin, but I didn't look into that approach yet.

@lyahdav : That looks pretty cool. It's not quite clear to me where it runs. Is this a script that one would install on the same box that phab itself is running on?

For anyone trying to get Kanban statistics / reports in the meantime, you can try this project I recently started working on:
https://github.com/lyahdav/analytics-limn-analytics-data/tree/kanban_stats. It generates a CFD (Cumulative Flow Diagram) and computes cycle time and lead time.

(Self-reminder of the downstream report: https://phabricator.wikimedia.org/T624#2606686 .)

This has happened about 2 months ago, so a lot of the damage has already happened. We had a listing somewhere about what to do, but I can't find it now, so I'll re-write it here for posterity:

This can cause a storm of commit mail when upgrading. If there are old tags which weren't imported at the time, when Phabricator is upgraded to a version containing D16129 it can fire off thousands of commit emails, flooding inboxes and making some folks grumpy at their Phabricator administrators.

In T5051#156552, @chad wrote:

...
This task will be re-scoped to just being about burn down charts for milestones.

As far as I know, no users have actually gone berserk and deleted all their comments in nearly two years now, so I don't plan to specifically build comment removal rate limiting: this action does not seem particularly more dangerous or abuse-prone in practice than other actions like adding comments, merging tasks, etc. If a user did do this, recovery is likely not very difficult even without limiting.

In my personal opinion adding a CC that cannot see the task is an error and like this should be treated, meaning ux should just report as error when try to save it. It is important that ux reports it since it can be overlooked by the person changing the task.

In T6502#187499, @dpaola2 wrote:

We have no precedents of abuse in Phabricator so far, but looking at our history with Bugzilla I will not be surprised the morning we find a first precedent.

^ I am incredibly jealous of your perspective and am really, really surprised you haven't had this problem yet!

How can we make the title and description more clear?

Hi Chad,

any customization.

Does this ticket request include displaying Status of each Task on the Workboard display?

For what its worth, the biggest violators at my company tend to be company executives who (sometimes) rightfully wish to skirt our process. But, when they see how trivial it is to skirt our process, they're tempted to do it more often. And then they do it more often.

In T4863#152912, @epriestley wrote:

• Diff/Mock: These are fairly straightforward, alhtough I'm not totally convinced that they're valuable. At least in my personal workflow, I don't imagine I'd be likely to ever use them, and I don't recall other requests for them offhand. I'm hesitant about building new hard-coded first-party application stuff, too, since we've made so much progress on getting rid of it. I could build this in a generic way, of course, but that makes it less straightforward.

In T11034#186209, @epriestley wrote:

The dialog can be resized by dragging the lower right corner.

What about show only active projects in "Browse projects" window?

Hello! What about show only active projects in "Browse projects" window?

See T4788#184477 for current plans.

In T4788#185925, @CodeMouse92 wrote:

[...] Still, I think it would be pretty simple to just shut off the task graph (but not the list?) in those situations [...]

I definitely agree that in most cases, 100+ subtasks (especially direct subtasks) is better as a project. Still, I think it would be pretty simple to just shut off the task graph (but not the list?) in those situations if there is an exception that hasn't been thought of.

It might be useful if the dependency resolution was only two-levels deep. That wouldn't really solve the problem for extremely wide trees though.

In T4788#185851, @chad wrote:

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

In T4788#185851, @chad wrote:

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

Also, before that is done, rather than showing "Task graph too large to display ..." message, have fallback to the old plain list of tasks. Therefore the information will still be available, but just simply not provided as fancy...

Re the limiting to hardcoded 100 nodes without any criteria:

The best of the best is of course our https://phabricator.wikimedia.org/T4007 ;-)

In T4788#185751, @bd808 wrote:

The task graph can get a bit out of hand -- https://phabricator.wikimedia.org/T2001

In T4788#184537, @epriestley wrote:

so the UI should still look good given that edge-case.

Understanding the use case is important in choosing how the UI degrades.

@epriestley, just thought you'd like to know that, on that aforementioned massive task, the task names are now entirely missing. If you scroll all the way to the right, it shows the assigned person, and that's it. :\

As was mentioned, there was code already for detecting a hidden hash/anchor and loading older transactions/comments to allow it to be reached. Turned out it was a cinch to hook it up, which I've done in D16256.

This is enormously complex to implement in the general case.

@epriestley, I'm not expecting any particular solution, just as long as the list of subtasks is navigable in some sane fashion.

so the UI should still look good given that edge-case.

Although the new graph display has the branch-like display at the left, that column is removed from the task titles (2 columns away) - which aren't indented to clearly show the parent-child relationship.

@epriestley, the use case is actually from my content development department. It's hard to explain the task, but the hundreds of direct subtasks was unavoidable, and the project workboard did not work well in their workflow. Developing content for educational software can be extremely demanding. That said, I'll admit it isn't common to have hundreds of subtasks. Still, it is a scenario that can happen, so the UI should still look good given that edge-case.

I'm leaning toward making it a "Relationships" box with "Task Graph", "Mocks" (with a thumbnail/gallery view instead of just titles), and "Commits/Revisions" (probably with a little more status information than we currently show).

That would be perfect!

One possible solution might be to make "Task Graph" box "Task Dependecies" and have a separate tab for a straight list (default, parent/sibling only) and graph.

Just file a new task once you have the necessary information.

Please reopen. It's holidays / long weekend nowadays (CA, US, CZ), so I can't provide ther required stuff immediately. We'll get back to it with more descriptions soon. Thanks.

We need a root problem description to move forward here.

Just FYI, but on this install there's some weird rendering going on:

Suggestion from one chat I had:

I mean even having just a "Revert" button for each change would be easier
Even if you had 50 to click, it's better than manually undoing :)

For reference, @Danny_B filed a copy of this on HackerOne here so I could award a bounty for it:

Also worth noting is that Content Security Policy (T4340) would have prevented this. CSP is obviously worth implementing, but I believe the last attack it would have prevented was D4534 in January 2013, so it's hard to prioritize if it only defuses one attack every 3-4 years.

The Phacility cluster has been patched.

In the future, please report security issues via HackerOne:

Current task graph is great for visual representation... but can we get somewhere very simple list of blocks/blocked by?

T2637 cycles down to itself again

A few tasks (like T2637) are still drawing crazily enormous trees. I think our tasks are especially highly-connected and 97% of what I've looked at seems reasonable, so this might not be much of an issue for other installs, but I think we definitely need some kind of behavior where we hide the more distant parts of the tree once it gets too big.

I guess that after some exposure, it would be clear; If we're prioritizing experienced users over new ones, it's fine the way it is.