There is definitely a bug here, I just have no idea what configuration of forms leads to it. @epriestley might have other guesses.

I'll wait Friday stable.... today I've switched from stable to master branch. The install is if I can say untouched and every Friday updated.
Just git pull in 3 dirs and that's all. Use well known bash script for that. All customization and setups are stored in SQL database.
What else steps to report - just pressing New task and appears that.
Is it an option to clean up folder and make clean git clone ?
If tomorrow stable don't resolve that nasty problem will proceed with clean install.

That is, the problem would be:

I guess we actually have to test this use case:

I can fix if it's one line, I just assumed it was something super hard with external urls or something.

I blame the fun police.

https://secure.phabricator.com/source/phabricator/browse/master/src/infrastructure/markup/PhabricatorMarkupEngine.php;4c7d464f8bf2627ef7455596fde2ae5667e67a57$356

Macros are disabled in Phame posts, via markup engine. This originated in D2202.

I think the way the view gets built is a little odd and I didn't get the logic quite right. Definitely a bug, thanks.

We'd want to know the root problem you're having with Phabricator specifically so that we could decide the best way to resolve the issue in the upstream. Can you go into more detail about the custom policies you're wanting to create, how often, what they do, etc?

Thanks, but we really just need the steps to reproduce the issue locally. I don't know them, I have no guesses as to how to get an installation to do that. Without knowing how to reproduce your bug specifically, we have no idea what to look for or if we're fixing the correct bug. This is a huge time burden for us, and is outside what we cover under "free support". We require every bug report to provide these steps for us, since Phabricator is a free product.

Ok, i'm an idiot.
I configured wrong endpoint.
It's working now.
Still, it might be good idea for mentioning this policy in install doc - it's not really obvious that you need

"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"

For IAM policy to work.

Probably worth mentioning that this creds are configured using IAM instead of root creds.
Policy for this user:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::files.example.com",
                "arn:aws:s3:::files.example.com/*"
            ]
        }
    ]
}

In T5029#210026, @bcooksley wrote:

@epriestley my apologies for this. I had sent out a memo previously asking for everyone to file tasks on our Phabricator so that I could co-ordinate things from there. It seems some folks have missed that, so i've now resent it to a wider audience.

Usual "here in my machine works fine".
Hereby is screenrecord to convince you
http://srecorder.com/s/3huk
Or just give a joker where to look after for raised flag of locked task or like that.

For anyone who doesn't want to wait for this to be implemented, here's a Tampermonkey script to do it: https://gist.github.com/lyahdav/30fabcfb2856a28d320114922c91a1e3

Cool, this would be great!

The general headers/sections are mostly scripted now so they should be fairly consistent, but I'm still editing the actual markup at the end of the day.

I'm good with the current balance of the changelogs - the one thing I think would be nifty is being able to accumulate the Upgrade/Compatibility sections across changelogs, for sites that aren't able to upgrade weekly. I was considering making a script to scrape that info but haven't had a chance to sit down for it. Also it'd be relying on the changelog format to be consistent (seems to be pretty darn consistent).

I think we currently get about equal amounts of "your changelogs should be more detailed" and "your changelogs have too much irrelevant stuff" feedback so I'll take that feedback under consideration but don't plan to make changes unless the overall balance of feedback shifts substantially in one direction.

We support viewerprojects() elsewhere but it isn't currently a component of the "Auditors" datasource. See also T9362#207080. I'll file a version of T9362 for the "Auditors" field.

More generally: I think your decision to not try to migrate saved queries makes a lot of sense. In lieu of that, I'd like to cast a vote for more prominent mention in the changelog. It would be great just to see a note that some queries would break and some hints on identifying and replacing/repairing the broken ones.

I've hit the same problem that @cspeckmim ran into. As best I can tell, in the new system there's no way to quite replicate the behaviour of the old 'needs' or 'problem' audit queries. The closest attempts I've come up with so far are:

• query for Audit Status = Audit Required/Needs Verification and Responsible Users = viewer(). But that includes results where the user is the diff author, not auditor.
• query for Audit Status = Audit Required/Needs Verification and Auditors = viewer(). But that misses results where user is a member of a package or project auditor.

I think this would work if I could query for Auditors = viewer()/projects(viewer())/packages(viewer()), but it seems the functions aren't composable (at least in the UI).

I tried removing white space: nowrap; (from one of .phabricator-action-view button.phabricator-action-view-item, .phabricator-action-view-item) in the browser inspector on FF and it looks like it goes back to normal (even when expanding).

Yeah Chrome is fine as well.

Do you have a rough suggestion on what to do with badges.search? Seems like noone would use these feature regardless.

I'm going to merge this into T5029. This is an extremely low priority for this upstream because this workflow is virtually unheard of among full-time software development professionals (see "Target Audience" in Contributing Feature Requests) because it is inherently error-prone.

How do you make guarantee that unrelated, simultaneous, uncommitted changes in the same working copy do not interfere with each other?

Maybe a better way to explain Phabricator's philosophy is that it's build on code quality. That is, if we have to equally choose between developer efficiency and code quality, code quality will win because we feel code quality leads to greater long-term efficiency. It means less likelihood of wasting reviewers time, or chasing bugs, or missing issues because of easily catchable programmatic mistakes. Is it a great workflow if you're just fixing a typo in a document file? Not at all. But 99% of revisions are not typo fixes. With a commit, we can run builds, show reviewers full context diffs, allow for arc to patch diffs, allow for chain of custody and so on.

How do you make guarantee that unrelated, simultaneous, uncommitted changes in the same working copy do not interfere with each other?

The problem to be solved is that workflows as I've tried to describe aren't possible. Workflows where there is no official policy that changes first have to be committed, signed off or whatever before they can be considered for inclusion upstream. Or if you want, workflows in a more relaxed community with smaller and larger contributions coming in from a wide variety of users and developers not all of whom are experts in using git, svn or what have you.

I guess this is pre pre-commit review?

We want to know the problem you feel that feature solves specifically, not just that you want it. You can run patches manually or run arc diff --preview to just preview changes. But offhand I don't see any workflow benefit to reviewing non committed changes and don't recall any requests for such a feature.

Sorry, the Root Problem was clear enough in my head but apparently not explicit enough in the OP. I hope to have addressed that now.

Please use Ponder or Conpherence if you have general questions about using Phabricator. If this is a feature request, it needs to state a root problem in order to be accepted. See Contributing Feature Requests and Describing Root Problems.

I've followed the steps you listed above but am not able to reproduce the issue. Do you have more information you can give us on how to reproduce the bug? Without reproduction steps the upstream cannot move forward.

Same problem here, any help?

Thank you for the very thorough reply.
That's not a big deal and it certainly can wait!

In our case these are commits from landed Differential diffs. Permissions
for the web user are there and correct, but I'm not sure I understand all
the details around the daemon vs. web user, and the daemon is doing the
work for this git commit parser.

Thank you for your quick reaction (and sorry that I didn't reply sooner). I think a black color with a 1px black text-shadow looks better. The blue is confusing (it sort of looks like a link).
So I suggest:

.phui-document-view .phabricator-remarkup .remarkup-header strong {
  color: #000000;
  text-shadow: 0 0 1px #000000;
}

I've implemented the sudo approach at some point - P2016 - and I think it worked alright.

mkdir: cannot create directory ‘/var/storage/3f/49’: Permission denied

I have to report a possible bug as asked in Q584.
Message for editing locked task when create new non-existing task:

... and then there was one ...

I haven't been able to reproduce this locally by artificially making services unavailable or connections fail. Debugging this in production will require momentary service interruptions on admin until I can narrow things down so I'm going to wait until off-peak to poke at it.