Thursday, December 3, 2009

Sharepoint: Item-Level Permissions in Doc Library Based on List Data

Had an interesting challenge to set item-level permissions on a SharePoint document library based on list metadata. If a user uploaded a document and set the value of a list column to "published", everyone could see it. It the document was "unpublished", only a restricted group could view the file.

After a lot of surfing around the web, I found Richard Seroter's excellent post, which covered the vast majority of what I needed.

As Richard did, I created both my main document library and a lookup list which contained my published/unpublished values, and a list of users associated with each.

NOTE: I tried using a people/groups field type for this column at first, but when queried, that returned both the field ID and value, like "1;DOMAIN/username;2;DOMAIN/user2". I finally switched to a multi-line text field instead, which was easier to query cleanly.

In my main document library, I set up a lookup field that pulls the title values from my lookup list. So far, so good!

In order to run the Sharepoint Server Sequential Workflow project in VS 2005 Richard used, I needed to nab first the Visual Studio 2005 extensions for .NET Framework 3.0 add-in, and then the SharePoint Server 2007 SDK: Software Development Kit.

NOTE: I actually ran into an issue where neither set of templates were showing up in my already-installed copy of VS 2005, so I ran a repair install before I could finally access them. Hopefully, it will just work for you. =)
OK, ready to run! I fired up VS, started the project, and got through the first couple of steps. I referenced another article at The Code Project for some of the finer details, including how to deploy the DLL to the GAC.

NOTE: Don't be a moron like I was. Make sure that you nab the PublicKeyToken when deploying the DLL, and fill that in wherever the code asks for it. Leaving it as '111111111111' doesn't work. ;)

When all was said and done, the project was finally deployed and it looked like things were working...but wait, that workflow that just said 'completed' is now 'in progress' again. We're getting 'out of memory' errors. What's going on?

Thanks to an article on how to debug your SP workflow, we found the problem: An infinite loop. No, not caused by our code - by the workflow itself.

See, the workflow was set to run when a new item is created OR when an item is changed. It turns out that when the workflow runs, it makes a change to the item...Which then triggers the workflow...Which makes a change...Which triggers the workflow...And you're stuck in an infinite loop. Brilliant.

Back to the web! An article on the same problem in another workflow scenario suggested simply disabling event firing immediately before the update is called, and turning it back on right afterwards.

That's the solution we put in for now, although I think it would be better long-term to move the IF statement up a notch. It could check and see whether the values it would be updating the list item to is already there. If old values = new values, do not update.

It's working for now, tho. Phew!

No comments:

Post a Comment