Hiding Documents During Workflow Processing in Microsoft Word

Encoder Data Matrix ECC200 in Microsoft Word Hiding Documents During Workflow Processing

I flip-flop on this one. On the one hand, I would expect that keeping users from seeing documents until any workflows finish processing should be the default especially for workflows that start automatically when a document is created or modified. On the other hand, though, I can easily think of situation where you would not want this to happen. So I guess Microsoft took the right road by not making it the default. All we need now is a means to hide documents when we have to. Fortunately, it s pretty easy. We take advantage of the security-trimming features of SharePoint (which don t show things that a user doesn t have access to) and use those features to hide our documents until we re ready to show them. First, we need to hide the documents. At the beginning of your workflow, add a Code activity and add the code from Listing 9-22. This code will do two things: Stop the document from inheriting its permissions from its containing document library this automatically causes the current user to be assigned as an administrator on the document. Assign the specific approvers as administrators (or whatever access level you need to give them) to the per-item permission set for the current document.

Listing 9-22. Hiding Documents from Users Not Involved in the Workflow SPListItem item = this.workflowProperties.Item; item.BreakRoleInheritance(false); SPUser user = this.workflowProperties.Web.CurrentUser; SPRoleAssignment assignment = new SPRoleAssignment(user); SPRoleDefinitionBindingCollection binding = new SPRoleDefinitionBindingCollection(); binding.Add(workflowProperties.Web.RoleDefinitions.GetByType (SPRoleType.Administrator)); assignment.ImportRoleDefinitionBindings(binding); item.RoleAssignments.Add(assignment); //repeat code similar to the following for each user involved in your workflow. SPRoleAssignment assignment2 = new SPRoleAssignment (@"KCDHoldings\User1", "user1@kcdholdings.com", "User1", ""); SPRoleDefinitionBindingCollection binding2 = new SPRoleDefinitionBindingCollection(); binding2.Add(workflowProperties.Web.RoleDefinitions.GetByType (SPRoleType.Contributor)); assignment2.ImportRoleDefinitionBindings(binding2); item.RoleAssignments.Add(assignment2); In Listing 9-22 we break the permission inheritance and then add specific permissions for two users the current user and then the ever-present User1. In your workflow, you would likely want to add permissions for every user who will play a role in your workflow. You can get this list of users easily from the Contact Selector (or People Editor) control see the information earlier in this chapter. Notice that you can specify different permissions for each user added to the permission set we gave the current user administrative access but User1 contributor access. The last thing we need to do is reset the permissions once the workflow is done so that it is again available according to the permissions of its containing document library. Two lines of code will take care of this for us. Add another Code activity to the end of your workflow and add the code from Listing 9-23 to it. Listing 9-23. Granting Access to the Document Again SPListItem item = this.workflowProperties.Item; item.ResetRoleInheritance(); Bang. Done. By setting the per-item permissions for the document, we have hidden it from users who are not involved in the workflow. Once we reset those permissions to inherit from the document library, the document automagically appears for all users who should have access. Before you say anything, yes, the Approval default workflow does exactly this for you if you choose as shown in Figure 9-14, which was taken from the association form for the Approval workflow. One drawback, however, is that it requires content approval be turned on in the document library. Our code will work regardless of the content approval setting on the list or document library.

Figure 9-14. The default Approval setting allows you to hide documents until they are approved, but it requires content approval be turned on in the document library.

Way back in 5, we wrote a custom activity that removes macros from Office 2007 documents. In 6 we made use of that activity in our workflow. The workflow we created was done in Visual Studio and we could easily add the custom activity to the toolbar. But what about workflows created using the SharePoint Designer Wouldn t it be nice if we could add custom actions and conditions to meet our business needs Fortunately, you can easily.