Forum OpenACS Development: File-Storage Checkouts

Collapse
Posted by Sean Harrison on
Hi, all,

I just finished extending File-Storage (based on OpenACS 4.6.3) in order to enable locked check-outs and check-ins of the files. Thanks to those who helped me over a hurdle in the development of this.

I haven't done any abstraction of the code (such as making all this checkout functionality optional), but I have provided a working example for the community:

http://edittools.net/projects/file-storage-example/

I am using this to help manage a publishing project involving a half dozen editors and about three dozen authors. Since the files are Microsoft Word documents, there isn't any hope of using CVS merge, and Word's "merge" function is hopelessly broken. So, we have to make sure that only one person at a time is making changes. This addition takes a lot of administrative headaches off the shoulders of the editorial project manager (me).

Is this functionality something that would be an interesting addition to the file-storage module in general? Should I post diffs or a patch to show what I've done, or full copies of the files that I've created or modified?

I'd be glad to work on generalizing this functionality for file-storage in OpenACS 5.1, if it is something that the community decides to add to file-storage.

P.S. to Dave Bauer: I _like_ the 4.6.3 file-storage functionality, in which the same document can have different file names in different revisions. This is, in my experience on the big editing project, the right way to handle things. At any time, the folder view will show only one entry for each document, and I don't have to worry about whether the editors on the project have changed the filename on their own computers (which they all tend to do), because when they "upload a new version" it will still be considered part of the same file object. Please don't change this, as I recall recently reading that you planned to do or had done. Thanks.

Take care,
Shawn Harrison

Collapse
2: Re: File-Storage Checkouts (response to 1)
Posted by Malte Sussdorff on
Shawn, it definitly is a good thing for file-storage to have. Furthermore, I just realized that FS does not support notification, though I think a patch had been posted. If there is interest I could ask Abhinav if he is able to apply it to head for the 5.1 release.
Collapse
3: Re: File-Storage Checkouts (response to 1)
Posted by Mark Aufflick on
Yeah - that stuff sounds great!
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

Collapse
5: Re: File-Storage Checkouts (response to 1)
Posted by Jade Rubick on
This would be a great addition!
Collapse
6: Re: File-Storage Checkouts (response to 1)
Posted by Don Baccus on
Dave - yes all functionality of this sort should be pushed down to the CR.  The file storage package is just a UI wrapper  for the CR, conceptually at least...
Collapse
8: Re: File-Storage Checkouts (response to 1)
Posted by Mark Aufflick on
<2¢>

we should possibly start a "Future of OpenACS Content Repository" discussion.

We are already discussing:

  • File locking (this thread)
  • Replacing the site map with CR folders or vice versa (here)
  • Merging in some of the api from the old CMS which should really belong in CR (various threads including the above and New CMS discussions)
  • Playing with the way revisioning works (New CMS discussions plus various other threads)
I'm sure there are others that have fallen by the way!

The CR is shaping up as one of the key backbones of OpenACS, but it's also a bit of an orphan - no one wants to document it, and when we used the CR keywording functionality to build the new bugtracker, we found that some parts of it hadn't been used for a few versions (that was obvious, because some key functions weren't even there!)

It's actually pretty sexy, I think we need to make sure it gets the attention it deserves.

</2¢>