Forum OpenACS Q&A: Re: CR question

7: Re: CR question (response to 6)

Posted by Nima Mazloumi on 06/13/07 11:56 AM

Good point. Thou I was not thinking of erroneously deletion in first place but rather the fact that the data must never be lost.

There could be a central trash folder for each user or a local in each folder. Usually a user would expect that the recovered file is moved back to where it was, right? I guess CR does not track movements of files. So either I have to store that data a local trash folder?

Something else that might be important are permissions. When a file or folder is moved are explizit permissions moved as well? At least this I see in the log "Deleting associated permissions...". I was not able to confirm since moving a file is broken at least in my current HEAD installation. I always get

[13/Jun/2007:09:25:46][3030.3060222864][-conn:15-] Error: Aborting transaction due to error:
Query did not return any rows.

and a message:

There was a problem moving the following items...

8: Re: CR question (response to 7)

Posted by Carl Robert Blesius on 06/13/07 04:25 PM

Why call it "delete" in the UI if your are not going to delete things?

An alternative would be "archive". Gmail started by not offering the option to delete messages, but actually went back and added a delete option b/c people wanted to actually "nuke" messages. They have both options now: delete and archive.

Make sure you ask Daveb about how he implemented the CR image upload plugin for us. It gives a unique URL to images and files in the CR. Might be a useful concept as you think about how to do this.

9: Re: CR question (response to 7)

Posted by gustaf neumann on 06/14/07 12:35 AM

i would not opt for per user trash-cans (what if one user deletes a file, and another user wants to find it later). another option is to have a trash bin per file-store instance. so, if someone deletes a file in a filestore of a community, a user would certainly look into the trash bin of that community and find it there. I would not expect that the system tracks back, from where the files was exactly deleted (mac os x trash can does not do it either). I am not sure, what "deleting associate permissions" actually mean without reading the code. And yes, the move operation of the fs as it is currently implemented is not really nice and it is likely to be broken. going for a drag+drop interface based on javascript would be much simpler...