Can you browse to https://your.install.com/applications/view/PhabricatorFilesApplication/ and post a screenshot of the "Storage Engines" panel on that page? It should look a little bit like this (example from this install), although your settings are presumably different:

This doesn't seem to be going anywhere too fast so I'm just going to nuke it while I'm combing through old things rather than letting it collect dust forever.

We scored our first kill today. @dgdfgdg slipped through our defenses in his initial volley, but we reacted quickly and the system automatically deflected his second salvo.

T11957 is the modern followup for this.

At least in this use case, I believe things turned out alright without this policy.

It's critical that we are addressing specific, plausible threat scenarios when implementing security protocols. This task currently lacks such a scenario.

This is pretty old and doesn't meet the requirements of a modern feature request (notably, clear definition of a root problem). Feel free to file a new request if this is still an issue. Particularly helpful would be discussion of why editing the page to say "Go see <other page>" is insufficient.

This got done at some point, I believe, since we have an SPF record now.

• Over time, we've drained the swamp to some degree on the default home page, by moving toward more useful defaults.
• We implemented Dashboards. Although we'd like to improve them, they've allowed ambitious users to fix this themselves for some time.
• See T11957 and M1473 for modern followups with a more concrete plan to lay this to rest.
• See also T11132 for discussion of NUX-oriented changes, specifically.

This is a billion years old now -- see, e.g., T11954 for more modern work.

"Blame Revision" was a freeform text field at Facebook (from before DiffCamp, even) where you were ideally supposed to enter the revision or commit that introduced the bug you're fixing, if you were fixing a bug introduced by some known change.

That Chrome change seems at least plausible as a root cause to me, but I definitely don't know enough about the Chrome internals to really hazard a guess.

See also https://code.google.com/p/chromium/issues/detail?id=473657 for earlier adventures in Chrome.

Here's my upstream report:

Here's my reduced test case for Chome 55:

Oh, it reproduces for me.

This appears to be a bug in Chrome, because this fixes it:

Specifically, I resolved it by just pushing everything.

I think I had pushed new code to secure001 and then wandered off to do something else.

Oh, I think the edit to the title here is actually misleading, and the author in this scenario never used "Request Review" (this action is only available if the author has previously used "Plan Changes", which they did not appear to in this scenario).

I have a not-so-bad version of this in mind but it seems that the printer faxers are too terrified of our advanced defenses to even attack us any more.

• Systems integrated with Doorkeeper (JIRA, Asana, some prototype GitHub support) already get URIs marked up.
• The current JIRA integration does cover JIRA URIs in all remarkup systems, including Phriction and Maniphest, although you can not link to multiple JIRA installs until T6703, and you must use full URIs (if you use JIRA-123, it's possible that multiple linked installs have project namespaces called "JIRA"). It's possible we'll support this more naturally in the future, but not until after T6703, which is a very low priority.
• Custom markup rules already supported (see P1157, P1209 for some examples), although you're on your own to write them. These are probably the best fit for your use case.
• I believe needs for this sort of thing are often very specialized, so I do not currently plan to add any kind of generic, configurable remarkup rule that just matches arbitrary regexps against stuff and links them. You could write such a rule as an extension. One caveat to this is that we currently have bugtraq.url and bugtraq.logregex, which sort of work like this, except in a bad way. I'd like to remove them in the future, but there's an outside possibility that we'll replace them with a more flexible system like the one you describe.

Thanks!

Thanks! Yeah, this was just some editing/testing slop on my part. Your suggested fix is correct.

@chad, it looks like we're just using the browser's default outline for buttons.

Okay, it does look invisible in Firefox. Is Firefox the browser you're using?

I can't reproduce tab order differing from visual order, either.

I can't reproduce this:

I would remove the idea of a "global dashboard" as distinct from "top dashboard" -- we just look through both sections and pick the first dashboard we see, if any exist.

Also, maybe a good way to start is to do this:

(I guess a bad argument for having hard-coded home is that you can uninstall Dashboards. We could make it a mandatory app, though.)

That is, if you delete all of the dashboards from the menu that's fine, you just get hard-coded home.

Oh, my suggestion is this:

I think the short technical path forward is:

Well I'm planning to make you build everything so we can do whatever you want, pretty much.

If you are not an administrator and create a task with THE FAX SUPPORT NUMBER THAT SHALL NOT BE NAMED in the title or body, you will now be immediately logged out of all your sessions and your task will be quarantined.

Sorry, had to drop the pup off at pup daycare.

The solution that I think is most promising is this:

sorry phone

I don't think there's any reason that model can't work, it just feels really weird/inconsistent to me and not necessary, since I don't think there's any real value in retaining "install dashboard" or having a single magic home dashboard.

Also, is Dashboards going to get a second action so you have this choice when viewing a dashboard?

Okay, but I can end up with two different dashboard menu items which look the same, work the same, but are edited in completely different ways through entirely separate applications?

Also, if the user can't reorder, rename or remove Home, how do we figure out where it goes if they edit their menu and reorganize all the items (e.g., add three copies of their profile, all at the bottom of their favorites)?

If we retain "Install Dashboard", there are also two different ways to install a dashboard: to install a default dashboard, you go to Dashboards > blah blah > Install Dashboard. To install a second dashboard that you just want to be able to switch to, you go to "Customize Favorites > New Dashboard > ...". Seems potentially simpler to throw away "install dashboard" completely and just work like more like searches do.

If I install a custom personal dashboard, my personal dashboard becomes Home, replacing the existing "Home" link, and I can't get back to the global home?

I think we now test everything we've seen except RocketLoader (which is hard to test and hasn't come up too much recently) and not serving .whatever paths (which we've only ever seen one instance of, and which is also somewhat hard to test). I'm going to consider this resolved for now until we see more issues.

That's similar but not directly related.

(Since we no longer have labels, can users add labels if they want?)

So they can remove "Home" and have no way to return to the install's default dashboard, and everyone has their own personal copy of "Home"?

That's correct. I'm not sure what's going wrong. My guesses are the crazy stuff you might expect like:

If you have project "AAA" with milestone "BBB", which renders as "AAA (BBB)" in the UI:

Actually, I think the issue @jcox reported and the downstream issue (https://phabricator.wikimedia.org/T152726) may not quite be the same.

I'm going to close this as resolved because we now have a setup check for it and haven't seen any more Apache version issues since this report (more than two years).

I'm going to close this since it isn't reproducible (e.g., the link above works fine) and I'm fairly confident that this is a configuration problem in how you've adjusted nginx to work, deviating from the upstream instructions.

It's also safe to cherry-pick whatever D17012 lands as and then reindex to pick this up immediately without doing a full upgrade.

For best results (or maybe "any results"), run this command after upgrading past D17012:

The "Public" vs "All Users" stuff is sort of a confusing behavior on our part (the workflow is what set "Public", which doesn't really make sense given the rest of your config) but I think it's largely mooted by the fix in D17011, and to be more clear about it we'd have to make this one particular file magical somehow (we can't choose either "users" or "public" as the policy unambiguously, because the install may change the value of policy.allow-public later without also updating the logo).