One other thing is that PhabricatorApplicationPolicyChangeTransaction->renderApplicationPolicy() has unconventional behaviors which are not very helpful and not consistent with normal CAN_EDIT / CAN_VIEW transactions. This is somewhat perplexing because ModularTransactions has renderPolicy() already, which has better behavior. I think it didn't exist yet when Applications modularized in D17757, and when it was introduced in D19829 I just overlooked the opportunity to update it.

In Applications → (Pick Something), if an application policy is set to "Custom Policy", the policy is not linked.

I upstreamed this to Chrome here: https://bugs.chromium.org/p/chromium/issues/detail?id=1003002

I understand this was supposed to be mentioned here: Herald ignores commits that are ancestors of permanent refs if they were previously pushed to some other non-permanent ref.

0.00000000001 is very funny and we would be losing a truly great joke at such a young age

Left Nav

There may also be no Application in contexts where we want to render a global search menu, notably the 404 page:

Vaguely adjacent:

Oops -- I think this is a reasonable fix, thanks!

assertWritable checks that the file exists and writable. There's assertWritableFile, but it's private, and it's being called anyway from setKeys.
This might be hiding some other strange conditions, but I couldn't think of any that don't end up just making the file un-writeable.

Now that we are on RDS I can confirm that MySQL also has ONLY_FULL_GROUP_BY enabled by default.