UserFrosting icon indicating copy to clipboard operation
UserFrosting copied to clipboard

Use model events to handle different modes of user deletion

Open alexweissman opened this issue 7 years ago • 3 comments

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_at timestamp)
  • Medium delete (deleted_at timestamp 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.

alexweissman avatar Dec 05 '17 18:12 alexweissman

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.

splitt3r avatar Dec 07 '17 14:12 splitt3r

So actually, Eloquent already supports model events: https://laravel.com/docs/5.4/eloquent#events

alexweissman avatar Dec 08 '17 04:12 alexweissman

Looks great :+1:

splitt3r avatar Dec 08 '17 07:12 splitt3r