sharepoint

There’s quite a bit of documentation and confusion
around SharePoint Designer workflows and the context under which they
run. I’d naively assumed that Workflows would run in the context of the
user that initiated the workflow, but with system user permissions.

This didn’t help me, as I’d got some ‘working’ workflows that, once tested with
a non-privileged user simply didn’t complete, as they hit permissions issues.

The specific issue was that these users have the ability to add into a list,
but not edit, delete or approve, as the entry into the list is via a complex
InfoPath form. Workflow actions occur on addition to the list to route
the request to an appropriate approver, and kick of an escalation process.

It appears that SharePoint 2010 has a new Impersonate feature in Workflow, but hey – I’m
still using 2007, and am ‘specifically’ using SharePoint Designer (for business
compatibility purposes). I’ve used a lot of third-party SPD Workflow actions
from Nick Grattan, I Love SharePoint, and wasn’t about to be beaten,
as I can currently do everything I need from SPD Workflows.

I finally found a solution that did exactly what I needed).

Though vigorous googling, I found in the comments of the Useful
SharePoint Workflow Activities, that people were complaining
that the ‘Start a Workflow‘ action was running the new workflow as the
system user. Not me! – that’s exactly what I need.

I downloaded and installed the activities, but had to apply another update to get them to work properly in
SharePoint Designer.

I now have a new ‘wrapper’ workflow, which is automatically called on ‘new
item’ to the list, and this calls the 2 existing workflows (now manually
started), that were previously set to be automatic.

This has had an added benefit, in that the ordering of these workflows is now
consistent as one is called after the other. The only thing to bear in
mind of course is whether this behaviour is what you want, based on your
situation.

This problem happens because Sharepoint has its own variable named ID
which it uses to identify documents/pages on the server. Our solution
should not be using a variable named ID.

I changed my QueryString parameter to RequestID instead and all was good, apart from the thought of why the other page still worked fine.

I then realised that if it didn’t know what list it was trying to target, then the ‘List’ querystring parameter needs to be there too – as per other ‘application page’ requests in the _layouts folder, like approve/reject.

It then became obvious that I was doing too much work anyway:

Passing in the List as well as the ID allows you to then just get straight to the list item with the following code…

SPListItem item = (SPListItem)SPContext.Current.Item;

as the List and ID are already taken care of. A little neater than what I ‘was’ doing….

I recently needed to take a simple InfoPath form and surface that through a ‘themed’ SharePoint page. It’s possible to load the form in a browser without needing a specific page, but this effectively eliminates your master page from the equation.

Nick Grattan wrote an excellent paper on using the XmlFormView control to contain InfoPath forms on SharePoint webpart pages.

This is all great until you then need to send in input parameters to the form. I looked around for quite a while before I found the (rather obvious) Initialize event allows you to set the Input parameters of the form. All other methods of loading the form (InfoPath client, FormServer.aspx) use a querystring-style format.

The following code should do the trick in the case where you’re passing information from a current ‘list item’ to the form:

I discovered that in order to write code in a WebPart page (using SharePoint Designer)
you’ll need to add a PageParserPath to the web.config as follows – otherwise you’ll get an error saying something like ‘code not allowed in this page’. I’ve got a folder called ‘WebPages’ that houses the page. The standard web.config already has the PageParserPaths element:

NOTE: If you’re showing/hiding the form based on a flag/checkbox etc in the page (I’m doing this), then make sure you wrap the XmlFormView in a container Panel/div that you show/hide server-side, rather than showing/hiding the XmlFormView itself. For some reason this doesn’t seem to work properly (at least in FireFox).

In the end the missing link (that I failed to read) from the Microsoft doc was simply that the Single Sign-on Windows service needed to be running with a domain account (I chose the same as the administrator accounts), and it then worked fine.