feat: ability to undo deletion

[kguzek]

it would be nice to be able to have an 'undo' button when the user deletes a resource in the admin panel. I thought about implementing this client side, by simply showing an "item has been deleted" modal with an undo button, which actually only sends the DELETE request after the time elapses (e.g. 10s), but that would mean that if the user 'deletes' something and refreshes the page immediately after, then it wouldn't actually get deleted, because no request will have been sent to the backend and the timer will have been lost due to component unmount.

I think the best way to implement this would add some kind of deletedAt field in the base controller, and DELETE would simply set the timestamp to the near future. if there is no PATCH sent that reverts it back to null, then it will actually get destroyed at the provided time.

what are your thoughts on this? maybe a different implementation?

[mini-bomba]

is a deletion confirmation modal insufficient?

[kguzek]

is a deletion confirmation modal insufficient?

I'd argue yes, because we already have one, but the effects of deletion (removing from item from the list) are only visible after the confirmation, and it is only then that a user might realise they made a mistake.

[Leadman5555]

Well, that is possible. Though not in a way you'd probably like it to. What could be done is the deletion revert and a script running every n minutes that would clean up outdated entries. However, doing it though deletedAt field is not a good idea. If we have such a field in every model, the overhead would be big (checking it in every single operation - that is, we have a separate view that is always applicable). Automating that view would be... well, not nice. Moreover, we would have referential integrity problems - manual checks for referencing items. Assume a parent object is deleted - if so, should every dependent be also marked as deleted?

[Leadman5555]

The only possible server-side solution I can see is having a mirrored "deleted" database, where deletion is moving a record and all dependent records into the "deleted" mirror, while updating all parents. This makes a usually simple atomic operation a multi-step one that needs synchronization with ongoing queries.
Likewise, restoring is moving from the "mirror" to the normal database, also a multi-step solution

[Leadman5555]

And that leads to yet another problem - merge conflicts on restores 🥳

[mini-bomba]

delaying deletion would also require us to manually enforce database consistency rules (on delete relation actions)
= more work for the backend code which could've been done faster and safer by postgres itself

[Leadman5555]

Mhm, like I said, barely possible in a safe fashion.

[Leadman5555]

it would be nice to be able to have an 'undo' button when the user deletes a resource in the admin panel. I thought about implementing this client side, by simply showing an "item has been deleted" modal with an undo button, which actually only sends the DELETE request after the time elapses (e.g. 10s), but that would mean that if the user 'deletes' something and refreshes the page immediately after, then it wouldn't actually get deleted, because no request will have been sent to the backend and the timer will have been lost due to component unmount.

Can' you do that on frontend? I guess if you wrote pending deletions in the local storage instead of component timers, that could solve to refreshing issue

[Leadman5555]

Although, even if implemented in a safer manner on frontend, it is still a synchronization circus. Assume the following: user removes & user creates a new (duplicate) record => pending deletions need to be cancelled