critic
critic copied to clipboard
criticctl deluser doesn't work
Output from a test of adding, removing, and then adding the same user again.
criticctl adduser --name test --email [email protected] --fullname Test --password changeme
test: user added
criticctl deluser --name test
test: user retired
criticctl adduser --name test --email [email protected] --fullname Test --password changeme
test: user exists
It doesn't delete users, it marks them as retired (as the output suggests,) and is thus rather poorly named.
Actually deleting a user require quite a bit more work, in particular if the user ever did anything, since it wouldn't be a good idea to delete reviews and comments and stuff.
Aha. My intended usage was to remove a user that I had added with the wrong username. Adding a new user with the same e-mail will fail in that situation (e-mail address should be unique). It makes sense to just retire rather than deleting in any "real life" situation.
The docs and command-line help do say "retired" rather than deleted, and the docs are pretty explicit about what the command does and doesn't do. It might make sense to add something more to the output of "criticctl --help" though?
Feel free to close this if you're happy with the current behavior.
In a somewhat related issue, I just noticed that my admin account and my own account manage to share an e-mail address with no complaints from criticctl. Is that intentional, or did I stumble on a potential can of worms?
It's only the git emails that are (currently) required to be unique on master, but that was in fact fixed on the r/jl/external-authentication branch recently (still not merged); on that branch you can retire a user with [email protected] and the add a new user with that same email.
I'm not happy with the current "criticctl deluser" behavior, so we could keep this issue open as a reminder.
I think at least these operations on a user should be supported:
- Retiring, as today, which pretty much just sets a flag and stops sending emails to the user, and adds some UI signals that the user is in fact retired.
- Deleting, which frees up the username for reuse, hides all details about the user from other (non-administrator) users, but keeps the user record itself, and the information, so that existing reviews, comments and other actions taken by the user in the past can be traced by an administrator.
It would then make sense if "criticctl deluser" did the latter, and a new command did the former.
Hi!
I'm in the state where I have a user felixh
that I tried to remove and then re-add but instead got "retired". Now I can't add the user since the email is already in use.
How do I work around this?
I'd be fine with just some way to get back the user from the retired
state since I can work around the issue with that account manually.
I ended up logging in to the server, running something like the following:
$ sudo -u postgres psql
# \c critic
# SELECT id,name,status FROM users; # This got me the id of the user in question
# UPDATE users SET status='current' WHERE id=60;
I hope this doesn't break anything. :D