This isn't an actionable bug report because it doesn't include reproduction instructions. Reports MUST include reproduction instructions; see Contributing Bug Reports and Providing Reproduction Steps.

Nevertheless, I'm still not sure how to debug this error message / my configuration.
Is there a way to test/run the Drydock Host Blueprint and get more information than the command failed?

I would say, definitively. 'xxxxx' looks more like a placeholder for me, but that might be a personal preference.

If we masked with ***** instead of xxxxx, do you think that would have been more intuitive?

I am also affected. Is there any known workaround?

So, the information is just masked but really present in the real command call? The ssh man-page states what the options before the xxxxxs mean, I'm just not sure if the call is right when the information is masked. E.g. the clone call...does phabricator call with git@phabricator... or with the username provided for the ssh connection. anyway. Is there a log where the real command is written? Why is it even masked here?

the -l xxxxx is your configured SSH user, the -i xxxxx is the path to your configured SSH private key (it's written out to a temporary file).

Bug reports MUST include reproduction steps that allow us to reproduce the issue locally. Without this information, we can not move forward.

Bug reports MUST include reproduction steps that allow us to reproduce the issue locally. Without this information, we can not move forward.

Some more info I dug up:

• There are 2 commits that appear to have flipped comments, i.e. the comments that appear on audit1 actually apply to audit2 and vice versa.
• These commits are sequential and were pushed simultaneously (i.e. the author made multiple commits on master locally before git pushing them all)
• In both cases only comments made by the author appear out of place.

I think it starts out as a URL, and then replaced on the client-side with the name after some AJAX. Most of the time I don't have time to see the "before" text.

I don't understand why it's a tag. Does the JIRA link look like a URL or an actual name?

css is it's own world of magick.

I'm faking my way through it.

Here's Chrome's Style page for the element:

I'm just surprised to hear something is still overflowing after D16081.

DoorkeeperTagView is also used for DifferentialAsanaRepresentationField, which is probably easier to set up (?).

The value is rendered here: https://secure.phabricator.com/diffusion/P/browse/master/src/applications/differential/customfield/DifferentialJIRAIssuesField.php;70463e8a16d4cbe0c83b23b9328c4a359072c506$53

I'd need to see it to fix it. These are tags?

Alright, thanks for clearing it up, and sorry for calling it a bug :) I am new to phabricator, trying to see if I can configure it for my needs where permissions have a big role. Maybe I should explain what I am trying to do, so my request maybe makes more sense. You are of course welcome to close this task as wontfix, I just, as a new user, found it confusing that the edit policy wasn't strictly enforced around the application, view policy seems more strict though, which is nice :)

I have a somewhat similar problem when I try to start a working copy job:

There are many situations where you can make an edit in one way but not in another. For example, you can't edit the subscribers for a task via "Edit Task" on the detail page, workboards, or task list, or via the API, or via mail commands but you can edit them via "Subscribe", "Unsubscribe", with Herald, by commenting with @username, or via the action dropdown.

Thanks for the quick reply.

This is expected. You do not need "edit" permission to comment on a task, subscribe to it, award it tokens, or take other actions available in the action dropdown.

Assume you are testing. Please use http://phacility.com if you want to try Phabricator at no cost. This is a working installation.

This issue is not always reproducible but happens very frequently:

Updating Phabricator is required before submitting a bug report.

I've applied the patch and updated by URI accordingly (removed the ssh config as well) - seems to work

Yes, put the port in the URI like a normal URI (host.com:1234).

I'm willing to give it a go, just to confirm before I do that what my URI would be in the UI?

svn+ssh://svn.host.name:port/srv/repo/url/path/

If you have time, can you let me know if this patch fixes things?

I'm just going to merge this into T5953. The LDAP importer is a contributed patch from yesteryear which we wouldn't bring upstream today, and unlikely to see improvements outside of a more formal upstream effort in T5953.

git blame suggests that this hasn't ever matched on word boundaries (it didn't in August 2012, when it was first written -- see rPHU45f7bd6a).

I can't reproduce this on the linked install or locally either; presuming we fixed it at some point.

We haven't seen other users encounter difficulty with this, and the error message is relatively specific already.

This is sort of resolved since Diffusion moved to PHUITwoColumnView and project tags are now listed in the sidebar, labeled "Tags", while VCS tags are listed in the main list, also labeled "Tags". Labeling them both "tags" isn't great, but context provides some help and this doesn't immediately appear to be particularly confusing.

When we destroy an object, we load all its edges and destroy them too.

The repository created last year.

I am running Phabricator up to date (I upgrade it today, using git pull --rebase)

Edge Constant 39 was TYPE_OBJECT_USES_CREDENTIAL, which was removed a few months back.

What are the steps to reproduce the error, specifically? I can't trigger this exception.

Sorry for the disruption.

Should probably be fixed once D16170 is deployed...

Thanks. D16167 should hide this and the similar HTTP/HTTPS check for unapproved, disabled, unverified, etc., users, who can't act on them.

Thanks! That is exactly what we had, and I was not aware of it. And yes, we have this on purpose because of there being a load balancing (trusted) proxy in front of Phabricator. For whatever reason, I assumed Phabricator had it's own X-Forwarded-For handling. Mainly my mistake here was jumping to the assumption that Phabricator was looking at X-Forwarded-For based on the value - even though the error message never indicated that it was.

Since I typed up most of this anyway:

Closed as "invalid". I apologize for the noise. This was an undocumented Twitter specific patch.

this is a rather minor nit, but figured I should report it regardless.