Getting the Current User's SharePoint Group Names In - SharePoint 2010, InfoPath 2010

Getting the Current User's SharePoint Group Names In - SharePoint 2010, InfoPath 2010

Since I did not write a post about SharePoint 2010 for some time, thought to write a pretty interesting post about how to get the logged in user's SharePoint group name using InfoPath functionalities. And for those who don't like to do some coding to get the thing done, they will surely like this approach. Since this is going to to be a longer post, I think it's better to go as a step by step approach, so I will start from Step 01.

Step 01.

Select the Custom List and on Ribbon under List click Customize Form. Then the List will be opening in the Microsoft InfoPath Designer 2010 .

Step 02.

Click on Manage Data Connections in InfoPath Designer. Then add two receiving data connections as following.

• First we will add a receiving data connection for web service UserProfileService.

Receive Data Connection for UserProfileService

SOAP Web Service

• In the text box type, http://ServerName/_vti_bin/UserProfileService.asmx.

UserProfileService.asmx?WSDL

• From the list of web methods, select GetUserProfileByName.

Web Method - GetUserProfileByName

• Click Next and you'll be asked for set the value for Account Name, leave it blank as doing it would get the current User.

AccountName - Leave it blank

• Tick Automatically retrieve data when the form is opened.

Tick - Automatically retrieve data when the form is opened

• Click Finish.
• Then let's start creating the receiving data connection for web service UserGroup.

Receive Data Connection for UserGroup

SOAP Web Service

• In the text box type, http://ServerName/_vti_bin/UserGroup.asmx.

UserGroup.asmx?WSDL

• From the list of web methods, select GetGroupCollectionFromUser.

Web Method - GetGroupCollectionFromUser

• Click Next. You will be asked to set sample value for UserLoginName. In that screen click Set Sample Value and in the appearing box type domain\Administrator.

userLoginName - Domain\Administrator

• Click OK and Next. In the appearing screen Untick Automatically retrieve data when the form is opened.

Untick - Automatically retrieve data when the form is opened

• Click Finish. Now you have successfully created two receiving data connections.

Step 03.

Now we will have to modify the xml schema for GetGroupCollectionFromUser data connection. For that we we will need to extract the InfoPath form. To extract the form, in InfoPath form go to File and Publish and then Export. Select a Folder to export the files and the form will be extracted.

Export

Step 04.

Now when the form has finished exporting, go to the folder you have selected. You will see a list of files that has been created in Export process.  But in our case we only focus on GetGroupCollectionFromUser.xsd (the xml schema for GetGroupCollectionFromUser data connection).

Exported Files

• First Close the InfoPath Designer. Because you can't edit files when are being used by the InfoPath designer.
• Open GetGroupCollectionFromUser1.xsd in a text editor (I prefer Notepad++) and edit it as below.
• Find the following line. Normally it's the 2nd line of the file.

                <s:import namespace="http://www.w3.org/2001/XMLSchema">

• Add following below above line.

<s:complexType name="GetGroupCollectionFromUserType">

    <s:sequence>

      <s:element minOccurs="0" maxOccurs="1" name="userLoginName" type="s:string"/>

      <s:element minOccurs="0" maxOccurs="1" name="Groups">

        <s:complexType>

          <s:sequence>

            <s:element maxOccurs="unbounded" name="Group" >

              <s:complexType>

                <s:attribute name="ID" type="s:unsignedShort"></s:attribute>

                <s:attribute name="Name" type="s:string"></s:attribute>

                <s:attribute name="Description" type="s:string"></s:attribute>

                <s:attribute name="OwnerID" type="s:unsignedByte"></s:attribute>

                <s:attribute name="OwnerIsUser" type="s:string"></s:attribute>

              </s:complexType>

            </s:element>

          </s:sequence>

        </s:complexType>

      </s:element>

    </s:sequence>

  </s:complexType>

• Find the following part.

<s:element name="GetGroupCollectionFromUser">

   <s:complexType>

     <s:sequence>

  <s:element minOccurs="0" maxOccurs="1" name="userLoginName" type="s:string">

         </s:element>

</s:sequence>

    </s:complexType>

  </s:element>

• Replace it with the following code.

<s:element name="GetGroupCollectionFromUser" type="tns:GetGroupCollectionFromUserType">

</s:element>

Step 05.

Now right click on the manifest.xsf and choose Design. Choose GetUserProfileByName data connection and apply rules on the PropertyData field as following.

• In Fields bar click on Show Advanced view.

Advanced view of Fields

• Under Fields Select GetUserProfileByName (Secondary).
• Then Add a rule. 

GetUserProfileByName (Secondary)

• The rule condition is Name="AccountName", rule type is Action.

Select a field or group

GetUserProfileByName - Name

Type Text

• Type "AccountName".

Type "AccountName"

•  The rule actions are:
• Set field’s value. Under Field, Set Field as follows.

GetGroupCollectionFromUser (Secondary) - Name

• Then Under Value, Set Value as follows. Click fx and then Insert Field Or Group.

GetUserProfileByName - Value

• Don't Click OK yet. Click Filter Data. The Click Add.

Select a field or group

GetUserProfileByName - Name

• Click OK.

Type Text

Type "AccountName"

• Click OK. Then you will get something like this.

Complete Formula (fx)

• Click OK.

• Then add another Action. Action is Query for data from GetGroupCollectionFromUser. 

Query for data - GetGroupCollectionFromUser

• Click OK.

Step 06.

Now create a formatting rule for a field that you want to disable/hide if current user is not member of a given SharePoint Group. Put a condition as below, where the "LCGD Clerk" is the SharePoint Group Name.

Select a field or group

• Set the Name in GetGroupCollectionFromUser (Secondary Data source).

GetUserProfileByName - Any occurrence of Name

Type "LCGD Clerk" (SharePoint Group Name)

Step 07. 

Now Everything is completed. Final step is Publish the form.

Difference between Team-Site and Publishing-Site in SharePoint

Team Site	Publishing site
Team Site is used for intranet sites.	Publishing site used for Internet sites.
There is no Publishing option in Team site.	Publish option is there in Publishing sites.
If you create the Page or edit any content in page it directly visible to end user.	If you create Page or edit any content in the page will not directly visible to end user, unless until you Publish the page.
By Default lists and templates are available (like:- survey list, announcement list, task list, promoted links list)	By default lists and templates are not available (like:- survey list, announcement list, task list, promoted links list). To enable this list we need to activate "Team Collaboration Lists" feature.
Team site has a couple of text Page-layouts	Publishing site have much more complex page layouts

How-to Read an XML / InfoPath Form Values and Upload to Word Document in Document Library using Nintex Workflow

Hi,

This article will help you to read InfoPath/XML fields using Nintex workflow after form created.

Create new workflow to the Form Library where your InfoPath will save and fallow the steps below.

Step 1:

Step 2:

Double click on "Query XML" box or click on Configure option in Query XML-menu.









Step 3:

Now you able to see below screen, in this you need to select XML- Source.
If you are working for the InfoPath in the current Form Library then select Current item or you can give XML file URL using URL or you can give direct XML source text using XML.

Step 4:

For example below is my XML format text in the InfoPath form.

Now you need to create Workflow variables to save each XML tag data like below.

You can Add. Delete and Modify the Variables by using below options.

Step 5:

Now close the Variable popup and come to Query XML setting.

In Output 1 tab select Xpath in Process Using: like below.

If you want to read multiple values just click on "+ Add Output" link and add few more Output fields like below.

Step 6:

Now you are ready with all variables which are having XML field values you can use this variables for your reqirement, just save the workflow and publish the workflow.

Here my requirement is like, i have to update a word document with this Output Variables so i updated like below.


First add Update Document action to workflow and open it.

 Need to pass your workflow variables into document Content Controle or (Quick Parts).

Now you are ready with your complete workflow, make this workflow to run at item created time,  save it and publish it.

I hope this will help you ......

Minimal Download Strategy (MDS) overview

Learn about Minimal Download Strategy (MDS), a new feature in SharePoint 2013 that reduces page load time by sending only the differences when users navigate to a new page.

In this article 

Enable MDS
Benefits of using MDS
MDS architecture
Developer controls
Additional resources

Minimal Download Strategy (MDS) is a new technology in SharePoint 2013 that reduces the amount of data that the browser has to download when users navigate from one page to another in a SharePoint site. When users browse an MDS-enabled site, the client processes only the differences (or delta) between the current page and the requested page. Figure 1 shows the sections that change from page to page and therefore require an update. The delta usually includes the data in the (1) content areas, as well as other components such as (2) navigation controls.

Figure 1. Page processed with MDS

You can identify a site that has MDS enabled by looking at the URL. An MDS-enabled site has the (3) _layouts/15/start.aspx page in the URL followed by a hash mark (#) and the relative URL of the requested resource, as shown in Figure 1. For example, the following is the MDS-formatted URL for the page newpage.aspx:

https://sp_site/_layouts/15/start.aspx#/SitePages/newpage.aspx

It is equivalent to the following non–MDS-formatted URL:

https://sp_site/SitePages/newpage.aspx

As a developer, you might have created SharePoint components that need some updates before they can work seamlessly with MDS.

Enable MDS

You can enable MDS in your site by using either the site administration pages or the SharePoint client object models.

To enable MDS by activating the feature in the administration pages, choose Site settings > Manage site features, and activate the Minimal Download Strategy feature.

Because the feature is activated by modifying the EnableMinimalDownload property, you can also use the client APIs. The following code shows how to enable MDS using the JavaScript object model (JSOM).

JavaScript

var clientContext;

clientContext = new SP.ClientContext.get_current();
this.oWebsite = clientContext.get_web();

this.oWebsite.set_enableMinimalDownload(true);
this.oWebsite.update();

clientContext.load(this.oWebsite);

clientContext.executeQueryAsync(
    Function.createDelegate(this, successHandler),
    Function.createDelegate(this, errorHandler)
);

function successHandler() {
    alert("MDS is enabled in this site.");
}

function errorHandler() {
    alert("Request failed: " + arguments[1].get_message());
}

Benefits of using MDS

Using MDS provides several benefits, including:

• Speed: This is the main objective of MDS. When you are using MDS, the browser doesn’t have to reprocess the chrome user interface (UI). MDS also reduces the payload compared to a full page load.
• Smooth transitions: By updating only the areas that change, you draw the user’s eye toward these areas, as opposed to a full page load where the whole page "flashes." When the whole page is updated, the user must parse it in its entirety to detect what is new. Users have an easier time navigating a site that only updates the areas that changed from the previous page.
• Browser navigation controls: Other AJAX-based systems confuse the previous and next buttons in browsers. Because MDS updates the URL in the browser window, the previous and next buttons work just as they are supposed to.
• Backward compatibility: The MDS engine either provides MDS navigation immediately or detects when it isn’t possible. In the case where MDS navigation isn’t possible, a full page load occurs instead. This process is called failover, and it ensures that all pages render properly regardless of whether they contain MDS-compliant components. MDS also works nicely with search engines because the href attribute of anchor tags uses the regular, non MDS-formatted URLs. Instead, the MDS engine in the client captures the onclick event and uses it to communicate with the server.

MDS architecture

The basic mechanics of MDS are pretty simple. The main components of MDS are two engines, one in the server and another in the client, that work together to calculate the changes and render the pages in the browser when the user navigates from page to page in the site. Figure 2 shows the MDS flow when a user navigates through an MDS-enabled site.

Figure 2. MDS flow when a user navigates the site

1. The browser requests the changes between the current page and a new one in the SharePoint site.
2. The MDS engine in the server calculates the delta between the current and the new pages.
3. The MDS engine in the server sends the delta to the MDS engine in the client.
4. The MDS engine in the client replaces the changed areas on the current page with the new page content.

The resulting page is exactly as it would have been if the page had been downloaded without MDS.

The MDS engine in the client includes a download manager. All requests in the page are routed through the download manager. All controls in the page must subscribe to the download manager to learn when a URL has changed. The download manager makes one request for all the new control data. To be able to work with search engines, the MDS engine doesn’t directly use the href attribute of anchor tags to store MDS-formatted URLs. Instead, the SPUpdatePage function handles the onclick event and uses it to communicate with the server. The SPUpdatePage function is declared in the _layouts/15/start.js file.

The MDS engine in the server sends the information back to the client. This information can contain HTML with embedded scripts and styles, XML, or JavaScript Object Notation (JSON).

The URL plays an important role in MDS. An MDS URL looks like the following: https://sp_site/_layouts/15/start.aspx#/SitePages/newpage.aspx.Start.aspx contains minimal shared UI and instructions for loading page changes. MDS considers the part following the hash mark (#) as the target page. The target page starts with a slash (/) followed by a URL relative to the SharePoint website. When the browser receives the URL, it sees that the part to the left of the hash mark hasn’t changed, so it fires a local navigation event. The MDS engine in the client captures the local navigation event and uses it to perform an MDS update.

As mentioned previously in this article, in some situations it’s not possible to determine whether the page can be updated properly. In these situations, the MDS engine issues a failover, which consists of an extra round trip to redirect the browser to the full version of the new page. These are the most common reasons why failover occurs:

• The new page has a different master page.
• The current master page has changed.
• The MDS engine detects non-compliant HTML, for example:
  • Pages using ASP.NET 2.0
  • CSS or scripts not registered in the MDS engine
  • Illegal HTML
• There are non-compliant controls on the page, for example:
  • The control is not in the MDS engine whitelist.
  • The control assembly is not marked as compliant.
  • The control class doesn’t have the MDS attribute.

The MDS engine tries to recover from a failover after the user navigates to yet another new page.

Developer controls

Thanks to the failover mechanism, your controls work seamlessly whether or not MDS is enabled in your users’ websites. However, it is a good idea to update your SharePoint controls and components to take full advantage of MDS. Users get a better experience when your pages and controls are MDS compliant. The following components are good candidates to get optimized for MDS:

• Master pages
• ASP.NET pages
• Controls and Web Parts

Configure a Content Search Web Part in SharePoint 2013

Display content by configuring a simple query in a Content Search Web Part

If the query that you want the Content Search Web Part (CSWP) to issue is simple, for example, if you want to limit search results to a result source or to a specific tag, then you’ll probably only need to use the configuration options on the BASICS tab.

1. Make sure that you’re a member of the Designers SharePoint group on the site that contains the CSWP.
2. Go to the page that contains the CSWP that you want to edit.
3. From Settings , select Edit Page.
4. In the Web Part, select the Content Search Web Part Menu arrow > Edit Web Part.
5. In the Web Part tool pane, in the Properties section, in the Search Criteria section, select Change query.
   A dialog box as shown in the image above opens. Here, you can configure the query as described in the following table.

Select a query	Select a result source to specify which content should be searched.
Restrict results by app	Select an option from the list to restrict results to a specific site, library, list, or URL.
Restrict by tag	You can limit results to content that is tagged with a term. Select one of the following: Don’t restrict by any tag Search results aren’t limited by a term. Restrict by navigation term of current page Search results are limited to content that’s tagged with the navigation term of the current page. The navigation term is displayed as the last part of the friendly URL. This option is only meaningful for sites that use managed navigation. Restrict bycurrent and child navigation Search results are limited to content that is tagged with the navigation term of the current page (displayed as the last part of the friendly URL), and content that is tagged with sub-terms of the current navigation term. This option is only meaningful for sites that use managed navigation. NOTE    In a cross-site publishing scenario, this selection will work only when the result source that you selected from the Select a query menu is the catalog result source that was created when you connected your publishing site to a catalog. Restrict on this tag Search results are limited to content that is tagged with the tag that you type inside the box.

Display content by configuring an advanced query in a Content Search Web Part

If the query that you want the CSWP to issue is advanced, for example you want to use Keyword Query Language (KQL) Syntax Reference, you’ll need to use the configuration options that are available in Advanced Mode on theBASICS tab.

When you configure the query in Advanced Mode, you can also use query variables. Query variables are placeholders that are replaced with values when a query is run. Examples of query variables are {User.Name}, which is a placeholder for the name of the user who is viewing the page, or {URLToken.1}, which is a placeholder for the first value in the URL as counted from right to left.

1. Make sure that you’re a member of the Designers SharePoint group on the site that contains the CSWP.
2. Go to the page that contains the CSWP that you want to edit.
3. From Settings , select Edit Page.
4. In the Web Part tool pane, in the Properties section, in the Search Criteria section, select Change query.
5. In the dialog box that opens, select Switch to Advanced Mode.
6. Configure your query as described in the following tables:

If the query that you want the CSWP to issue is advanced, for example you want to use Keyword Query Language (KQL) Syntax Reference, you’ll need to use the configuration options that are available in Advanced Mode on theBASICS tab.

When you configure the query in Advanced Mode, you can also use query variables. Query variables are placeholders that are replaced with values when a query is run. Examples of query variables are {User.Name}, which is a placeholder for the name of the user who is viewing the page, or {URLToken.1}, which is a placeholder for the first value in the URL as counted from right to left.

1. Make sure that you’re a member of the Designers SharePoint group on the site that contains the CSWP.
2. Go to the page that contains the CSWP that you want to edit.
3. From Settings , select Edit Page.
4. In the Web Part tool pane, in the Properties section, in the Search Criteria section, select Change query.
5. In the dialog box that opens, select Switch to Advanced Mode.
6. Configure your query as described in the following tables:

BASICStab
Select a query	Select a result source to specify which content should be searched.
Keyword filter	You can use keyword filters to add query variables to your query. For a list of available query variables, see Query variables in SharePoint Server 2013. You can select predefined query variables from the drop-down list, and then add them to the query by selecting Add keyword filter.
Property filter	You can use property filters to query the content of managed properties that are set to queryable in the search schema. You can select managed properties from the Property filter drop-down list. Select Add property filter to add the filter to the query.
Query text	Type your query by using Keyword Query Language (KQL), or use the Keyword filter and Property filter lists to build the query. The keyword query can consist of free-text keywords, property filters, or operators. Use braces to enclose query variables. Query variables are replaced with an actual value when the query is run. Keyword queries have a maximum length of 2,048 characters.

REFINERS tab

Use this tab if you want your search results to be limited to items that have one or more refiner values. The managed properties that are enabled as refiners in the search schema are listed in the Choose your refinerssection. Select a refiner value in the list, and then select Add to add it to the query. If you want search results to display as a group on one or more managed properties, select Show more. This is useful to display several variants for a given item, and want to group them under a single result.

SORTING tab

In this tab, you can specify how you want your search results to be sorted. The managed properties that are set as sortable in the search schema are listed in the Sort by drop-down list. From this list, select a managed property, and then select Descending or Ascending. To add more sorting levels, select Add sort level. If you selected Rank from the Sort by list, you can select which ranking model to use for sorting in the Ranking Model list. You can also add more rules and conditions by selecting Add dynamic ordering rule.

SETTINGStab
Query rules	Select if to use query rules.
URL Rewriting	Select if you want the URL rewrite to the item details page to be relative for each catalog item as defined when you connected your publishing site to a catalog. If you select Don’t rewrite URLs, the URLs for catalog items will point directly to the library item of the connected catalog.
Loading behavior	Select when you want the search results returned by the CSWP to appear on the web page. If you use the default option, Sync option: Issue query from the server, queries are issued from the server, and the search results are included in the page response that SharePoint returns. If you selectAsync option: Issue query from the browser, the queries are issued from the user’s browser after the complete page is received. You can use this option for content such as Recommendations or Popular Items.
Priority	Select the priority for content that’s displayed by this Web Part in relation to other Search Web Parts. If SharePoint is running under a heavy load, the queries will be run according to their priority.
Caching	Select one Active Directory security group if you want search results to be cached for users in the group. By caching search results for a security group, you can reduce page load time. NOTE    You should only select a security group where search results are identical for all users in the group. For more information, see this article.

TEST tab
In this tab, you can preview query details sent by the CSWP.
Query text	Shows the query that will be run by the CSWP.
Select Show more to display additional information.
Query template	Shows the content of the query template that is applied to the query.
Refined by	Shows the refiners applied to the query as defined on theREFINERS tab.
Grouped by	Shows search results that are grouped by managed property as defined in the REFINERS tab.
Applied query rules	Shows which query rules are applied to the query.
Query template variables	Shows the query variables that are applied to the query, and the values of these variables as they apply to the current page. To preview the results, select Test Query.
To test how the query works for different user segment terms, select Add user segment term. To preview the results, select Test Query.
Query text	Shows the query that will be issued by the CSWP.

Top of Page

Control how content is displayed in a Content Search Web Part

To control how content is displayed in a CSWP, you have to customize display templates.

Here are some examples of how content looks before and after applying a customized display template to a CSWP.

Before	After

To learn how to create a custom display template, see SharePoint 2013 Design Manager display templates.

Top of Page

Add a Content Search Web Part

1. Make sure that you’re a member of the Designers SharePoint group on the site where you want to add the Web Part.
2. Go to the page where you want to add the Web Part.
3. From Settings , select Edit page.
4. In the Zone where you want to add the Web Part, select Add a Web Part.
5. In the Categories list, select Content Rollup.
6. In the Parts list, select Content Search > Add.

Top of Page

About the Content Search Web Part

When visitors browse to a page that contains a CSWP, the Web Part automatically issues a query. The search results are displayed within the CSWP. In most cases, visitors won't even know that search technology is being used to display the content they're viewing. To them, it'll look and feel like any other webpage.

By configuring a query in a CSWP, you can define which content visitors will see when they browse to a page that contains a CSWP. By default, the query in the CSWP is configured to show the three most recently changed items on the site. By configuring the query, you can change the number of items that are shown in the CSWP and which content is shown. For example, you can configure the query so that the CSWP will show nine list items from a particular list, or the last six documents the visitor created in a document library.