We cannot listen to the Deleting event and send anything back to the user because the flags for the post haven't been actually deleted yet.
We cannot use the afterDelete callback from the AbstractModel because deletion is executed from the eloquent relationship, which uses an underlying query Builder object which doesn't fire events.
In addition, the original comment made by Ian (https://github.com/flarum/flags/pull/35#discussion_r563206641) - to me - isn't really, entirely valid. Our flags implementation dismisses all flags from a post when the flag(s) on that post are reviewed; it is one interaction that causes the dismissal of all flags of one post.
As such we need to remedy this by doing:
Reinstate or move logic from FlagsWillBeDeleted to Deleting.
Or fire a FlagsHaveBeenDeleted event.
Use the post as argument in the event, not the flags (which are deleted).
The Deleting event in the flarum/flags extension was refactored here https://github.com/flarum/flags/pull/35.
As a consequence:
afterDelete
callback from theAbstractModel
because deletion is executed from the eloquent relationship, which uses an underlying query Builder object which doesn't fire events.In addition, the original comment made by Ian (https://github.com/flarum/flags/pull/35#discussion_r563206641) - to me - isn't really, entirely valid. Our flags implementation dismisses all flags from a post when the flag(s) on that post are reviewed; it is one interaction that causes the dismissal of all flags of one post.
As such we need to remedy this by doing:
FlagsWillBeDeleted
toDeleting
.FlagsHaveBeenDeleted
event.