Sunday 20 January 2008

Workflow: tasks which can only be actioned by task owner

When coming to Visual Studio workflows, something which surprises many SharePoint developers is that tasks assigned in the workflow can actually be actioned by any SharePoint user with basic permissions. In the worst scenario, 'basic permissions' means any user with contribute permissions to the SharePoint web which contains the workflow tasks list, and clearly this could be a whole lot of users who have nothing to do with your workflows. In the best case, you might have tied down permissions so that only users involved in workflows can use the list. Even so, this still means that any actor in the workflow can respond to any task, not just tasks which have actually been assigned to them. To my mind, this is bad - all it takes is a confused user to accidentally respond to someone else's task and your workflow is in a whole world of chaos.

So what can we do about this?

Well, there doesn't seem to be much written about this, but fortunately the best solution (AFAIK) is also the simplest one. Before we dive in, I notice other people needing to solve this problem have taken the approach that since a workflow task is just a list item, we can execute some code to set permissions on the list item using the API. A logical tactic, but happily there is special provision for doing this in the workflow framework - we still need to write a little code, but it's much simpler than that approach. The key is the 'SpecialPermissions' property of the CreateTask activity:



Pitfall - confusingly, clicking the ellipses button (...) for the property presents a generic VS collection editor (shown below), which as far as I can tell just flat cannot be used with this property - all the controls are disabled!




I'm assuming this is a bug in the Visual Studio 2005 Extensions for Workflow Foundation, so we'll ignore that! However, clicking the tiny blue 'bind property' button presents the more familiar 'bind the property to an instance variable' dialog - assuming you haven't already created a variable to store the permissions for this CreateTask, we should select 'Bind to a new member', and create either a field or property to store the permissions:



This creates a collection object, specifically a HybridDictionary, to which we can add items for each permission we need for this task. And we only need a handful of code lines to do it! Since we're likely to use it for many (i.e. all) tasks in our workflow, let's have a separate method we can call each time:

private void setTaskPermissions(HybridDictionary boundDictionary, string sTaskOwner)

{

     boundDictionary.Clear();

     boundDictionary.Add(sTaskOwner, SPRoleType.Contributor);

     boundDictionary.Add("NT AUTHORITY\\authenticated users", SPRoleType.Reader);

}


So, we pass in the collection specific to each task, and also the string username for the task owner. We then add an entry for the task owner to the dictionary with the 'contributor' permission, and one for all other users with just read permissions. Note we also clear out the dictionary before adding in case this task has already been issued (i.e. something got rejected in the workflow and we came back to this task a second time) - this avoids any errors due to the key already existing in the dictionary.


The calling code then, looks like this:

setTaskPermissions(approveExpenseClaim_SpecialPermissions, taskProps.AssignedTo);

This would be added to the code for each CreateTask activity in your workflow. The first parameter is the variable we bound earlier to the SpecialPermissions property (of the particular task we are dealing with), and taskProps is the SPWorkflowTaskProperties object which holds data for the task.

And that's it - much less code than you'd need to modify permissions for the list item with general API usage. The effect of this is that the task owner is the only standard user (administrators with full control excepted) who can respond to the task, but all others can read it. Needless to say, you could customize the code to your specific permission requirements if they are different to mine.

The user experience

One final thing worth pointing out is that the user experience might not be quite as slick as you'd like. Since we've restricted permissions on the item, any user who clicks on the task but doesn't have permissions will see the standard access denied message:



Personally I think an improvement would be to show a more friendly message, but this would require substantially more effort and complexity. My view is that for a few lines of code, this approach is a great trade off between effort required and benefit of protecting the integrity of the workflow - I'm definitely not a fan of sleepless nights wondering just what would happen in the workflow if users unintentionally responded to tasks which didn't belong to them, so it works for me. As always, if you've implemented a different way of dealing with this problem or have other comments, it would be great to hear.

Thursday 10 January 2008

Resources from my workflow deep-dive presentation

Had a lot of fun presenting VS workflows at the UK SharePoint user group last night. We seemed to have weather issues (again) which might have put some people off travelling, but we still had a great crowd of around 100-120 people. As promised, here are my resources (my 'workflow bonanza pack' in fact ;-)). In the zip behind the link below, you will find:

  • Slide deck (presentation title: "Workflow: A deep dive into developing workflows for SharePoint using Visual Studio and Infopath")
  • Sample code for the state machine expenses workflow I built
  • My workflow information pack document

Much of the goodness is in the document - the contents are:

  • Links to my favourite workflow resources (blogs, books etc.)
  • How to: work with SharePoint tasks and e-mails in workflows
  • How to: Pass data into an InfoPath task edit form
  • How to: retrieve what the user entered into an InfoPath task edit form
  • How to: debug a workflow
  • How to: use serialization to retrieve data from an InfoPath form
  • Advanced workflow tips
  • Workflow pitfalls
  • Appendix 1 - correlation tokens

You can download all this from http://sharepointchris.googlepages.com/COB_WorkflowResources.zip

P.S. I'll be expanding on this content - the next couple of articles will be workflow-focused.

Friday 4 January 2008

Speaking at UK SharePoint user group on workflow

For anybody interested in workflow, I'll be speaking at the UK user group next week at Microsoft's London Victoria office on 10th Jan. There are two great sessions so I'd encourage UK SharePointers who can get to London to come down. Needless to say, I'll be posting my slides/sample code etc. for those further afield.

For those considering coming down, the meeting should be fun and it looks like a high turnout - we have over 100 people registered already. My fellow speaker is SharePoint MVP and all-round good guy Andrew Woodward.

The timetable and session abstracts are:

1800 - 1830 Arrive

1830 - 1930  Workflow: A deep dive into developing workflows for SharePoint using Visual Studio and Infopath - Chris O'Brien

Of the three types of workflow available to the SharePoint developer, only Visual Studio workflows provide complete flexibility and power. Without the right information however, the learning curve can be steep for the uninitiated. In this session we’ll start with initial decisions such as SharePoint Designer workflows vs. Visual Studio workflows, sequential vs. state-machine, and InfoPath vs ASP.Net for forms. From there we’ll cover the key steps to get a workflow up and running including retrieving data from an InfoPath form, configuring workflow activities, and deployment of the workflow. Over several demos, we’ll build a basic state-machine workflow, and show why workflow is a valuable addition to any SharePoint developer’s skillset.

1930 - 2000 Snacks and drinks

2000 - 2100 Search Server 2008 – What is it, how does it affect me and should I be testing it? - Andrew Woodward

A look at the recently announced Search Server 2008.  We will walk through an installation and demonstration of the new Federated Search capabilities, what’s provided out of the box, what you can get from free, how to leverage sites using Live.com and how to federate results from Google. We will discuss how this fits in with your existing WSS and MOSS deployments and the release timescales.


Registration/more info is at http://suguk.org/forums/thread/7300.aspx - please add to the thread leaving your full name