better late than never: I don'l ike it and think it is over-engeneered. You might be better suited with a new wf-state and transition (deleted/delete) and a content rule that moves items to a dedicated trashcan on the transition. There is no automatic putting stuff back but in more than 90% of all projects that should be enough.
@thet you are right that content rules don't work on deleting. That's why I proposed a wf_transition and a content_rule that listens to that and moves the item to a trashbin (some folder). The trashbin can be emptied by a action or a cronjob. The normal delete-action has to be hidden for normal users.
in fact, I was thinking on a subscriber listening to the IObjectRemovedEvent event, changing the workflow state to a customized one visible only to the person that removed the object and storing the object in a special folder as you mentioned.
I didn't see the thread until now.
I still use this module on two Plone 4.3 projects. And yes, there is zero tests in this module, this was years ago and I was not comfortable how to write tests with PloneTestCase.
As the README says, when you trash an object, it doesn't move the object, it stays in place. The primary decision for this design is that it's a nightmare permission wise (depend on your project) to handle the move to another folder. And I didn't want to pollute the workflow history with a deleted state.
This adi.trash addon is more simple, it customizes in profiles/default the delete button in folder_contents and delete action for objects, calling a custom browser view instead. In the custom browser view, it asks: "Am I inside the trash itself?", if True, deletes the object, if False, moves the object to a trash folder, creating the folder it if it doesn't exist.
There is no restore, advanced features, configuration, nothing, it just moves a deleted object to a trash folder. Since it's a move action, we didn't test if it keeps the history. We're not using it yet, but it's simplicity caught our eye.
It can be improved, of course: for example, before moving it to the trash, editing the object and adding a comment "Excluded by USER", that kind of thing. I don't think it should have much more functionality than that, if more log is needed for example, collective.fingerpointing along adi.trash would be a better fit.