That's similar but not directly related.

Thanks for pointing me in the right direction -- this was indeed pilot error. Switching to rewrite as stated in the install guide fixes the error.

(Since we no longer have labels, can users add labels if they want?)

So they can remove "Home" and have no way to return to the install's default dashboard, and everyone has their own personal copy of "Home"?

Home is Home, whether it's hardcoded or a dashboard. Maybe don't allow them to remove that? But I don't care if they remove the Profile Photo/Name panel or divider.

In all cases, we have no LABEL anymore

User default menu would be like:

This is the view when you first log in.

Getting another instance of what looks to be a similar issue but for a different function, specifically

That's correct. I'm not sure what's going wrong. My guesses are the crazy stuff you might expect like:

If you have project "AAA" with milestone "BBB", which renders as "AAA (BBB)" in the UI:

Re-applied the scripts and all is well now. Once another SQL script comes into the stable branch I will run the upgrade again, something must still be off here. For reference, after a pull, daemon stop, etc. we are only running storage upgrade --force -- is this incorrect? Seems to be fine in our other instances, but for this one the scripts are being marked as applied, but they aren't.

Actually, I think the issue @jcox reported and the downstream issue (https://phabricator.wikimedia.org/T152726) may not quite be the same.

I'm going to close this as resolved because we now have a setup check for it and haven't seen any more Apache version issues since this report (more than two years).

I'm going to close this since it isn't reproducible (e.g., the link above works fine) and I'm fairly confident that this is a configuration problem in how you've adjusted nginx to work, deviating from the upstream instructions.

It's also safe to cherry-pick whatever D17012 lands as and then reindex to pick this up immediately without doing a full upgrade.

For best results (or maybe "any results"), run this command after upgrading past D17012:

The "Public" vs "All Users" stuff is sort of a confusing behavior on our part (the workflow is what set "Public", which doesn't really make sense given the rest of your config) but I think it's largely mooted by the fix in D17011, and to be more clear about it we'd have to make this one particular file magical somehow (we can't choose either "users" or "public" as the policy unambiguously, because the install may change the value of policy.allow-public later without also updating the logo).

Oh. No - no it doesn't.

No problem -- we gave you a false start in Q528 and this behavior is pretty hard to guess at if you don't know the internals.

OK, after removing the custom logo (even though it's Public) I can't replicate any more.

Same file.

Specifically, this is the PHID you're looking for in the UI:

If you do this:

Well, the fact that the logo isn't restricted:

When you say "fail hard", you specifically mean that you get an exception message beginning with this text?

Um. That's a different bug to the one I'm reporting. The custom logo I have set is visible to Public.

(Actually, I'm just going to respect the file policy but ignore policy failures.)

Here are more reliable reproduction steps:

Ick. I could replicate it three times with those steps (without typing into the comment box - only a click; I need to check what happens with typing). I wonder if it needs a service restart somewhere in the mix (my update script is in Q528). Let me do some more testing.

I can't reproduce this. Here's what I did:

I'm going to attempt to reproduce this as written, but I will be shocked if these steps work to reproduce the issue you describe.

This search UI also needs to be updated:

My only (mild) concern with this is that object types may become slightly ambiguous in some contexts: currently, icons are (at least mostly) unique across object types. A tag icon or a briefcase icon is always a project. A calendar icon or a cocktail glass is always an event.

Does an administrator have two "Customize Menu..." links? Or does their link at the top also let them customize the global stuff?

I'm probably going to change this to repository and accept an ID, PHID, short name, or callsign, as all the Phabricator-side web/CLI stuff now does.

Richer integration would likely happen sooner than something like this, simply because it's something we frequently get asked for and benefits a large group of installs.

I updated the summary to hopefully make the problem description more clear, and to add an additional problem which I encountered on one vendor's custom made bug tracker, where their search was returning URLs that were only temporarily valid in the session that the search was done in.

Can you please check out Contributing Feature Requests and Describing Root Problems. We don't accept feature requests of this nature unfortunately without understanding the core problem. For example, external systems in the future could be fully integrated automatically with Phabricator, and make the need for special Remarkup pointless. We're not interested in things that are hypothetically cool or useful, and don't have the bandwidth to pursue specialized requests that can already be accomplished with a small plugin.

You can do this yourself today with a Remarkup Extension. Parse specific URL patterns in remarkup and return them looking however you want.

Did I get all the concerns covered here?

Did I really start this project in February?

You can use bin/storage upgrade --apply phabricator:2016... to reapply a specific patch explicitly, even if it has previously been marked as applied. You can get the full names of patches from bin/storage status.

While Changes doesn't list any caveats in the readme for https://github.com/dropbox/phabricator-changes, the readme for Changes itself seems to indicate that it's dead:

BTW its probably time to make it 5.0, not 2.0