Custom Activity Workflow for implementing Item Level Security in SharePoint Designer 2007

1. Introducing Office SharePoint Designer 2007 Workflows

Office SharePoint Designer 2007, a replacement for FrontPage, is used as an aid in the
rapid design and deployment of workflows. Office SharePoint Designer 2007 is specifically
designed to help create and customize web sites and workflows built with SharePoint
Products and Technologies. The Development process in SharePoint Designer is based on
declarative rules-based, code-free workflow editor.

SharePoint Designer (SPD) gives list administrators, business administrators, and designers
the ability to create workflows without writing any code. SPD exposes many of the
workflow activities that ship with SharePoint as "actions" that users can string together
into a sequential process. These actions are customized via sentences that describe the
action and bind data to action parameters.

However, businesses will oftentimes need more custom functionality than the actions
provided with SharePoint, requiring them to write custom code that can run on the
server. This guide describes how to write a custom code as an activity using the Visual
Studio Extensions for Windows Workflow Foundation and expose it as an action in SPD.

"Activity" refers to the basic building block of functionality in a Windows Workflow
Foundation (WF) workflow.

In Office SharePoint Designer 2007, however, each activity appears as an action,
represented by a sentence that contains variables that the user can configure using
drop-down menus and lookup dialog boxes. Users can also select conditions, which are
configurable conditional clauses that direct the flow of the workflow.

As the user is selecting and configuring conditions and actions in the workflow interface,
Office SharePoint Designer 2007 generates the two files that actually represent the
workflow class:

The workflow markup file, which contains markup language that describes the activities
included in the workflow.

The workflow rules file contains the business logic of the workflow in declarative rules
form, rather than as code.

2. Create a Microsoft Office InfoPath 2007 Form

1. Create a new Microsoft Office InfoPath 2007 Form.
2. Add two Text boxes and rename the text boxes as "Contributors" and "Readers".
3. Save the Form.
4. Publish the form with the two columns to the Microsoft Office SharePoint Server
   2007 site for which the item level security needs to be implemented.

3. Create a custom activity in Visual Studio with promoted properties

1. Navigate to Start | All Programs | Microsoft Visual Studio 2005 | Microsoft Visual
   Studio 2005.
2. Select the File | New | Project menu command.
3. Visual Studio displays the New Project dialog box.
4. Select the Visual C# | Workflow project type.
5. Select the Workflow Activity Library template.
6. Enter the path in the Location field.
7. Enter the name in the Name field.
8. Click OK.
9. Visual Studio creates the activity library project, including a single activity,
   Activity1, and displays a design view of Activity1.cs.

10. Rename Activity1.cs to ItemLevelSecurityActivity.cs by right clicking on Activity1.cs
and choosing rename.

11. Select the View | Toolbox menu command to open the Toolbox window.

12. From the Toolbox window, drag a Code activity and drop it onto the "Drop
    Activities Here" work area of ItemLevelSecurityActivity's design view.
13. The Activity Designer displays a code icon in the work area.

14. Rename CodeActivity1 to ItemLevelSecuritycodeActivity by right clicking on
    CodeActivity1 and choosing Properties and change the Name Property.
15. In the Solution Explorer, right click on References to bring up the context menu
16. Select Add Reference.
17. From the Add Reference dialog box, add references to the Windows SharePoint
    Services and the Windows SharePoint Services WorkflowActions.
18. In the Solution Explorer, right click on ItemLevelSecurityActivity.cs to bring up
    the context menu.
19. Select View Code.
20. Add the following namespaces in the code:

using Microsoft.SharePoint;
using Microsoft.SharePoint.Workflow;
using Microsoft.SharePoint.WorkflowActions;

Note: The activity wouldn't be useful if it didn't pass information on, so to make it
available to the rest of the workflow, we will need to use property promotion. Property
promotion consists of getters and setters to allow the property to be bound to variables
outside of the activity. For this example, we need to derive the Workflow Context object
to retrieve the current SharePoint Site, the List Id for which the activity is attached and
the current List Item to provide Item Level Security.

21. Place the cursor on the closing bracket of the ItemLevelSecurityActivity constructor
    and press Enter Twice.
22. Right Click on the last line you just inserted.
23. Select Insert Snippet.

24. Select Workflow.

25. Select DependencyProperty - Property.

This code snippet generates the getter/setter code and allows you to specify the
property name, type and description for the property.

26. Fill in these fields in the boilerplate code with the corresponding values. Use Tab to
    move between the fields and press enter when finished with the fields.
    1. For deriving the Workflow Context object to retrieve the current SharePoint
       Site:

i. Name: __Context.

ii. Type: WorkflowContext.

iii. Description: Context.

2. For retrieving the List Id for which the activity is attached:

i. Name: ListId

ii. Type: string

iii. Description: List Id

3. For retrieving the current List Item to provide Item Level Security:

i. Name: ListItem

ii. Type: int

iii. Description: ListItem

Note: Remove the Category Property and add the following code in its place for all the
three dependency properties.

[ValidationOption(ValidationOption.Required)]
The resulting output should resemble the following:

With this customized, the property is exposed to the rest of the workflow. The
workflow can now bind variables to these properties for both input and output.

27. In the Solution Explorer, right click on References to bring up the context menu
28. Select Add Reference.
29. From the Add Reference dialog box, add references to the System.DirectoryServices.
30. In the Solution Explorer, right click on ItemLevelSecurityActivity.cs to bring up
    the context menu.
31. Select View Code.
32. Add the following namespaces in the code:

using System.DirectoryServices;

33. In the Solution Explorer, right click on ItemLevelSecurityActivity.cs to bring up
    the context menu.
34. Select View Designer
35. Double click the ItemLevelSecuritycodeActivity activity to view the
    ItemLevelSecuritycodeActivity _ExecuteCode method and write the custom
    code behind your activity for implementing the Item Level Security as displayed.

36. In the Solution Explorer, Right Click on Properties and choose Open from the
    context menu.
37. Navigate to the Signing tab.
38. Check the Option Sign the Assembly.
39. Select the New option from the Drop down below
40. In the Create Strong Name Key dialog box, enter the Key File Name
41. Uncheck the Protect my key file with a password option.
42. Select the Build | Build Solution menu command.

4. Deploy the dll to the GAC and add it to the web.config file

The next step is to compile your activity and deploy it to the GAC
(C:\WINDOWS\assembly). The assembly must be signed. You can drag and drop this into
the GAC directory or use the .net gacutil tool. Keep a note of the assembly, class,
version, and public key token, as they'll be used later on in the .ACTIONS file.

1. Navigate to the root port directory of the SharePoint Site for which the activity is
   created located in "C:\inetpub\wwwroot\wss\virtualdirectories" and search for
   "web.config" file. These xml files contain lists of authorized types that can be used
   for that server port.
2. Open the file and search for "WorkflowActions", which should take you to an entry
   that looks like this:

<authorizedType 
    Assembly="Microsoft.SharePoint.WorkflowActions, Version=12.0.0.0, 
    Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
    Namespace="Microsoft.SharePoint.WorkflowActions" 
    TypeName="*" 
    Authorized="True" />

Underneath this tag, add a corresponding tag for your dll. For example:

<authorizedType 
    Assembly="ItemLevelSecurityActivity, Version=1.0.0.0, 
    Culture=neutral, PublicKeyToken=7211fc0c4fbd8603" 
    Namespace="ItemLevelSecurityActivityLibrary" 
    TypeName="*" 
    Authorized="True" />

The activity dll is now ready to be run on the server

5. Edit the WSS.ACTIONS file to describe the activity
parameters

The final step of preparing an activity for SPD is to change the WSS.ACTIONS file. This
xml file describes the types of the promoted properties of the activity and how to map
them into a rules sentence.

1. Navigate to "C:\Program Files\Common Files\Microsoft Shared\web server
   extensions\12\TEMPLATE\1033\Workflow" folder and open the WSS.ACTIONS file.
2. Navigate to the end of the file.
3. Append the following code before the </Actions> tag.

<Action 
    Name="Item Level Security activity in sharepoint designer"
    ClassName="ItemLevelSecurityActivityLibrary.ItemLevelSecurityActivity"
    Assembly="ItemLevelSecurityActivity, Version=1.0.0.0, 
    Culture=neutral, PublicKeyToken=7211fc0c4fbd8603"
    AppliesTo="all"
    Category="Extras">
    <RuleDesigner Sentence="Apply security to %1 Document Library">
          <FieldBind 
                Field="ListId,ListItem" 
                Text="this" 
                Id="1" 
                DesignerType="ChooseDoclibItem" />
    </RuleDesigner>
    <Parameters>
        <Parameter 
            Name="__Context" 
            Type="Microsoft.SharePoint.WorkflowActions.WorkflowContext, 
        Microsoft.SharePoint.WorkflowActions" 
            Direction="In"/>
        <Parameter 
            Name="ListId" 
            Type="System.String, mscorlib" 
            Direction="In" />
        <Parameter 
            Name="ListItem" 
            Type="System.Int32, mscorlib" 
            Direction="In" />
    </Parameters>
</Action>

Note:

The "Action" tag defines basic information about the action with the following attributes:

· Name – name of the action (this is what SPD displays in its actions list)

· ClassName – the name of the activity, i.e. Namespace.WorkflowClassName

· Assembly – details of the GAC'ed assembly

· AppliesTo – describes what types of lists this activity can be used for, either "list",
"doclib", or "all"

· Category – category that SPD will display in the categories for available actions

RuleDesigner

<RuleDesigner Sentence="Apply security to %1 Document Library ">
  <FieldBind 
    Field="ListId,ListItem" 
    Text="this list" 
    Id="1" 
    DesignerType="ChooseDoclibItem" />
</RuleDesigner>

The next section is the "RuleDesigner" section. This describes a rule sentence for the
action as well as how to bind them to the activity properties. These are the sentences
SPD displays in its rules wizard.

The variable parameters in the sentence, e.g. %1, etc., are exposed as customization
links. When displayed, they will be replaced with the "FieldBind" tags below, where %1 will
be replaced with the FieldBind with Id=1,etc.

The "FieldBind" tag describes each variable parameter. The "Field" attribute corresponds
to the parameter, or activity property, as it is described in the Parameter tag in the
markup. "DesignerType" describes what type of interface to show when the user clicks on
the link. For example, if you want to show a select user dialog, you would use
"SinglePerson" for the designer type. The "Text" attribute is how the field is displayed in
the sentence.

The end result for the above markup would look something like this in SPD:

Parameters

<Parameters>
  <Parameter 
    Name="__Context" 
    Type="Microsoft.SharePoint.WorkflowActions.WorkflowContext,
     Microsoft.SharePoint.WorkflowActions" 
    Direction="In"/>
  <Parameter 
    Name="ListId" 
    Type="System.String, mscorlib" 
    Direction="In" />
  <Parameter 
    Name="ListItem" 
    Type="System.Int32, mscorlib" 
    Direction="In" />
</Parameters>

Finally, the "Parameters" tag tells the RuleDesigner how to map the fields to the promoted
properties on the workflow activity.

Each "Parameter" describes the name of the property (which should match the
corresponding FieldBind above), the system type of the property, and direction ("In"
means that the activity gets that parameter, and "Out" means the activity sets that
parameter).

Once you have this file laid out, save your file.

6. Boot SPD

1. Do an iisreset.
2. Navigate to Start | All Programs | Microsoft Office | Microsoft Office
   SharePoint Designer 2007.
3. Select the File | New | Workflow menu command.
4. In the Workflow Designer dialog box, enter a name for the Workflow and select
   the SharePoint Document library list for which the activity should be attached from
   the Dropdown.

5. Check the Automatically start this workflow when a new item is created option.

6. Check the Automatically start this workflow whenever an item is changed option.

7. Click Next.

8. Click Actions



9. Select the More Actions
10. In the Workflow Actions dialog box, click the dropdown for the Select a Category and choose Extras.



11. In the Choose an Action box, select the Item Level Security activity in sharepoint
designer will appear and click Add.

12. Note that Apply security to this Document Library is displayed.



13. Click on this option in the Actions

14. From the Choose List Item dialog box, Select the Current Item option and click OK



15. Now the Actions is changed by displaying the current item's name.



16. Click Finish.
17. The Workflow can now be checked by creating a new InfoPath form, by entering
    the Authors and Readers fields.
18. Save the InfoPath form to the SharePoint site.
19. Select Manage Permissions from the Context Menu of the item saved and check for
    the permissions.

7. Conclusion

Though this topic covers implementing Item Level Security by creating custom activity,
the task can also be achieved by creating Item_Saved and Item_Updated Event
Handlers for Lists. Though there are multiple ways of implementing the task, creating
custom activity is more effective by means of reusability and lesser coding in VS 2005.