It would be better to have a "is_deleted" flag, or a "deletion_time" timestamp column in the user table, and modify the user management code to use that, and filter with that in mind.
As our JHipster apps are growing, there is a natural tendency that the user entity is getting linked to various business entities. This could clash with the user management code, which currently happily wants to delete physically from the user table. This result is foreign key violations, and transaction rollbacks, etc, which is not that nice. In this case, either the developer needs to clear up every reference from different business entities (which is not always simple), or need to implement logical delete - somehow.
I prefer the later, so even if the user is deleted, it can clearly displayed that for example he/she was the last 'owner' of a particular business entity.
A new field needs to be added to the user - I prefer a deletion_time timestamp, as the 'created_ and updated_ is already there, and modify the UserService / UserRepository to deal with it correctly.
There is also a @Scheduled purge of users who haven't finalized their registration before activation link expired. I guess it could not hurt to continue deleting them as they have no relationship with other entities.
@gmarziou oh yes I have this on https://start.jhipster.tech (well, I just use a default JHipster app...), and this is really awesome, as there are quite a lot people entering "false" e-mails.
I don't understand why people do this... At the same time you wouldn't believe what I see with my e-mail account (my name in French is like "John Smith" in English, so there are people creating Amazon, Uber, Facebook accounts using my e-mail address - often with their credit card linked to it...)
Yes, not activated users are generally not an issue, I believe.
I could implement the necessary changes, if no one objects it.
@gzsombor in fact I have an issue: we already have an "activated" flag. And this is kind of the same thing -> maybe we should modify the UI to use this by default, instead of deleting.
And keep deleting possible, but in a less easy to use button - I do delete some users on https://start.jhipster.tech as there are some people doing mistakes, etc, so this is still useful. Another issue: as the email and login are unique, sometimes it's good to delete people, and not just flag them.
Sure, the login and email address uniqueness is needs to be addressed, of course. I've done it - needs some modifications in the UserRepository and in the db unique constraint.
And yes, sometimes deleting users physically is the simpler thing. Maybe we can add a checkbox to the delete dialog, to "Delete instead of hide"
The activated flag is not very good to use to 'de-activate' a user. Unfortunately, if you de-activate a user, the previously mentioned 'cleanup' will try to delete them, but it will fails and kill the thread in every night - ouch. So no more 'half registered user cleanup'. If you constantly monitor your app for exceptions, you will notice it, but I rarely do it 馃槈
So in the end, I have a 'Deletable' interface/base-class near to the AbstractAuditingEntity, and use it everywhere - and try to remember to add filtering for the 'deleted' flag, which is not that difficult, if you do it consistently.
It means also that such soft deleted users should not be able to reset their password.
Maybe password should be cleared up also to avoid being exposed in case of database compromission.
-> @gzsombor would you be OK to close it? We just have too much work at the moment
Sorry, I had a feeling, that you were not convinced, that this is a needed feature, so I haven't pushed a solution. (And recently I have minimal time 馃槥 ). I keep it on my radar, to do it in this month.
@gzsombor its a good idea indeed, I used to do this all the time, it was good for audit purposes and also in case where you have relationship with users, but you dont to delete the entities while deleting a user
Most helpful comment
I could implement the necessary changes, if no one objects it.