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.

See also T10215.

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

Truly our most useful project.

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.

Some earlier discussion in T3612.

@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".

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

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

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?

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.

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

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

Looks like it imported before I got to it. Still seeing an issue?

(I also added you to Community, granting you tremendous new power to tidy up around here.)

Ah! That makes sense. Originally we were more strict about which repositories we would update (which would have caught this) but this created some worse/more-confusing effects in the "enroll" direction (see T10940).

You can also check Request → Machine in DarkConsole to see which host served things, if the Load Balancer / web node thing might be part of the explanation.

(When I toggle between cluster/no-cluster locally with --service / --remove-service, everything appears to be working properly, although I didn't precisely reproduce your setup.)

Just to rule this out, are repo001 and repo002 also web nodes which may receive traffic directly? That is, could this be explained this way?

I think only frogs are allowed to be memes.

I wish :(

• 🐗 For when something is boring.

Thanks for the report! The primary issue should be resolved at HEAD of master, and promote to stable within about 48 hours.

In T11242#183007, @chad wrote:

{F1706803}

Several behaviors are interacting here. First, here's how MIME types work:

@csilvers, I think you ran into this too although I wasn't around at the time. Likely fixed in HEAD of master.