Forum OpenACS Q&A: CR question

1: CR question

Posted by Nima Mazloumi on 06/11/07 11:00 AM

Is there a way to tell content repository not to really delete an item and its revisions but flag them as deleted? I have a request here for a file storage instance. It should delete the files but just make them "invisibel".

2: Re: CR question (response to 1)

Posted by Nima Mazloumi on 06/12/07 11:52 AM

does cr_items.publish_status reflect that?

3: Re: CR question (response to 1)

Posted by Nima Mazloumi on 06/12/07 11:59 AM

possible values seem to be ready, production, live, expired.

wouldn't it be interesting to have a flag in file-storage wether it should really delete files or simply flag them as deleted or archived just like communities?

4: Re: CR question (response to 1)

Posted by Nima Mazloumi on 06/12/07 08:49 PM

Ok. Here is the plan. I will add a new parameter to file storage that will decided wether files/folders are really deleted or wether their publish_state is set to for instance 'archived'.

When an item is deleted folder-chunk will not display the file anymore. now who should still see the files? I assume administrator of the current folder right? thus I would recommend a second list in folder-chunk that displays deleted items to admins.

The question is now: what if a user tries to create an item that has the same name of an existing deleted one?

There will be a bulk action to set the status of an item and subitems to live again.

From what I see file storage for or less forwards removal to content repository. therefore I will place a parameter check in delete.tcl that will call two new procs for archiving items instead of calling fs::delete_folder or fs::delete_file.

does this approach sound acceptable?

5: Re: CR question (response to 1)

Posted by Nima Mazloumi on 06/12/07 08:50 PM

the next step could be adding a cr parameter for a whole site to behave like this on the content repository itself.

6: Re: CR question (response to 1)

Posted by Gustaf Neumann on 06/13/07 08:42 AM

a design based on the idea, that an admin will be needed for getting erroneously deleted files back, is not preferable.

If one needs a soft delete, why not thinking about moving these files into a trash directory? This is a metaphor familiar to most users. It is as well much easier to address naming issues (the name clash when recreating a soft-deleted file in the same directory does not happen; the name clash after the second delete of the same file in the trash folder can be handled by e.g. appending suffixes, similar to Mac OS X).

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...

10: Re: CR question (response to 1)

Posted by Don Baccus on 06/14/07 03:41 PM

Nima, whatever ends up being done needs to be agreed upon by .lrn honchos, since file-storage is a rather critical part of .lrn.

Also if the change is reflected in the CR we'll need to TIP it and get OCT approval.

I like the carl/gustaf notions better than adding a "hidden" flag to cr_items. an "archive" option with one archive per file storage instance seems better to me than your original idea.