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.

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.

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

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

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

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:

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.

Since I typed up most of this anyway:

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

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:

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):

There's no pathway forward here without reproduction steps.

I think this use case (specifically, deploying working copies of a repository to a Phabricator host) is extremely unusual.

m8b

My plan forward is:

Presuming this is resolved, but let me know if I'm missing anything.

It's intentional that we don't support these because they appear frequently in expressions source code, for example:

well now

So these are all unreachable commits that have now been imported?

Are all of these events commits?

I explained this above, in T11187#181641.

See T3179.

No. Phabricator is explicitly designed to make it impossible to impersonate other users.

By design, it is not possible to impersonate other users over Conduit. There is no transaction you can construct which will list any user other than the authenticated user as the author.

When you apply a group of changes with a *.edit endpoint, they are all applied at once, as though you had submitted an "Edit" form or a comment with actions. In particular, this means:

We haven't seen any other users run into difficulty with this, but we'll keep an eye on it and consider updating the documentation if we see further confusion.

That also doesn't look like a working copy.

Great! Yeah, make sure to restart both after upgrading or you can be left running old code against a new schema, as here.

Working Copy: Path "/home/fl.blondeau/NetBeansProjects/namescan-phabricator" is not in any working copy.

Did you restart your webserver after updating? See Restarting Phabricator for help.

Can you try arc install-certificate --trace, and show me the output?

I pushed that junk here, yell if anyone catches issues.

I sure wrote some Javascript today

Cool. The expectation is that this won't happen again going forward (we should automatically compute reachability from here on out). Let us know if you see it again in the same repository. If we get a few more reports maybe I'll make the error message mention this command.

Try bin/repository mark-reachable rXYZ (and show me the output, maybe)?

Let me know if that doesn't fix things. Expected behavior is:

Thanks for all the help digging into this, there is pretty much zero chance I would have guessed that on my own. I think D16149 should fix this properly, I was able to reproduce a similar error once I knew what I was after.

Okay, I figured this out:

Thanks! Looks like we have things flipped for some reason. Let me see if if I can track that down. I think I should have a patch in an hour or so, or I'll let you know if I need anything else.

We should be able to parse any repository in any state, so don't delete the tag!

(I suspect v2.11.1 is a tag-object and the tag-hash and object-hash are getting mixed up somehow, but hopefully the full command will shed some light on things.)

Hrrm, I'm very confused by that behavior.