We use Nintex Workflow all of the time. It compresses project times, and reduces, if not eliminates the need to develop custom code. One of the problems that we run into though is that the Approval workflow that comes out of the box appears to be hard wired for the SharePoint approval process.
As it turns out, it doesn’t need to be. Christian from iLoveSharePoint has a great solution that lets us replace the built in workflow with a Nintex workflow. It would also work for workflows built with SharePoint Designer. As opposed to rewriting it, I’ll just say that you can link to it here:
I will add two things to it. Christian has some sample code that if you just copy and paste won’t work due to wrapping, etc. Here’s what the code should look like:
#workflow must be associated with the target list
$workflowFileName = "Nintex Test.xoml"
$targetListTitle = "MyListName"
if($item.DisplayName -eq "$($workflowFileName).wfconfig")
$binFile = $item.File.OpenBinary()
$wfConfig = [xml][System.Text.Encoding]::UTF8.GetString($binFile)
$baseId = [Guid]$wfConfig.WorkflowConfig.Template.BaseID
$library = $web.Lists[$targetListTitle]
$assoc = $library.WorkflowAssociations.GetAssociationByBaseId($baseId)
$library.DefaultApprovalWorkflowId = $assoc.Id
He also mentions one way to get the GUID of the Workflows list. You can also get it by navigating to it with SharePoint Designer, drilling down into your declarative workflow, and opening the workflowname.xoml.wfconfig.xml file, and looking for the DocLibID tag.
I ran into a nasty little problem at a client site this morning. I had just finished setting up Reporting Services on a SharePoint Foundation front end server and everything was working just fine. The client had asked for a central site to store reports by default, so I of course created a new blank subsite called Reports (creative, right?). However, immediately after the site was created, I got this error:
“This operation is not supported on a report server that is configured to run in SharePoint integrated mode. (rsOperationNotSupportedSharePointMode)”
That’s a reporting Services error – why am I getting this from SharePoint? Of course I wasn’t. When I had configured Reporting Services, I had also configured the Virtual Directories for the Reporting Services web services, and for the Report Manager, which is unused in Integrated mode. I allowed the default values for both to be used, which are ReportServer and Reports respectively.
That was of course my problem http://servername/Reports was already a valid URL so instead of going to my newly created site, it tried to access the Reporting Services URL, which doesn’t work in integrated mode.
Fixing this was a little bit tricky. The first part was easy, create a site that isn’t named either Reports or ReportServer,and set it up. The tricky part was deleting a site that I couldn’t navigate to. It would be easy with Server,but this was Foundation. SharePoint designer did the trick nicely. With a site open, you can manipulate sites one level down, and I was able to delete the offending site.
The moral of the story? Be aware of existing virtual directory names when creating subsites on the same server.
SharePoint designer 2010 has changed quite a bit from its predecessor – certainly on the UI side. In other ways it has remained the same (its occasional inability to tell whether or not a file is checked out is still very annoyingly persistent). One of the major changes was how it handles .aspx page editing.
Previously SPD2007 had the concept of advanced editing, and a more locked down standard editing environment. This was controlled BY aven’t been able to find an application option to change the behaviour of the “Edit file” link on the information screen. If you’re working on a web site, the advanced mode results in an awful lot of extra clicking, and an awful lot of cursing after being presented with yellow highlights.
If there’s something that I’m missing here, please feel free to fill me in!
Anyone that’s worked with SharePoint 2007 or WSS 3.0 and SharePoint Designer, and is moving to SharePoint 2010 might be a little confused about how to get the new Designer client. Previously, it was (and still is) delivered through MSDN, but after the announcement that it was made free of charge, it was made available for general download.
SharePoint Designer 2010 is ONLY available through public download. You can find the home page for the product here, and download links for both 32 bit and 64 bit are at the bottom of the page.
There are a few important usage notes here. Firstly, SharePoint Designer 2010 works ONLY with SharePoint 2010 sites (not 2007 sites). Designer 2007 works only with 2007 sites, and not at all with 2010. Therefore, if you find yourself like I do in a situation where you need to support both environments, you’ll need to keep both installed side by side.
This however brings up another issue. The bit level of all Office applications need to be the same. SharePoint Designer is an Office application, and Designer 2007 only had a 32 bit version. In this scenario, you are restricted to the 32 bit version of Office 2010. In truth,this isn’t much of a restriction,and Microsoft itself suggests that you use the 32 bit version of office unless you have a compelling need for 64 bit. The 32 bit version is more compatible with add-ins, etc.