SharePoint Check Out Policy Honoring
When writing a piece of Document Imaging software for SharePoint (such as VizitSP), it's likely that you'll need to worry about saving changes to files. This post will explore the different options there are and what compromises need to be made when deciding how to honor a SharePoint list's check out policy.
What Would Microsoft Do?
In almost every case, we tend to ask ourselves, "What would Microsoft do?". The debate as to whether a decision they made is the right one can be made elsewhere. The point is, Microsoft decided to do something a certain way, and now all of your customers are used to that behavior - right or not.
As far as document editing tools go, Microsoft Office is the only piece of software that is integrated into SharePoint out-of-the-box. When viewing a Document Library that has Microsoft Word documents in it, you can easily choose to Edit the doc directly in Word. When you're done editing, you can save it directly back into SharePoint from Office and continue browsing without downloading anything. Vizit is very similar, but from the raster-image side of the fence. We need to make sure that we behave as much like Office as possible; checking files out when you'd expect them to be checked out, checking them in when it makes sense, and offering the same menus and options as you would see when editing Word documents.
A List by Another Name
Many would argue that Document Libraries are simply an extension of the Generic List. In almost every respect they would be correct. They behave the same, they both contain list items and can have "folders", and they both live in Sites. They place where they differ is in two critical areas regarding documents. Association and Versioning.
Items in a Document Library have a one-to-one correspondence with an SPFile. SPListItem.File is a direct pointer to the document in question. Items in a Generic List have a one-to-many correspondence with its attachments. SPListItem.Attachments is an SPAttachmentCollection (a glorified string array) that contains the names of the files attached to it. Recently, I posted a blog in how to get at list item attachments. Looks like Microsoft glossed over this one.
Document Libraries offer a versioning feature. Files can be checked out, checked in, published, etc. List Item attachments in Lists are missing the UI to do this. You can't check out, check in, publish. If that was the intended behavior, it would be nice if the object model reflected that decision. Unfortunately, the same object is used to represent a List Item attachment as is used to represent a file in a Document Library. Through the object model, you can check attachments out, check them in, etc. This is inconsistent at best. If you aren't aware that this is how things work, you are likely to put SharePoint into a state that's not trivial to get out of.
Why Can't I Delete this Attachment?
From the little bit of testing that I did, I discovered that attachment exhibit a strange behavior when they are checked out. From the SharePoint web page, you have no way of knowing that a given attachment is checked out. If you attempt to delete an attachment, it will seemingly go away. But, by simply refreshing the Edit Item page, the attachments reappear. Nothing was deleted!
The only way I was able to successfully delete an attachment that was checked out through the object model was to delete the entire item it was attached to. I didn't look to see if the attachment was actually deleted via the object model, but my guess is that it is still in there... but with nothing pointing to it. Not cool.
What to Do?
Seemingly, the best question we can ask ourselves is "What Would Microsoft Do?". Fortunately, they punted on this problem as well, not offering Office integration with List Item attachments. If you want to edit an attachment, you must download it, edit it, and reattach it, hoping that no one else is doing the same thing. Otherwise, it's a race to see who gets there last and steps on the other's changes.
One-Uping Microsoft
Doing Microsoft one better isn't too complicated in this case. We can offer users the ability to one-click edit raster images through VizitSP while maintaining the checkoutless model they provide for attachments. There's little we can do in this case until Microsoft offers the UI to check attachments back in after an aborted edit.
For those of you out there that would rather deal with the occasional support call asking how to get them back to normal, it is fairly easy to add some UI to your own app that lets them check the file back in. Just hope and pray they don't uninstall your app before they phone in.
