I poked at it a little bit but only got this far:

We can just replace ui.custom-header with two separate options I guess and put deprecation guidance in the old option.

(And no matter what the policy is, this allows attackers to compromise a support account and then strip MFA from a "better" account, upgrading access.)

In the general case, as with the upstream cluster (T7639) I think the quorum thing in T9515 that @eadler mentions is the most promising way forward to reduce MFA support costs. Briefly, it would work like this:

Month view in desktop mode should be flush with box?

Upgrade.

It's intentional that you can not see information about tasks you don't have permission to see.

https://secure.phabricator.com/book/phabricator/article/spaces/

Calendar needs design work after intervening redesigns, but the views have been responsive for some time.

calendar.event.search is still pretty useless/bare-bones (you don't get very much information back), but we can expand that as use cases arise. We don't have specific needs for this yet.

T8267 briefly discussed the idea of automatically selecting an icon if one isn't provided.

Currently, there's no way to create an event without explicitly selecting an icon, so there's no way to really implement this.

This UI needs some cleanup in all browsers after some intervening redesign, but I don't see anything specifically wrong about it in Firefox at HEAD of master.

I'm just going to close this:

We can revisit this later if use cases develop, but we haven't seen any need for it yet.

This is on EditEngine + Modular Transactions now. There are probably still some remaining issues I didn't catch.

I've marked D16287 as fixing this, although it does not fix Countdown (today, only Calendar has the new behavior).

(Presuming that fixed things until we see evidence otherwise.)

Specifically, this should be resolved by D16242 (July 6).

T11319#185560 has some additional discussion about somewhat-related-ish issues.

It might be reasonable to un-pht() the field names in the short term until this gets solved for real, although it would be nice to see a use case with a legitimate translation rather than Pirate.

This is sort of very vaguely related to T5586, although I don't know if the fix will end up being the same or not.

Alright, that's promising at least. Thanks for testing!

We could also possibly just drop these commit mails in all cases where no audit triggered. It's easy to write a Herald rule to restore them if you do want them. Possibly involved enough to be adjacent to T10978, though.

A small part of the motivation for this change was to make commits reachable only from Gerrit magic refs (refs/changes/..., similar to refs/pull/...) visible in Diffusion. This didn't really make it into a single upstream task I think, but some of this is scattered across T9726 / T6878. So we have at least one use case where users want these refs to exist and be treated roughly like they were tags/branches.

I do think there is significant room to improve the behavior of arc diff (roughly captured in T6072) but I'm ultimately not sure how to improve this situation:

Yes, writing "Depends On" in a commit message or editing "Edit Parent Revisions" or "Edit Child Revisions" in the web UI should never affect what is shown in Differential. If you can reproduce this, this is a bug which we'll fix.

Please see Planning for information on timelines.

Some kind of ghost would be good too, but not too snapchat-ey.

All files from before you upgrade to D16270 are haunted and subject to ghastly behavior.

D16271 probably either fixes or moots this.