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.

I have no plans to support that in the upstream. Running commands on the Phabricator host is a very unusual use case, and it would allow anyone who can write a Herald rule to write one that runs rm -rf / or compromises the Phabricator install by reading session keys out of MySQL.

Hi Evan!

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

See D10391

@witrin Thanks for that contribution! I really need this.
I tried to set this up but I got the followeing error:

Additionally, you should use maniphest.edit, not maniphest.update.

Also, for clarification, "Administrators" on Phabricator are just regular users as far as policies go. They don't override them.

Closing for lack of feedback. If you're able to update your install and provide this task with a set of reproducible steps, we can look into it further.

This issue is not always reproducible but happens very frequently:

Updating Phabricator is required before submitting a bug report.

Yeah, I think you can just do a SQL migration like:

User enters full URI (protocol + domain + optional port), like https://blog.phacility.com/ (UI is basically the same as it is now -- they still enter one value, it just has protocol + port now).

In T9640#172158, @chad wrote:

I'll fire up a VM this weekend and see if there are any issues.

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

So what exactly do you need to comment out for this to work on PHP7? Is is src/applications/cache/spec/PhabricatorDataCacheSpec.php and src/applications/cache/spec/PhabricatorOpcodeCacheSpec.php

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 think the root of this is largely building a commit mapping from "draft" commits to their equivalent "published" commits. I believe all of the approaches available to us are:

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.

This install now exposes two separate actions in a new submenu, although the backend is only sort of halfway converted. My plan is:

Thank you Evan for your ansewer!

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...

Here's what I'm thinking here:

• Add lint/unit/coverage "summary" field to each Build.
• Recalculate whenever new lint/unit objects show up (Possibly offline via daemon).
• arc-side lint/unit already generates a Build, so this one will hold the --nolint/--nounit information (+ excuse?)
• Anywhere we currently show that information, load the summary information and aggregate that, instead of aggregating all lints/units directly.

The UI stuff seems to be figured out so I'm going to call this done this continue work in T4788.

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.

I believe D16166 resolves this. See T11179 and T4788 for followups.

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

Yeah, this is a little obscure since I was trying not to build more than we needed. The URI comes from DiffusionRepositoryManagementPanel->newEditEnginePage(), which does this:

I dinked around on this but for the life of me, can't find where it's getting the URI from. I did learn how paging works in EditEngine though.

Thanks!

Follow the instructions in Restarting Phabricator.

Offhand, I'm surprised by this. I expect LFS smudging to be a side effect of git checkout and for all Drydock working copy construction pathways to invoke git checkout. This appears consistent with advice from the LFS upstream (albeit a year or so old):