Okay, it does look invisible in Firefox. Is Firefox the browser you're using?

I can't reproduce tab order differing from visual order, either.

I can't reproduce this:

isn't that outline provided by the browser?

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.

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

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.

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.

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.

Your config looks very little like the config we recommend. Why are you using try_files instead of rewrite?

I upgraded my installation to

commit ad65d933fa75a2c417ba23f3684f0109de0f6ace
Merge: cfcc3b8 f0bf041
Author: epriestley <git@epriestley.com>
Date:   Sat Dec 3 02:39:57 2016 -0800

We use nginx:

1.open the app
2.go to the index
3.check the list

1.check the banner colur

check the home page, banner is missing.

zdfhcvbn
xcgjcvhjcvgjcvj

Can you show me:

The intended target of the link is Cluster: Databases.

Purely organizational. I don't believe there's anything technically that Phabricator can't do, but we're just trying it out and don't want to move everything over before we're ready to commit.

What are the barriers you face to hosting on Phabricator instead of on GitHub?

Sounds like this can safely be closed as PEBKAC

FWIW, in this particular case our repository is hosted on GitHub, so lovely automagic in Phabricator wouldn't solve my specific case.

Generally, I am leaning toward splitting the "Commit" rule into two rules, "Commit" and "Ref Update".

We have some spooky magic around "autoclose" which might make the behavior for "Is on autoclose branch" different than "Is on <specific, named branch>". That said, I'm not sure if it's actually materially different, and these likely end up being more-or-less the same thing when we actually fix them.

I think it is the same as T6522?

Oh, maybe this isn't quite the same as T6522. Pushing another commit to the branch probably fires the rule?

We also made some changes to this recently (D16936, D16983) and it could conceivably be a version issue, but neither of those changes replaced a static cache with a RequestCache or similar, and D16936 is correctly using the RequestCache (which is cleared when the taskmaster de-queues a new task).

I can't reproduce this in the Phacility cluster, either. Here's what I did:

Your logic there w/ dumping the prefs is definitely convincing. Perhaps I hallucinated this and it was actually that I did something in a different order, e.g. I disabled "A commit is created", then restarted the daemons, then disabled "A commit has auditors added" and misattributed causality (where the real issue was that disabling "A commit is created" is not sufficient to stop receiving emails when a commit is created that you're an auditor on).

I'm not immediately able to reproduce this. Here's what I did:

Why does the mail say you received it, see /mail/

We have updated to Git 2.11 and updated to master pull/push works for us. Thank you as always. :)

I believe this is now resolved at HEAD of master. Let us know if you're still seeing issues after updating.

I think we're currently consistent about showing updated date (Diffusion, Differential, Maniphest, Phriction index view).

This issue is now fixed in the Docker image, which now uses an older version of Git and checks to ensure that it does not install 2.11 when the image is being prepared. If you're affected by this issue, run docker pull hachque/phabricator.

Brilliant! As T11940 mentions, downgrading to git 2.10.2 fixes the problem. Thanks guys.

As above, we don't support installs that don't follow our guide.

Hi Chad, thanks for the quick response. That's unfortunate, I use to run setup using the "Installation Guide" a while back. That server died a few months ago and I decided to docker everything. My previous setup use to check for updates every 30 minutes and I never had any issues. Thus, I let this docker update every time it restarts, probably shouldn't have done that. :)

You're welcome to spin up a test instance on Phacility or do a installation from our guide, but we don't accept bug reports that include "use third party installer" to reproduce.

Sorry I accidentally hit Ctrl+Enter and submitted before completing the form