Comment 12 for bug 1630728

I'll write up something more detailed to try steering toward a proper solution. But in the meantime...

If you want to temporarily activate/enable and deactivate/disable users -- as in the earlier example of a contractor -- use the juju dis/enable-user commands.

$ juju disable-user jjam
User "jjam" disabled
$ juju enable-user jjam
User "jjam" disabled

As noted previously in this thread remove-user archives a user permanently, never to be revived. The short answer to why is auditing. The longer answer is that the user name is the user id. That user id/name is used in the key for other items. We don't destroy or change owner when we remove a user so we don't want to create a new user that would then have access to things the previous user of the same name had access too.

I agree that users and authn/z should be overhauled, but that is a larger coversation. In the mean time I'll take a stab at making the confirmation text much more explicit (e.g. disable vs. remove) and the error more appropriate (e.g. username not available). Similarly in Paul's case the errors should note the user is gone/unavailable not "user already exists".

On develop, I don't see an error after confirming I want to remove a user. That does look like a bug if it is happening.