I have this requirement as part of a site that will be built specifically for external users in SharePoint Online.
It's basically an automation need for users to be granted access to certain areas of the site by adding them to appropriate SharePoint Online groups. Users should also be automatically created by a workflow when their details are picked up from a list.
I've done an attempt to do this in SharePoint Designer, but it turns out there's no such action in there.
A couple of alternatives exist - Nintex Workflow which I have in place and Plumsail Workflow Action Pack which I don't have in place but a quick overview can be found on their website.
With Nintex, there is the handy action "Office 365 add user to group", which is usually working well. For external users, however, I found it impossible to resolve them like any Office 365 user.
I understand this might be due to the licensing part of the whole picture (external users can't be assigned a SharePoint Online license), but I am hoping that Nintex would address this issue in any of the future releases.
The only alternative I found so far is to create this user in the Office 365 tenant, assign a license to it (all automated through the workflow) and then add it to the group. Unfortunately, my requirements involve no licensing for such users, so I'll have to find another possible automation approach.
Has any of you managed to accomplish this? Would be happy to hear oppinions.
Monday, August 17, 2015
Thursday, August 13, 2015
Sync Excel Tables to a SharePoint List
Update: This doesn't work anymore with the release of Excel 2016. All previous versions of Excel still support it.
I have this requirement as part of a large process automation project for an international company operating in construction. OK, well the requirements never come in that clear - "sync" is not used. The goal is to have a SharePoint 2013 list, populated with data from an Excel 2007 spreadsheet.
Then part of the data would be picked up by a workflow and some of the data will be edited with human interaction during the process. At the end, the data should be in a compatible format to use with a reporting system such as SSRS or PowerPivot for SharePoint Server. That's another topic.
There are several approaches that we can take to achieve the first and most important goal - get the spreadsheet data into a SharePoint list. While the data can be easily exported from Excel (2013) to a SharePoint list quite quickly, there's no way to update it through Excel afterwards. It's a one-off solution which won't add value to this project at all.
I'll just show how that simple option works in Excel 2013 (it works in previous versions, too).
Before starting anything, please have in mind that you can only get the data into a SharePoint list if it's formatted as a table, that won't work for just about any spreadsheet. But we'll start with "any spreadsheet" :) In our scenario, we have a group of employees that might be new hires and we need to get them in a list, so we can possibly start a workflow that will do all the things associated with the new hires - e.g. assign them a telephone number, create an account in Active Directory, etc. The workflow is another topic which we won't discuss, but the main point is that's a common scenario.
Organizations usually transition from paper-based process through Excel spreadsheets to an automated software solution at the end.
Today we are lucky to have 7 new hires across different departments. We got this nice little spreadsheet from HR and we want to create a pilot list called "Employees" in our brand new SharePoint Online environment. It will work in the same way if the environment was SharePoint Server 2013 on-premise anyway.
I have this requirement as part of a large process automation project for an international company operating in construction. OK, well the requirements never come in that clear - "sync" is not used. The goal is to have a SharePoint 2013 list, populated with data from an Excel 2007 spreadsheet.
Then part of the data would be picked up by a workflow and some of the data will be edited with human interaction during the process. At the end, the data should be in a compatible format to use with a reporting system such as SSRS or PowerPivot for SharePoint Server. That's another topic.
There are several approaches that we can take to achieve the first and most important goal - get the spreadsheet data into a SharePoint list. While the data can be easily exported from Excel (2013) to a SharePoint list quite quickly, there's no way to update it through Excel afterwards. It's a one-off solution which won't add value to this project at all.
I'll just show how that simple option works in Excel 2013 (it works in previous versions, too).
Before starting anything, please have in mind that you can only get the data into a SharePoint list if it's formatted as a table, that won't work for just about any spreadsheet. But we'll start with "any spreadsheet" :) In our scenario, we have a group of employees that might be new hires and we need to get them in a list, so we can possibly start a workflow that will do all the things associated with the new hires - e.g. assign them a telephone number, create an account in Active Directory, etc. The workflow is another topic which we won't discuss, but the main point is that's a common scenario.
Organizations usually transition from paper-based process through Excel spreadsheets to an automated software solution at the end.
Today we are lucky to have 7 new hires across different departments. We got this nice little spreadsheet from HR and we want to create a pilot list called "Employees" in our brand new SharePoint Online environment. It will work in the same way if the environment was SharePoint Server 2013 on-premise anyway.
First we'd format this as a table, in order to be able to even get to the "Export" button:
We now have the Export button, under the "Table Tools" section on the ribbon and we can choose the "Export Section to SharePoint List" option.
You get prompted for the URL of the SharePoint site and the name of the list that would be created for the table data:
A summary of the fields that will get imported.
Nice to know is that only one the following types will be assigned to the columns in SharePoint:
- Text (single line)
- Text (multiple lines)
- Currency
- Date/time
- Number
- Hyperlink
If a column has cells with different data types, Excel applies a data type that can be used for all of the cells in the column. For example, if a column contains numbers and text, the data type in the SharePoint list will be text.
Here are the results when that sync finishes. A nice little message in Excel:
A newly created list in our target SharePoint site:
Our employees are ready to jump into the complex workflow process to follow :) More on that will follow in one of the next posts likely if/when we get this project rolling out live. Now it's only a PoC.
More on this basic one-way sync can be found on this Excel 2007 Support article
Now let's talk about the second solution... which will enable us to store the Excel data... and sync it from Excel anytime at a later stage. Out of the box that's not available in Excel or SharePoint.
But there's a good add-in for Excel 2007 (great as our customer is on Excel 2007, and I've found it working well on Excel 2013, too). The add-in was available for Excel 2007 and later on deprecated.
You can still find it here and use it (for free of course) if it matches your organization's needs.
When you download and extract this, you simply get a macro-enabled Excel 2007 workbook called SynchronizeWSSandExcel.xlam. Start that one and enable macros. Then get your table in. Don't forget to format it as a table, as in the previous approach, the same requirement is valid here.
Then go to the Design tab under Table Tools and you'll find a brand new button - "Publish and allow Sync":
When you click it, the dialog box looks similar to the previous one, but it's a 1-step process this time. Doesn't get any sweeter than this (I'll just call my list New Hires as the Employees is already taken):
The outcome is the same as solution 1:
But we now have the ability to change the data... let's say Jack D needs to move from the IT department to Developers, we can change that and then synchronize the changes to the SharePoint list from Excel without the need to even open SharePoint. You just change the cell data, use the "Synchronize with SharePoint" option and your list will be updated.
In one of the next blog posts I'll talk about a couple of other approaches.. which are in fact the a lot more sophisticated and, but involve a significant cost that involves the need of SharePoint Server Enterprise Edition and a 3rd party workflow product or some custom coding to call the Excel Web Services.
Tuesday, August 4, 2015
Issues when requesting the Search Results page with no query in SharePoint 2010
After some vacation time in July I'm back to share some of the experiences with SharePoint, this time from the backlog I have for posting here. Although SharePoint 2010 mainstream support will expire soon (Oct 13, 2015) there are still a number of customers using it.
For one of our clients, we've had to design a custom big shiny button that leads to their Search Center (read: Results page) but without the need for users to type in any query before hitting the button. Something similar to this, in the middle of a Publishing page where we've removed the default Search Box webpart on the client's request.
That's a quick and easy thing, if we don't count the numerous design iterations that we've done of course. Once implemented in the test environment though, we have faced some issues.
Whenever you try to search for a keyword, nothing happens. Your Search Query box is reset to empty. So you try again... and again. This was a very intermittent behavior, after some time... it will eventually work. It was also working always for admin accounts. The ULS logs would show:
System.Runtime.InteropServices.COMException: The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again. at Microsoft.SharePoint.Library.SPRequestInternalClass.ValidateFormDigest(String bstrUrl, String bstrListName) at Microsoft.SharePoint.Library.SPRequest.ValidateFormDigest(String bstrUrl, String bstrListName) 7ee02ec8-2297-4816-b3c8-b31f0150d81d
Initially one would think to disable the Web Page Security Validation on the web application... which is totally not a good idea and brings more issues when trying to save site as templates, etc.
After a lot of digging, I've found no way of fixing this, so we've changed the behaviour of the Search button to not go to the results page directly with no query, but instead require the user to input a query before that.
Now that works fine and everyone's happy. Not sure if this is by design, but out of the box Search Webparts would require you to type your query before you can go to the results, so it might be.
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:
Solution:
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=1.0.0.0, Culture=neutral, PublicKeyToken=913f6bae0ca5ae12" Namespace="Nintex.Workflow.ServerControls" TypeName="*" Safe="True" />
<SafeControl Assembly="Nintex.Workflow.ServerControls, Version=1.0.0.0, 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.
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:
Solution:
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=1.0.0.0, Culture=neutral, PublicKeyToken=913f6bae0ca5ae12" Namespace="Nintex.Workflow.ServerControls" TypeName="*" Safe="True" />
<SafeControl Assembly="Nintex.Workflow.ServerControls, Version=1.0.0.0, 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:
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:
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):
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.
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.
Thursday, May 7, 2015
Cannot Edit Content Query Webpart
One of our clients who use SharePoint 2010 as a publishing solution (Internet) had an issue where they suddenly couldn't edit a content query webpart on a publishing page. The webpart can be added and displayed correctly, but not edited. It's slightly customized, containing a predefined query that's grabbing items from a list. Trying with a vanilla CQWP didn't make any difference though. Creating a new page and trying the same still did not succeed.
Whenever they tried to edit the webpart, they'd get Unexpected Error.
Looking at the ULS logs, I stumbled upon this:
System.Xml.XmlException: Reference to undeclared entity 'nbsp'. Line 1027, position 40.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.HandleGeneralEntityReference(String name, Boolean isInAttributeValue, Boolean pushFakeEntityIfNullResolver, Int32 entityStartLinePos)
at System.Xml.XmlTextReaderImpl.ResolveEntity()
at System.Xml.XmlLoader.LoadEntityReferenceNode(Boolean direct)
at System.Xml.XmlLoader.LoadNode(Boolean skipOverWhitespace)
at System.Xml.XmlLoader.LoadDocSequence(XmlDocument parentDoc)
at System.Xml.XmlDocument.Load(XmlReader reader)
at System.Xml.XmlDocument.LoadXml(String xml)
at Microsoft.SharePoint.Publishing.WebControls.CmsDataFormWebPart.GetXslFile(String templateFileUrl)
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart.createItemStyleList()
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart.get_ItemStyleList()
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart.createAllSlotNames()
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart.get_AllSlotNames()
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryToolPart.createFieldsToDisplayControlGroup()
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryToolPart.createConfigureLayoutSectionControls()
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryToolPart.CreateChildControls()
at System.Web.UI.Control.EnsureChildControls()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
So it seems somebody tried to insert an interval somewhere along the customizations. Looking further into the error, it seems it comes from the ItemStyle stylesheet. I grabbed it from the farm and saw there was &nbsp; at one location. By default, the would not be rendered when inserted in the XSL.
There are three quick ways to overcome this.
1. Change to  
2. Change   to <![CDATA[ ]]>
3. Insert this in the XSLT file:
<!DOCTYPE xsl:stylesheet [ <!ENTITY nbsp " "> ]>
We chose solution 1 and it works like a charm. Content Query webparts can now be edited,.
Whenever they tried to edit the webpart, they'd get Unexpected Error.
Looking at the ULS logs, I stumbled upon this:
System.Xml.XmlException: Reference to undeclared entity 'nbsp'. Line 1027, position 40.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.HandleGeneralEntityReference(String name, Boolean isInAttributeValue, Boolean pushFakeEntityIfNullResolver, Int32 entityStartLinePos)
at System.Xml.XmlTextReaderImpl.ResolveEntity()
at System.Xml.XmlLoader.LoadEntityReferenceNode(Boolean direct)
at System.Xml.XmlLoader.LoadNode(Boolean skipOverWhitespace)
at System.Xml.XmlLoader.LoadDocSequence(XmlDocument parentDoc)
at System.Xml.XmlDocument.Load(XmlReader reader)
at System.Xml.XmlDocument.LoadXml(String xml)
at Microsoft.SharePoint.Publishing.WebControls.CmsDataFormWebPart.GetXslFile(String templateFileUrl)
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart.createItemStyleList()
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart.get_ItemStyleList()
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart.createAllSlotNames()
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart.get_AllSlotNames()
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryToolPart.createFieldsToDisplayControlGroup()
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryToolPart.createConfigureLayoutSectionControls()
at Microsoft.SharePoint.Publishing.WebControls.ContentByQueryToolPart.CreateChildControls()
at System.Web.UI.Control.EnsureChildControls()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
So it seems somebody tried to insert an interval somewhere along the customizations. Looking further into the error, it seems it comes from the ItemStyle stylesheet. I grabbed it from the farm and saw there was &nbsp; at one location. By default, the would not be rendered when inserted in the XSL.
There are three quick ways to overcome this.
1. Change to  
2. Change   to <![CDATA[ ]]>
<!DOCTYPE xsl:stylesheet [ <!ENTITY nbsp " "> ]>
We chose solution 1 and it works like a charm. Content Query webparts can now be edited,.
Subscribe to:
Posts (Atom)