There was some unrelated discussion, but I think the original idea was to have a dashboard panel which is only this (panel on its own):

Dashboards need too much work to make this straightforward.

A treatment that might be nice is to add an "Events" sidebar panel, similar to the existing "Badges" panel. It could have a link to view their full (public) calendar (in the Calendar app), and show a quick view of current/upcoming events.

I think there may be a different/better fix to D13354, or maybe I'm not remembering why we made some decisions.

Hmm, odd. That definitely isn't the POST issue (although I suspect that may be an issue in some cases). The behavior will hopefully be more clear once master promotes, and definitely easier to debug. I'll dig into it a bit on my side in the meantime, I have a few ideas of things to try now. Thanks for your help!

Oh, I think I might know what's wrong. If you repeat the same process with a viewable file (like a JPEG or PNG) does that work?

Hmm, I'm not immediately sure -- that all looks correct on your side to me. Let me add some kind of basic LFS administration page that shows Phabricator's view of LFS objects in the repository -- hopefully that will shed some light on where things are breaking down.

That's probably (?) the repro.

Oh, I think I see.

You ran bin/storage upgrade?

Chrome is free to send more "If-Modified-Since" headers when you press reload than when you navigate. I have no idea what its exact behaviors are.

I can't reproduce that unless I actually use the "reload" command to reload the page, which looks like it makes Chrome dump caches on my system.

Those changes are live on this server now, let us know if you run into issues.

D15642 has additional details, but the new header/cache behavior is:

If someone wants to dig the original change out of the log and send me a revert, I'll upstream it. I think this behavior (30, 29, 28) is probably better in some sense, but the other behavior (1, 2, 3) is very likely better in terms of how many upstream bug reports it generates, and I have no qualms about shipping a worse product that I don't have to support as much.

On this:

D15641 has the technical details, but here's the behavior I've implemented:

If the unique url hash changed whenever the visibility policy changed, that would be fine.

Alright, a v0 of this is live here now -- "Move on Workboard" in the "Actions" menu above the comment box. This is a rough cut and we may not keep it in this form, but the infrastructure it needs is built now, at least.

ignore this - test

This no longer needs to wait for T5873, since enough of that has been sorted out in EditEngine and related work that it can move forward.

I think this is in good shape now, T9606 can track itself.

I think this is in good shape -- Herald is probably a ways out, and the only other chunk here is EditEngine which has a separate task (T9275).

/project/board/2/ always leads to the board and is the canonical URL.