I want to use ecreall.trashcan in a project based on Plone 4.3 and I want to know is there is any issue with it.
I added support for Travis CI but tests are not running and I have no time to dig on it to fix them.
Can anybody here share some experiences with the usage of this add-on?
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.
thanks you! I arrived at the very same conclusion.
I will work on that when I have time.
does that really work? i tried it recently on a Plone 4.3 site and AFAIRemember, the move before delete content rule didn't work.
@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.
seems almost doable for me.
@hvelarde did you do it? I came across this requirement again...
Ida Ebkes created an addon, which seems to exactly do that. I didn't review and test it though:
https://github.com/ida/adi.trash
nop, we never found time/resources to do it; test that one and let me know.
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.
This is how Castle implements it; it leaves the object in place but hides it.
we did nothing; this is still needed and probaly a good candidate for a GSoC project 
(are you reading this, @cewing? )