To restrict add/remove users to one person:

• Set the "Can Edit" policy to just that person.
• Check the "Prevent members from leaving this project." box.

There is no way to prevent the user themselves from leaving the project. Since they can edit the project, they could change the setting that prevented them from leaving, then leave.

This is mostly possible today by

• setting the edit policy to "project administrator(s)"
• setting the join policy to "no one".
• ...locking the project (which prevents people from leaving), though this person could still leave if they want to since they "can edit" the project, including the membership

Its not clear to me what the value is in preventing this person from leaving? (Which is to say, the scenario(s) under which they are accidentally leaving aren't clear to me?)

@btrahan's answer is more complete than mine, I omitted setting "Joinable By".

Using the "editable by" policy does achieve the desired effect of having a "project admin", sorry I was not aware that it could work in this way.

So, the person should be prevented from leaving the project if the project visibility would prevent them from viewing the project after leaving.

For example,

• I created GreatestProjectThisSideOfTheMississippi,
• made myself the only person who could edit the project
• changed visibility to only project members,
• and then left the project.

Now, I can no longer join the GreatestProjectThisSideOfTheMississippi, because I cannot view it. Additionally, other members would not be able to add me back to the project, because I am the only person who can edit the project.

Is this making sense?

Because policies can be complex, we can't always prevent mistakes like that. For example, a policy may depend on some external source of truth, which changes independent of any actions in Phabricator and accidentally locks everyone out of an object.

If you accidentally lock everyone out of something, you can use bin/policy unlock to force the policies open, then fix them.

In practice, this seems very rare and I think we've only seen 1-2 people ever make this mistake.

I'm not sure what external sources are used, but I understand the concept.

From my limited understanding, it certainly appears that you've made some effort to ensure policies cannot be set in an inconsistent manner; I'm not understanding why it wouldn't be worth adding this check to whatever other validations exist.

It's normal/expected to sometimes leave projects and be unable to see them afterward. For instance, if you're on the "Security" team and then you switch teams internally and join the "Frontend" team, you might leave the "Security" project. That might prevent you from seeing it anymore, but that's fine, and you expected that to happen when you left the project.

We could warn you about this (e.g., "Are you sure you want to leave this project? You won't be able to see it after you leave."), although this is somewhat difficult to evaluate and may be impossible to evaluate in practice. However, we haven't seen users actually make this mistake in the wild, so we currently believe that it is very rare for users to make this mistake (and perhaps they never make this mistake) and not important to add additional checks to prevent.

If we heard from several users that they'd made this mistake and found the workflow confusing, we'd ask them what they expected to happen and take more steps to make sure the action was intentional or the workflow was more clear based on their feedback.

The workflow also fails closed (i.e., puts the application into a state where there is too little access rather than too much) and bin/policy unlock allows the mistake to be fixed relatively easily, both of which serve to reduce the importance of preventing mistakes like this. But the major issue is just that we've seen very few users make mistakes that involve locking themselves out of objects they intended to retain access to.