User Details
- User Since
- Nov 13 2016, 12:20 AM (416 w, 2 d)
- Availability
- Available
Jan 8 2020
Last follow-up -- no, it was not a custom policy. The log of changes to the Project configuration show that the original setting for the edit policy was indeed "Project Members", which seems to indicate that Phabricator was incorrectly preventing new members from editing the Project.
I was unable to reproduce this with a new Project, which makes me suspect the problem isn't a bug in Phabricator. I suspect the Project that was not editable *actually* had a Custom policy with specific users added to it, rather than a "Project Members" policy.
I ran into this issue today as well. The context was a Project created by a regular user a few months back. He added himself and one other user to the Project. He also set the edit policy for the Project to be "Project Members." A few months later, a couple of other users were added to the Project, but neither of them could edit the Project (all links in the "Manage" UI were disabled, can't create milestones, etc.). The users who were in the group when the edit policy was set were still able to manage the group. One of them had to change the edit policy because the newer members of the group could not.
Feb 17 2017
It is somewhat confusing to have both an SSH key access level that allows repo cloning and an arc certificate level of access that enables different features.
Ah, yes -- this is where I got off track. In my head I had conflated being able to clone the repo with having the arc certificate installed. These steps are unrelated, I understand clearly now. As long as the SSH key is added in Phabricator and the Repo is activated in Diffusion, cloning it is no problem. In this case, I thought it was the lack of arc certificate blocking me, when in was actually just that I forgot to activate the repo. Whoops. Thanks for clarifying.
Fwiw, if someone else lands here (which I just did by Googling the same error message), the problem for me was the same as for the original poster -- having not first initialized a repo locally one way or another. My intuition (which is probably wrong) is that there is an interesting order of operations problem here.