Forum OpenACS Development: Re: File-Storage Checkouts

Collapse
4: Re: File-Storage Checkouts (response to 1)
Posted by Dave Bauer on
Shawn,

The changes to file storage will allow upload of new revisions from any filename. The upload filenames are stored in cr_revisions.title if no title is specified.

I would like to address locking and checkin-out of content repository items more generally. I need to implement this for WebDAV support. Right now the tDAV tcl code handles locking outside of OpenACS.

I would like to create locks for any content repository item. This way a locked file would be locked from a WebDAV interface and the regular web interface.

Shawn,

It does appear that you are one of the few users using file-storage for the original purpose, to collaboratively edit documents. Many users are using it more as a content managment application.

Collapse
7: Re: File-Storage Checkouts (response to 4)
Posted by Sean Harrison on
Dave,

Thanks for your reply, and for clarifying the file-name issue. That sounds like a great solution -- just to handle the case where the person uploading a brand-new file doesn't specify a title, if I understand correctly.

What you describe doing with the content-repository sounds excellent.

For my kludge job, I just created a new table, fs_checkouts, with four columns:

file_id (references object_id of the file),
checkout_date (a timestamp),
checkout_user (a user_id)
checkout_comment (a comment that the user makes when checking it out).

Then, in folder-chunk-postgresql.xql, I added a couple of joins (ugly!) to the contents query, in order to get all of this information, along with the "comment" field in the revisions table for the live revision, into the @contents@ variable. Then I could display all of the revision comments, or the checkout comments for the checked out files, in the folder view, which gives a nice snapshot of the status of the project.

There is no "history" in my implementation: When a file is checked out, a record is added to fs_checkouts. When the file is checked in, that record is deleted. In keeping with the versioning of the content-repository, it would make sense to keep history, too. If checkout information was added to the cr_revisions table, then each revision could hold the record of one checkout. (This would also allow locks to be taken on different versions of a document, which might actually be useful in some situations.)

Take care,
Shawn