Another 2c for the piggy bank. As someone that quite likes the majority of the 'non-serious mode' text, "clowncopterize" feels just a step too far. I can explain weird names to new people, I can link them to a guide, but "clowncopterize" still gives most people, including myself despite using and even advocating the use of Phabricator to others for some time, too much pause for thought. Its not the content as much as it is the jarring level of 'non-sequitur' it may as well say "By this time, my lungs were aching for air" for all it relates to the action that it performs. If it has to come back, at least give me some way to turn it off without throwing away all the other stuff by turning on serious business mode.

Here's another...

Also just seen this:

Hi, I've accidentally fixed it. I needed to copy some tickets across from the defunct system to our new live system, so I did:

Hi, I think I find the cause.

os/php ?

It works well on this site... There must be something strange on my own install...

I opened policy up on https://secure.phabricator.com/project/view/1411/ for testing.

I still can't reproduce the error. And it happens on this install for you as well?

Here is a screen record.

Just a heads up, this looks to be resolved. I've changed all the projects to only have future-valid hashtags, which usually involves my renaming the project to remove the [ ], and then, renaming it back, thereby forcing the automatic hashtag to regenerate properly.

I'll chime in with my 2c as well, the new "Set Sail For Adventure" button in Maniphest was also a bit confusing to me and another member of my team, and we're usually fans of the flavor and have pushed to keep it instead of switching over to serious_business.

This is the policy on the IAM user:

Sorry, made this on accident testing out the api, and I can't close it :(

Ok, I've reverted our prod system to last night's snapshots of mysql + root disk and it is back to working again (with zero changes in AWS).

Update: I freshly reinstalled Phabricator on Ubuntu 14.04, and couldn't reproduce this... but between the three instances there's very little in common. I'd never enabled Almanac stuff before on my other instance, and never on Haskell.org, but those exhibit this bug. A fresh install does not seem to, and there doesn't seem to be a stack trace.

In T10219#155678, @epriestley wrote:

Can you give me an example of a rule which is sometimes wrong and where the implied patch is not obvious from the rule name?

Can you give me an example of a rule which is sometimes wrong and where the implied patch is not obvious from the rule name?

It may also be useful to run arc unit --everything in libphutil/, as that will trigger a number of signature-related test cases.

We had to downgrade libphutil+phabricator to get it working again, so they're currently on the commit immediately prior to the v4 stuff.

PhabricatorEmbedFileRemarkupRule has the "correct" solution for this problem, via a chain of permissions grants tied together with KEY_EMBED_FILE_PHIDS. This will grant the file the same permissions as the relevant object (e.g., the task or whatever).

I understand this is not supported, thought I would document this scenario I came across.

Broadly, here's a command string (with live, active credentials) which works for me to put data into an eu-west-1 bucket:

I can't reproduce this. Before we move further, it looks like libphutil may be out of date?

We are too; that's expected to work correctly.

Oh, we're authenticating using an accesskey/secretkey for an IAM user, if that makes a difference.

Thanks. I'll bring up a eu-west-1 bucket and see if I can reproduce this.

Hi, here you go:

Can you show me the output of this command on your system?

Can you make a movie or give screenshots of where you are clicking?

At least some of these were likely T10214. I'm just going to merge this there until more evidence crops up.

I also can't reproduce this here or locally. I tried several different projects, and tried users with and without permission to edit the menu.

This should be resolved by D15112. I've made a note in T9789 to catch this class of issue sooner before we make the consequences more dire by pursuing changes planned there.

I'm at version a9e2e6c5aab94c8f4c57797ac63bfd88955a630d and php-fpm restarted after upgrading.
I don't have any editing permission on this install obviously, but the reproduce steps are the same. I see a 404 Not Found error on page after clicking "Edit Menu" rather than anything else.

I can't reproduce anything based on the steps you've provided here. Here's what I did on this install:

Thanks - that's all useful information. This is a long-term aspiration, rather than a short term goal. I'll keep an eye on the importing task, and maybe in the future we'll look into it again.

The only issue that I've noticed so far is that @{article: triggers the autocomplete, whereas it probably should not.

After D15105:

This looks like a known issue with implementors using NSS instead of OpenSSL. Here's the Red Hat bug:

I'm using CentOS 6.7. I could reproduce the problem on 3 centos servers.
Debian seems to work fine.