UserFrosting
UserFrosting copied to clipboard
Use model events to handle different modes of user deletion
Discussed in #785. Basically we should stop overriding User::delete, and instead factor out this code and its decision points into model events and controller methods.
The way I see it, we might have three modes of deletion:
- Soft delete (
deleted_attimestamp) - Medium delete (
deleted_attimestamp and clear out most user details) - Hard delete (delete record and delete/null out any orphaned related entities)
It's possible that if we make all related entities have nullable FKs, then medium-delete and hard-delete can be essentially the same thing.
This also brings up the question of what to do when a new user wants to use the username/email of an account that was deleted previously.
I think adding pre and postDelete events would be a pretty nice solution. That way a sprinkle could listen to e.g. user.preDelete / onPreUserDelete (http://symfony.com/doc/current/components/event_dispatcher/generic_event.html & https://learn.userfrosting.com/services/default-services#eventdispatcher) and remove everything so that there won´t be any constraint problems. And perhaps rename the events to follow https://symfony.com/doc/current/components/event_dispatcher.html#naming-conventions.
So actually, Eloquent already supports model events: https://laravel.com/docs/5.4/eloquent#events
Looks great :+1: