See also T10215.

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/#hypotheticals

We just edited this ticket's information to test if we could indeed edit someone else's diff (don't worry - we changed it back).

Truly our most useful project.

Wait for it...

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.

Merging this over and re-opening.

No, no I can't. I can't make a Phriction Panel.

I might be able make a Phriction Panel

Some earlier discussion in T3612.

In T11250#183164, @epriestley wrote:

The downside of this was that it caused a flood of notifications to go to the supervisors

Could you do something like this?

• Create two projects, "Supervisors (Blocking)" and "Supervisors (Ready for Approval)".
• Supervisors are in both projects.
• Herald adds "Supervisors (Blocking)" as a blocking reviewer.
• Interns add "Supervisors (Ready for Approval)" as a reviewer once they're ready to complete the flow.
• If supervisors only want mail once things are ready, they can disable earlier mail in Supervisors (Blocking) → Members → Disable Mail.

Assuming your local tree looks like this:

[master] - last commit from master, has "old"
abc4321 - Add Hello
25ag344 - Add World

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.

It's clear enough to me that higher -> more parental. It might be nice to make T123 not a link and bold, like elsewhere, for easy copy-pasta.

Not a good idea, but an idea:

After looking through real-life applications, this now seems obvious and in @avivey example A is Parent of B. At first glance - there's relation. But yeah, arrows would help, only thing problematic is agreeing on arrow notation.

@avivey Do you have any ideas on how to make that more clear? I'm imagining it will probably be obvious on real data when you know what the tasks are and you'll get used to it pretty quickly, but maybe not.

This is now available as "Edit Parent Tasks".

We haven't seen more requests for this in nearly two years, and the use case isn't really clear to me since you've always been able to edit many dependencies at once from a task. After recent work in T4788, you can edit them in both directions, too.

We now render dependency graphs, as on this task:

From elsewhere, it would also be nice if this tokenizer highlighted instance members of instances associated with the billing account. There isn't a straightforward way to determine which "joe" or whatever is correct right now that works better than "ask Joe what his account name is".

Got it. Was able to get the desired result using the Conduit API web UI and the calls you mentioned.

oh man, I even filed it.

You can use project.edit to add members, roughly:

Any particular system this doesn't work on?

Quick follow-up.. Any thoughts on the most efficient way to do a bulk add-to-group since the only obvious way to add users is via the autocomplete box from the members page for a project?

News to me that we don't support it.

Cool -- I'd expect that to work in most situations. Let us know if you run into anything else weird.

Well, now I just feel dumb. Haha. Yes, I think that would probably work, and I feel silly for not thinking of it since it has how I have been managing other privileges (i.e. Queue Managers, User Managers, etc.) Thanks!

in first glance, I'm not sure if A depends on B or the other way around:

Affecting Wikimedia as well.

I might not have read things carefully enough, but can you just add all the FTEs to "#yesrepo" and then use a positive policy to control access to Diffusion?

Now it looks pretty and actually first glance tells something :)

Seems kinda good now? Could maybe use some style/layout tweaks on the table (I'd like resolved tasks to be more obvious, for example), but that graph seems like it's actually pretty good/useful to me at first glance. Need to poke around more.

wut

Woooo pretty pictures graph! Can't say I can deduct any task relationship from graph, but nevertheless, it's very pretty!

Looks like I didn't think that one through very well.

Nope, it's a hardcoded app right now, see T11217

Is this not a modularizable thing?

I'm pretty tempted to try using the "graph trace" interface to show task graphs. My major concern is that it task dependency graphs tend to be fairly wide and shallow (one task has many dependencies) while commit/revision graphs tend to be narrow and deep (long chains of dependencies). The element isn't as good at showing wide, shallow graphs. If a task has ten subtasks, we'll get a graph like this:

The downside of this was that it caused a flood of notifications to go to the supervisors

But the root problem is code reviews are getting accepted that shouldn't be, correct?