Cannot create another user with the same username of a deleted user

[anesuc]

Hi all,

I just found a bug where if I remove a user from Admin (might do the same any other way, haven't tested), and I go to create a new user with the same username, it will fail saying to check error logs (checked both userFrost and php logs and there was nothing). This happened using the same username but a different email as well (so it's linked to the username). I've currently broken my myphpadmin to be able to check whats going on in the DB but I might make an effort later if this is a harder issue to debug.

User frost version: 4.4.5
PHP version 7.4.3

Edit: It turns out the email being the same also fails. So a past user can't join again.

Thanks,
Anesu

[lcharette]

That's because the deleted user is "soft deleted", so it still exist in the db, which is the intended purposed. However, I agree, the ability to permanently delete a user from the UI would be useful, plus a better error message.

[anesuc]

Alright. Yeah that would be useful! So deleting users directly in the users table will not break anything right?
Edit: Nvm it looks like there is other tables linked to the users.

[Delaney]

Hey @lcharette is this issue still open?

[lcharette]

User are still soft deleted. Open to suggestion how to handle this in the UI / CLI / whatever.

[anesuc]

I think there should be an option for an Admin in the Admin Dashboard to be able to permanently delete a user record. The option can be something specific along with a warning message etc thats fine.

[Delaney]

If emails or usernames from deleted accounts can be used again, my idea was to modify those fields and concatenate the deleted_at timestamp as a string to them, probably with a separator. Permanent deletion could break stuff.

[lcharette]

A hard delete would mean all activities and other related data would also need to be deleted. Otherwise you'll get record without an associated user. In some cases it could break things. For example: "Project was created by {name} on {date}"... Delete the username, the project still exist, but not the Name (unless you hardcode the Name string, but that can bring other issue, if the name can change ;) )

@Delaney solution is another solution, but what if User1 gets deleted, User2 is created with the same email/username, and then you need to re-enable User1?

There's no "perfect" solution, and I think it comes back to each app how they want to handle it. But I agree it should be more obvious when a username is denied because of a deleted user.

[Delaney]

@lcharette So a different error message for cases where the username/email is unavailable because of a deleted user?

[StrykeSlammerII]

I've posted a sprinkle for UF4 which redacts basic user info (name and email) before doing the usual soft delete, and gives users a button for self-deletion.

I found it ran into one of the issues lcharette noted: base UF often hardcodes usernames in logs, rather referencing them. After a username is redacted, earlier logs keep the original username--and if someone later reuses an old username, it will look like the older logs are refering to the new user.

...but as a sprinkle, it gives a starting point if anyone wants to try out the concept.
It may need expanded to fit any app it actually gets used in, because it only redacts username and email address; it doesn't know anything about a new app it gets dropped into. Read the notes before using 😁

I intend to update it to UF5 once I get that running on my end, but I've been slacking off on that 😦

[lcharette]

@lcharette So a different error message for cases where the username/email is unavailable because of a deleted user?

Not really, because you don't want to expose that a username exist, but has been deleted.

[H1ghSyst3m]

Wouldn't a Dummy User a better alternative, so when I delete a User then, the data like username, e-mail, name, surname change to anonym, deleted_user or something like that. That would also be better for the Privacy.

The dummy Users can also have a unique id behind their name like "deleted_user_2853" or "anonym_2425"
and a blacklist for username and e-mail domain would be really good, so that no one registers itself with a username or e-mail like that.

Then also the activities will just show the dummy user