Store the SharePoint filtered values

In case you have a view for your list and users use this view and filter its values and want to keep this filter saved without creating a personal view, you can create a JavaScript file with this content:

 

Then reference this JavaScript file from any page where you have your view. It is simply listen to the “onhashchange” and save the value after the “#” in the localStorage and retrieve it on next page load. The URL of the page after you change the filter looks like this: “/Lists/TestList/AllItems.aspx#InplviewHash6c224f7d-adc4-430c-8501-312cabe57c26=FilterField1%3DLinkTitle-FilterValue1%3DTest%2520Item” and the hash value is everything after the “#”

Nintex Repeating Section – JSLink

This blog post is building on top other posts by me and my friend Ayman El-Hattab, where in my post (Published April 9, 2015) I talked about creating master details records with repeating section in Nintex forms and Nintex Workflow, and how you can parse the repeating section data and use the information in a workflow “foreach” loop so you can create items in a separate list.

Ayman’s post (Published: Aug 4, 2015) is about displaying the repeating section data in the list view in an easy way, which is mainly by creating a custom field type (Nintex Repeating Section Data). He created two versions 2010 & 2013. But the only problem with this way is that you will need to deploy this field type first as a farm solution, which is not an option in some scenarios like O365 and organizations who do not allow custom server side deployments. Other than that it is a great and easy to use solution.

Why and What is JSLink

So this is why I build this JSLink to make it easy to deploy especially for O365, and if you are coming from Nintex side and don’t know what is JSLink, see this definition:

“Client-side rendering is a new concept in SharePoint 2013. It’s provides you with a mechanism that allows you to use your own output render for a set of controls that are hosted in a SharePoint page (list views, display, add and Edit forms). This mechanism enables you to use well-known technologies, such as HTML and JavaScript, to define the rendering logic of custom and predefined field types.” - Muawiyah Shannak - https://code.msdn.microsoft.com/office/Client-side-rendering-JS-2ed3538a (this link has a very good group of samples). You will also need to check the samples published on the Office 365 Patterns and Practices https://github.com/OfficeDev/PnP/tree/master/Samples/Branding.JSLink where they added some reusable templates.

List Column

Starting by creating a list column of type “Multiple lines of text” in the list where we have our Nintex form. Make it a “plain text” in the “type of text to allow”.

Repeating Section

On the form, drag and drop the repeating section and add the child controls as needed, in my example here I have three text boxes: First Name, Last Name, and Age as you can see below.

I also named the controls in the same order “First Name”, “Last Name”, and “Age”. And yes with the space between “First” and “Name” because this is how I want it to look like in the view.

Then connect the repeating section control to the multiple line field created in the first step.

The Repeating Section JSLink

Now it is the step where the JSLink will do its magic, I have three files deployed to the “Site Assets” library located in the root web in the site collection. (You can choose to upload these files anywhere but remember to change the URLs in the view web part and in the override JavaScript file)

The first file is the “NintexOverrides.js”, and as you can see below I am using the PnP namespaces, and this file mainly is telling SharePoint view that we have another rendering template for one or more fields in the view:

The next file is the “RepeatingSectionTemplate.js”, and I am using the PnP namespace as well. And the purpose of this file simply is to parse the repeating section XML and display HTML table instead:

The third file is “NintexOverrides.css” cascading style sheet to set how we want the table displayed in the view:

 

Deployment

Actually there is no deployment other than copying the three files to the site assets library then set the JS Link property by doing the following steps:

•  Browse to the view page where you want to apply this rendering (the list where the form with the repeating section is)
• Edit the web part:

• Scroll down to “Miscellaneous” then add “~sitecollection/SiteAssets/RepeatingSectionTemplate.js|~sitecollection/SiteAssets/NintexOverrides.js” in the “JS Link” property
• Click “Okay” then save the page “Stop Editing”

The Output

Now you have the repeating section as follows:

And adding more repeating sections is easy as adding more “Multiple lines of text” column and connect it to the repeating section control on the form, then the output will be something like this:

Then update the “NintexOverrides.js” file to list the new column as follows:

Now the output is like this:

Click here to download the three files mentioned above.

CREATING MASTER-DETAILS RECORDS WITH REPEATING SECTION IN NINTEX FORMS

Forms that have data in a relation of one to many or with master-details can be created using Nintex Forms plus Nintex Workflow. An example of this would be an order form that includes product details such as name, unit price, quantity, taxes and total price as well as  order date, billing and shipping options, and you need to submit both parts together by clicking one submit or save button.

With Nintex Forms, you can build the master part (the order in our example) as you would any other form, using the drag and drop controls, then connect them to the right column on your list, or just keeping them unconnected if you want some of them to be just on the form and not part of the list data. The details part (the products) can be formatted on the form using the Repeating Section control, where you only design how one row should look. Here is a simple example of a repeating section with the product name and the quantity:

As I mentioned above, you can connect your controls to list columns, but for the controls inside the repeating section you cannot connect them to list columns. Instead, you can only connect the repeating section as whole to a multi-line plain text column. The data will be saved as XML in this column like this:

In 2012, Vadim Tabakman posted a very good blog article about Parsing Repeating Section Data where he is reading the repeating section data without creating an extra column for the XML. He parses the XML in a user defined action – UDA - then uses the loop workflow action to query each item inside the repeating section using an incremental index. Vadim’s post includes an example form, workflow and even the UDA. In the comments, his blog followers mentioned that using the loop workflow action is taking too much time to execute. This is true because Nintex has a farm level option named “Safe Looping” which is on by default. Safe looping simply adds delay actions to your workflow at publishing time in certain places like change state and loop. Read more about it in another post written by Vadim on November 2012. Vadim suggested to me through Nintex support that using a "Foreach" action will solve the delay issue, because Nintex does not add the delay inside the Foreach action. Imagine submitting an order with 30 products using the loop action. It would take more than 2 hours to create the order related products in the second list, while it would only take a second using the Foreach action.

Adding to the same concept, I found this post by Erik Abderhalden about Best Practices with Repeating Sections in Nintex Forms, which has some useful information you may need to know. But in his example he is creating a separate column in the main list to hold the repeating section XML while you already have it in a hidden column named DataForm on the list which has the repeating section XML encoded. 

By the way, you can access any un-connected filed on the form from the workflow by querying this hidden column if you don’t want to have a separate column for it. The same, you can have the repeating section not connected to a column and be able to use the Foreach action instead of the Loop action. Here is what that workflow looks like:

As you can see, I am using a UDA to get a collection of XML items to use in the Foreach action, and I am recommending using it as it will keep your main workflow smaller and reduce variables.  Remember, you already need to create a lot of variables to handle the details part. Here is my UDA:

Get the encoded repeating section XML using the Query XML action, then decode it and add it to a collection variable. Instead of the “Log in History List” action, add your logic to create or update the items in the products list.

You can download a sample workflow and the user defined action plus the details of each action from the links below. So I am not going to go into details for each step, as I think the downloadable screens and the other blog posts mentioned earlier have enough information. If not, please feel free to post your question in the comments below.

Conclusion:

Repeating Section in Nintex Forms is a very useful control. Dealing with parsing its data from the workflow is not hard once you know how, and one way to get the information is searching online. And if you post a question on Nintex Connect or send it to Nintex support, they will answer you in a reasonable time frame.

ALTERNATE SOLUTION FOR THE ALTERNATE CSS URL IN SHAREPOINT 2013 ONLINE

Today RDA posted my first post on their blog. "ALTERNATE SOLUTION FOR THE ALTERNATE CSS URL IN SHAREPOINT 2013 ONLINE"

Please check and give me your feedback: http://www.rdacorp.com/en/Blog/2015/03/12/Alternate%20Solution%20for%20the%20Alternate%20CSS%20URL%20in%20SharePoint%202013%20Online

Error occurred in deployment step 'Install app for SharePoint': The provided App differs from another App with the same version and product ID

When you try to debug a SharePoint App from Visual Studio you may receive this error: "Error occurred in deployment step 'Install app for SharePoint': The provided App differs from another App with the same version and product ID" which means that your app is still on SharePoint somehow even if you can't see it in the Site Contents page.

To solve the issue you can check one or all of these steps:

1. Make sure that the App is removed from the site it is installed to. Go to Site Contents and find if it is there in an error state waiting for you to click on "Try again" to be deleted.
2. Remove the App from the site collection recycle bin if it is there (by default it will stay in the recycle bin for 93 days). This will move it to the Second-Stage recycle bin if you clicked on "Empty Recycle Bin" and will delete it if you selected the app and clicked on "Delete". (in all cases you will only find the App in the site collection recycle bin but the web site created for the App will be in the Second-Stage recycle bin, so every time you remove an App there will be one part in the first recycle bin and another part in the Second-Stage recycle bin, and restoring any of these parts will restore the other part).
3. Remove the App from the Second-Stage recycle bin.
4. If you still can't upload your App, repeat step 2 & 3 :)
5. If after step #4 you can't upload your App, go to the AppManifest.xml and change the Version (or the ProductID if you are still in the development)

You can get more information about Recycle Bin here : https://support.office.com/en-us/article/Manage-the-Recycle-Bin-of-a-SharePoint-Online-site-collection-5fa924ee-16d7-487b-9a0a-021b9062d14b?ui=en-US&rs=en-US&ad=US