As I noted in my last post I’ve been working with a State based custom MOSS workflow.  I’ve actually reached the point where I’m into resolving minor issues during my unit tests.  One of my tests involved having a user other then the assigned user take a pending task and resolve/address it.  So for example a document waiting to be approved is recognized by a manager who is covering for the assigned manager.  The covering manager has “permission” to complete the task but isn’t the assigned user.  This is where I had what I consider to be unexpected behavior.

What happens in SharePoint is that when I start in the debugger (or after deploying my workflow outside the debugger) the workflow is run in the context of the administrator.  Now before you read that as “administrator” let me clarify – it’s run under a fixed account.  The context of the thread executing the workflow isn’t assigned based on the current user.  So whether it’s the administrator account or the Guest account the point is that at runtime if a parameter containing the user who triggered a workflow event isn’t passed into the workflow there is no way to determine the actual identity of the person triggering that next step in the workflow.  This is important because if you are planning a workflow, then like most you are planning to capture a history of events which occurred.  The problem if you don’t explicitly pass the name of the current user triggering an event then the name available as part of your running context will not be correct.  Thus your history can at best reflect the name of the user who was supposed to resolve/address that action.  Lost is the identity of the user who actually accessed your site and did take action on that workflow item.

If someone actually has an answer for getting that user (aside from explicitly setting a parameter) that I'm not aware of please feel free to let me know?

I spent quite a while looking at the parameter and runtime environment data and created a new WindowsPrincipal.GetCurrent() instance to see if I could find the actual current user. I also checked for example the current user value in this.workflowproperties.web, and it also was the administrator.  Of course it might turn out to be a setting within SharePoint that I'm not aware of.  Not that I would have explicitly set it since I can only begin to guess at where the setting comes from when my workflow is deployed from Visual Studio 2008.  (btw, the account I deploy from isn't the administrator account.)

I actually consider this to be a pretty major workflow failing… in theory there is a reduction in security since the process executing the workflow has the permissions associated with (in this case the administrator) the most privileged account that will need to run any workflow.  Additionally it breaks down on tracking reliability since it is in theory possible to apply the wrong account name to some of the history data, or if you haven’t planned for it to not explicitly capture the actual user executing the workflow. 

Keep in mind if you are building and testing your workflow under the administrator account you might not ever notice this.  However, knowing about this issue you can set up an InfoPath form and at least capture the name of the user who actually acted on the associated workflow.