Thanks, that helped.

Yes, this project has subproject.

You need to add members directly to subprojects. Parent projects are just the sums of all subproject members.

Is this a Parent Project you're trying to edit? That is, does the project has subprojects?

Can you show us a screenshot of the top section of the "Members" page for the project? It should look something like this:

i try do ./policy unlock PHID-PROJ-<hash>
all policy reset for all users but button "Add members" still inactive

I'm an admin

And what is your account?

./policy show PHID-PROJ-<hash>
OBJECT

What is the Join Policy of the project set to?

I want to add a new member

What specifically are you trying to do that needs fixing.

any ideas how i can fix this

Sorry i can't reproduce this bug now, but my phabricator regularly updated and we working in this project and the source of this bug may be earlier.

Bug reports must include reproduction steps. See Providing Reproduction Steps.

That last part which I just landed hasn't been vetted in production for very long yet, but I think this all works now.

D15990 removes the Lamson instructions from the documentation.

After D15989, this dialog should properly include information about tree hash and commit hash matches. It could still be more clear, but appears to at least be working as intended now.

Basically, the metadata is sufficient to generate the "Local Commits" table and little else.

The commits are not in Diffusion. Here's a real example of the metadata we store for a commit:

Got it, thanks for taking the time to explain. When you say "metadata" for the commits, do you mean the commits are also in Diffusion (even if invisible)? If so, wouldn't this behavior affect Herald / Harbor Master?

When you run arc diff, you provide (explicitly or implicitly) a commit range. Phabricator stores:

The expected behavior is that when we discover a new commit, we search for any open revision which has an active diff with a commit that has the same commit hash or tree hash as one of the discovered commits. In this case, it appears that this revision did.

Prior to D15987, the easiest fix for this was to add --force:

Here and in one other report, revisions which are closed by matching a commit or tree hash with a discovered commit are not explaining this in "Explain Why". "Explain Why" is expected to be able to provide details about this:

Here are the commit hash and tree hash of the commit:

At present, the only way to get around the problem is to ignore arcanist and push directly to git for the change that involves this problem.

Thanks works!
That was easy!
Unfortunately I was looking at Applications -> Config -> Projects

I had to make the admin omnipotent using this trick, but then it had trouble validating the CSRF token.

I am also facing same issue in a file. Can anyone suggest me the way to fix it?

Feel free to look at this information and anything else in the Hyper instance you need to.

Is it OK if I look at some of the data on your instance to diagnose this? I expect to look at this information:

Every task here has the latest progress / information already. There isn't a second task tracker, we develop in the open.

Hi @chad & @joshuaspence Any progress on this bug?

I tried yesterday, with phd restart and it doesn't work. it restarted the daemon, but on web the issue still exists. Then I restart the whole server and the problem is still the same. Today when I wake up, I restart the server again. Magically the problem solved. I don't know what's happening here but I will close this question for now. Thanks avivey for your help here.

Sorry, meant OAuth support instead of OpenID. The gist of it was delegate authentication to a dedicated system. Be it via OpenID, OAuth, SAML, etc.

You can use 'phd restart' to stop all daemons before starting new daemons.

This is strange. After you mentioned daemon, I log into the admin account and see an issue about daemons not running. However, when I ssh to server and run the demon, it told me that demon is already running...

Are your daemons running? That will explain the part about "not closing revisions", and it might also effect the lint/unit "run" not being complete.

I can't reproduce this; I've used conduit to add the "Conduit" project to this task:

Phabricator also does not support OpenID and we specifically declined to support it in T524#35252.

In T8787#177689, @siepkes wrote:

My 2 cents; I wouldn't spent too much time on implementing various authentication schemes for Phabricator like Yubikey, U2F, password with SMS or whatever flavour of authentication comes out tomorrow. Since Phabricator supports OpenID such authentication schemes can easily be delegated to IAM solutions like GLUU, OpenAM, KeyCloak, etc.

Now it might be a good idea to make a tutorial showing how to install KeyCloak with Phabricator to get U2F support but actually trying to be an IAM seems like a waste of time and duplication of effort.

Problem solved, the fix is the index: emails[0]

Look this:

I don't know anything about writing JavaScript or JSON, but my guess would be to just drop ownerPHID key from that array, and just pass the PHID?

Why is ownerPHID in your query if you're trying to pull by authorPHID? Have you tried the conduit console to validate queries?

Closed question.

My 2 cents; I wouldn't spent too much time on implementing various authentication schemes for Phabricator like Yubikey, U2F, password with SMS or whatever flavour of authentication comes out tomorrow. Since Phabricator supports OpenID such authentication schemes can easily be delegated to IAM solutions like GLUU, OpenAM, KeyCloak, etc.

I think it may be reasonable to allow users to resign from reviews they are only indirect reviewers for, but wouldn't pursue this until after T10967.

Sounds good to me. Thanks!