This hasn't moved forward in a year so I'm just going to close it. We've removed header text in the latest UI iteration, too, and I imagine the button will be replaced completely with universal send-on-enter before long.

Although it's still a little early to be sure, we appear to have fixed the policy issue with unit test failures (D17029). Not sure if that actually impacted this or not.

My dashboard changed at some point and no one else seems to care, so let's wait for this to be more than an @epriestley-problem.

D17037 should fix the documentation, it definitely wasn't very clear as written. That should land some time today and the docs should be updated in about 24 hours.

In the first row of that table, it appears that you have configured a storage.mysql-engine.max-size of 8 ("8 bytes"). Try using 8388608 ("8 megabytes") instead?

If you want to come up with a specific list of domains I'm happy to buy them, but there are many hundreds of domains which differ from phacility.com by only one keystroke and buying hundreds of domains isn't cheap in terms of the amount of work I have to do to do it.

I can find this task by searching for "あああああ" so the CJK stuff may not really be much of an issue anymore? Maybe just an issue with Chinese because the index doesn't know how to tokenize words?

At least today, our error rate on this seems so low that it probably isn't worth implementing. We could take another look at it if we see more of it in the future (perhaps after we begin encouraging application development), but we haven't seen more of this that I can recall recently.

Paste now shows "Old", "New" and "Diff", so you can copy/paste from "Old" to revert. Not perfect, but I think this arises relatively rarely. See T11881 for a followup.

This is extremely old and it's not clear to me which bad cases remain -- I can't immediately find any by fiddling. If any do remain, they haven't turned up again in about two years. If you're still seeing issues, feel free to file a new task with a modern test case.

This picked up a few options through engine support and T11957 is adding some more. Particularly, default view is now "Authored" which I think resolves the original issue. I think the more-root problem is "Dashboards are kind of weird with all the panel copying", which is something we're aware of.

I am very sorry I am declaring t-shirt bankruptcy because I have learned it takes me over five hundred years to ship a t-shirt.

At some point after we get this working for Home, I want to replace the "Quick Create" menu with a similar customizable profile menu, resolving T5867.

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:

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.