Friday, March 06, 2009

MOSS 2007 - Workflow Approval Sets Modified By to "System Account" Part 2

In my previous post on workflow approval "MOSS 2007 - Workflow Approval Sets Modified By to "System Account"" I talked about the problem of how versions are created and updated by SharePoint as part of a custom workflow, causing the Modified By property of the page/item to be set to the system account rather than the account of the last person who actually worked on the page/item. That post shows an attempt at a solution that does not work, where I was still trying to understand how to use a SharePoint list event handler.

I was able to get the event handler working, but with a drawback: When an item is approved, the event handler sets the Modified By property of the page/item, but then it also creates a new draft version of the item in the version history. This could be confusing for users, but in my situation it's an acceptable solution. Below you'll find the entire project, zipped up using 7-zip format.

To install the event handler, follow the directions listed in the previous post "MOSS 2007 - Workflow Approval Sets Modified By to "System Account"", but use the Feature.xml, Elements.xml and UpdateTaskColumns.dll from building the project.


Phil said...

Great Post!
A couple problems with this is that you can only have one Information Management Policy per content type. If you're looking to track JUST the version, and you don't actually need an image, you're in good shape, because you just don't require the label, and let them add in the content control.

However, if you NEED image labels then they'll likely have more than just the version contained within the label. 1) the parameter _UIVersionString will always appear on the image (not the actual version and 2) you cannot parse the content control to glean just the version number out.

It seems like a circumstantial workaround to a specifications failure on Microsoft's part. If it is going to show the version on the SharePoint site, it should show it in the document. This solution is functional but has some elegance flaws that make it unuseable in some instances.

Again though, Good Post.

Unknown said...

Thanks for the feedback Phil!

Phil said...

Also, regarding your comment about how highly-customized sites have problems, i've noticed this before too, and it seems like under certain conditions SharePoint realizes that you are referencing content type columns or site columns that can only exist in the customized environment. I really wish I could remember the scenario. It seems like I created a content type that used a document template that needed a calculated column that only existed in a specific document libary. So when you try to copy the content type to another site it refuses to because it knows once it leaves the site collection, it is totally broken. It is a little different but i bet the principle is the same. Somewhere in the background some content type is referring to the version column, and tying those two together makes the present site collection the only sensical home. Just a guess.