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

See T10978 also

I expect our forking to be much lighter-weight than GitHub's (ideally, I'd like it to work something like git push whatever/branch creates a fork called "whatever"), forking is just a familiar metaphor.

I love it it is very good

MANDATORY

Yeah, I don't particularly like "Global" (too technical) or "Favorites" (feels very Windows 98 to me: "My Documents", "My Computer" -- "Favorites" isn't as bad, but "My Thing" has always felt weirdly condescending to me).

Not a fan of "global" here. just.... technical.

In T11535, @samking says forking "seems like a fairly heavyweight solution," and that users don't want their own GH-style fork as much as they want to create branches "somewhere".

• H140
• {H140}
• H141
• H141 force chad

everything will be OK :)

this is all too complicated