The past few weeks I have been on and off working on a SharePoint Visual Studio workflow that routes documents for approval and sets permissions on the document and tasks to approve so that only the user approving that document can read.

In the workflow, I created a “CreateTaskWithContentType” activity and off I went, using the SpecializedPermissions Property to set the permissions on the task that was created, and then a custom function to modify the security on the document getting approved.

This code is pretty straight forward. You add a new dictionary to for the SpecializedPermission and then add the user you want as the key (yes it was a valid user stored in originator) and then the value to be the SPRoleType you want to grand the user.

Every blog out there say that this should work, and it did. Sort off. While technically the permissions were getting set and no impact seemed to be happening to functionality, the SharePoint Logs said differently.

The following error kept showing up and it took me weeks to track it down.

After doing some digging on the internet I discovered a Blog by Hristo Pavlov about AllowUnsafeUpdates.

In his blog he showed that when permissions are changed AllowUnsafeUpdates in some cases is reset to false. This was the cause of the above error. When the workflow created the task, SpecializedPermissions called the ResetRoleInheritance() method which reset allow unsafe updates (As best as I can tell).

That being said I still do not know a way to fix the problem using SpecialPermissions. Instead, I manually set the permissions on the task using the TaskCreated activity in the workflow.

This same error comes up when you reset role inheritance on any item in a workflow – paying particular attention to set AllowUnsafeUpdates to true after just about any permission operation.

For example:

I anyone else has a better solution, please comment and let me know. Likewise I’m happy to field any question

UPDATE:

I learned you don’t need to call “item.update()” after you set or break role inheritance, or add a role association. This will cause an exception. You DO still need to re-set the allowunsafeupdates to be true.

MOSS, MOSS 2007, Security, SharePoint, SpecializedPermissions, Workflow