When you're editing a homepage dashboard, just having a spacer bar there for the applications menu might help make it more clear that 66/33 is better in a lot of cases than 50/50 -- currently, you can't see what stuff will really look like until you're already done and installed.

wow pretty sure I even picked numbers that add up to 100%

I definitely think we should skip the 3-column versions for now, I don't think we've seen any kind of need for them in practice. We could look at it again after Facts since I think some of these weirder things could make more sense on standalone dashboards, the app just isn't powerful enough yet for that to be paritcularly useful.

Do you think 50/50 and 33/66 are always bad even for standalone (not-on-homepage) dashboards? e.g., if we had a "Phacility Metrics" dashboard in the future after Facts, a 50/50 of a "Users" column and "Revenue" column or whatever could never be a useful way to present the information?

Haha, that's probably T10612.

Why do you think installs (offhand: Babel, WMF) are picking 1/2 + 1/2 if they're strictly worse than 2/3 + 1/3?

You're the only user we're currently aware of who wants to use the software like this, so I don't plan to address this use case at this time.

But when I am looking at my calendar app, I want to see local times, for whatever timezone I am in.

they won't not exist

"Ignored" in the sense of: no publishing, no herald rules, no audit triggers. Not, like, "they won't not exist".

Only that any legitimate commits pushed until things catch up will also be ignored. The repository will automatically leave the mode once everything finishes.

There was a relatively recent change to make Phabricator discover commits which are only reachable from tags and refs. As it discovers these commits, it will treat them like new commits and publish feed stories about them. This is a one-time event, but a few installs have a lot of tag-reachable commits for whatever reason. You can find a bit more discussion in T11188, and details about the change in T9028 and T6878.

This doesn't appear to even to be possible in Firefox. Here's a simple example:

Oh, or Apache.

Also likely fixed by restarting PHP-FPM, that method is defined here:

Did you restart everything after upgrading? See Restarting Phabricator.

From the Firefox bug and this linked one:

This appears to be stable, and is now accounted for.

This seem quiet and is now accounted for.

This appears functional and is now accounted for.

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.