Monday, June 29, 2015

Web Part Error when trying to view the Nintex Workflow Administration reports

Today I had to do a brand new installation of Nintex Workflow 2013 over SharePoint 2013 SP1.

After following the guide from Nintex, all worked well, except viewing the Administration reports.

This page is part of the Workflow Report Center and contains 10 different reports which are quite useful and they pertain to all sites within the entire SharePoint environment.

So the issue is that whenever you go to the highlighted link in the Nintex Workflow Management section in Central Admin:

You'd end up getting this:


1. Open IIS Manager on the SharePoint server.
2. Navigate to the SharePoint Central Administration v4 Site and go to Explore.
3. Open the Web.config file after backing it up and add the two lines below before closing the tag </SafeControls>
4. Save web.config and refresh the Administration reports page.

<SafeControl Assembly="Nintex.Workflow.ServerControls, Version=, Culture=neutral, PublicKeyToken=913f6bae0ca5ae12" Namespace="Nintex.Workflow.ServerControls" TypeName="*" Safe="True" />
<SafeControl Assembly="Nintex.Workflow.ServerControls, Version=, Culture=neutral, PublicKeyToken=913f6bae0ca5ae12" Namespace="Nintex.Workflow.ServerControls.WebParts" TypeName="*" Safe="True" />

You should be able to deep dive into the Nintex Reporting functionalities now.

Friday, June 19, 2015

The Query String (URL) Filter Connections

That is a quite useful webpart... as MVP Laura Rogers  blogged in a series of posts a while ago.
I'll just mention what happens when you try to move it over, as it simply doesn't work as you'd expect it to work.

Today I've tried to bring accross a Team Site from SharePoint 2013 On-premise to SharePoint Online by using ShareGate Migration. *Almost* everything went well and I decided to do some sanity checks on basic functionalities of the site.

The one thing that's heavily used is a Client List solution that is implemented in the following way:

Page A: A web part page, containing a number of List View webparts, each of them containing different pieces of information related to specific clients, let's say client documents and key contacts.

Client Documents and Key Contacts, for example are separate lists, each of which has an identical column, called "Client" of type "Choice" Each item in those lists is associated with one client only.

Page B: A page with only one list view webpart, visualizing a list called "Clients", with a search box and some groupings which are collapsed so that the whole list of clients is not displayed by default.

The "Clients" lits has a column called "Link", of type guess what (Yes, Hyperlink or Picture of course) which supposed to take you to information for *only* that client on Page A by filtering all webparts on Page A, based on their "Client" column's value - it should be matching the value inserted in "Link". That is achieved through the Query String (URL) Filter webpart.

The format of the link is:  http://intranet/sites/teamA/clientlist.aspx?Client=NameofTheClient.

When this is clicked (that's what people do when they find the needed result), they're taken to Page A (clientlist.aspx) and view all info related to the client, with all other clients' data filtered out. Great, isn't it?

So, that was working well on the SharePoint 2013 on-prem, but not in Office 365 as I've tested it now post-migration.

The Query String (URL) Filter webpart is inserted on Page A. It's only visible in Edit Mode and it was visible on the page when I went to edit it. But the functionality that we used to have on premise was not working, when clicking on the "Link" column on Page B, I was taken to Page A, but totally unfiltered and seeing a bunch of data for a number of clients - not what I needed in order to find something quick. And the reason struck me immediately:

It seems the webpart connections are not brought over! I've tried exporting the webpart and importing it manually - still the same thing. The only thing that came over is the "source" of the filter parameter. Let's imagine that one was gone too, so we'd start nice and clean by readding our webpart:

Go to "Add Web Part" and locate the Query String (URL) Filter under the Filters category:

That's how the vanilla version looks like:

Open the tool pane to configure it and choose a meaningful name of your choice for the filter and the parameter that you'll be passing in the query (in our case Client):

Now we've got to add the connections. In our case those are 10+ lists but for the example, let's say we'd just need to apply the value to the Client Documents list:

On the next screen, choose "Get Filter Values From" and press the "Configure" button:

Choose the target list column that you'd like to use for filtering:

Done. The webpart will now show you the connection(s) rather than the annoying "Unconnected" warning:

Hope that was useful for you if you're tasked with migrating some solutions based on these webparts in your daily work. The interesting outstanding question is where are these connections stored when they're not coming over with the webpart itself? I'll be glad if someone posts a comment with an answer on that mistery.

Friday, June 5, 2015

SSRS Reports unloaded after SharePoint 2013 SP1 upgrade

This gloomy Friday morning I've had a look at the homepage of an Intranet that had SP1 applied last night and I found this on all webparts that had rdl files loaded in them (SSRS reports) and were displaying perfectly fine yesterday.

Not a big deal, if you have the .rdl files in hand :) Just load them again. But has anyone experienced such a problem and have any idea why it happened? I don't.. and unfortunately don't have the time to investigate it properly. The SP1 upgrade went fine with all psconfig steps completing in success.