Haven't seen issues; now accounted for.

The upstream part of this is working in production, and this is now accounted for.

We haven't seen issues with this and it's now accounted for (I believe it's also in production).

A substantial number of users have linked Google accounts in production and we haven't heard about any issues, so I think that aspect of things is in good shape.

This is accounted for and we haven't run into any issues upstream with it in production after using it for about two weeks, but let us know if anyone runs into issues deploying it.

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.

Instances currently have two capabilities:

The Phacility cluster has been patched.

In the future, please report security issues via HackerOne:

This is impossible.

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

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!