rCORE9d89c996844c4599afc1cec9454a71dd80a69c6c threw out the -o pipefail nonsense in CoreHostBackupWorkflow.

(I renamed the "Up for Grabs" column to "Ready", and kicked this out since it doesn't have detailed technical instructions that a new contributor could follow like the other tasks in that column do.)

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:

In general, please follow Contributing Feature Requests when filing feature requests. We have no plans to expand on tokens beyond T11217. They are a lighthearted and frivolous application. I'd recommend un-installing it if it is causing user confusion (you wouldn't be the first install to do so).

As I noted in T11217, this isn't exactly a duplicate. Tokens today are created with a class (tokens-coin-2 above) in their <span>. I don't see why title="Piece of Eight" couldn't also be added to that tag.

T12000 isn't really a duplicate. It's more of an enhancement for today's tokens. Of course, it'd be useful for this eventually, too, but that's tangential.

Token added for effect. ;)

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.

Which settings, in particular, are you seeing issues with? The correct answer is to fix them, not hack in something to work around them being broken.

the usecase is that if our administrator needs to change some configuration settings which may impact current login users, the idea is to perhaps have a mechanism for force a relogin so the setting takes affect. I accomplish by writing a cmdline application and querying the phabricator_session table to invalidate the user's session, it's not integrated into the phabricator UI, but work good enough for now.

@epriestley I can confirm it works fine both on Mac and Linux for me. Thanks a lot for the finding and quick fix!

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:

Chromez

@chad was that for me or for Chrome? 😄

@epriestley could it be related to this change? https://chromium.googlesource.com/chromium/src/+/a67debf9a9b78f60e7b10b5574ae4ceab49af31b%5E%21/#F2

Here's my reduced test case for Chome 55:

Hah, I was on Chrome 54, and my report above works. But after updating to 55, it no longer works. Something changed in Chrome. Not sure what though.

@chad I was replying but saw now your last comments, thanks @epriestley for narrowing it down. Interesting that I can repro on Chrome 55/Mac while you can't.

Basically, I've found:

Oh, it reproduces for me.

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

This doesn't reproduce for me on this install in Chrome 55/Mac, or any other browser. I'm assuming the issue you saw on this server was T11998 which was a local configuration issue.

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.

Our expectation building Phabricator is that it's easy and obvious to accomplish tasks. Where are you looking in Dashboards that you're not seeing how to accomplish this?

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.

We have an identical ticket we plan to fix, definitely agree it's a bad experience.

Okay then, I thought this was a bug as it didn't seem to make sense for me as a user. Sorry for taking up your time.

This is expected behavior. We want to show an error instead of just vanishing the widget.

@rscircus - this task (like I assume most tasks here) needs paid prioritization to move forward. see https://secure.phabricator.com/w/prioritization/

• 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.