SharePoint: Get User Profile Properties with REST API

In my last post SharePoint 2013: Working with User Profiles & JavaScript CSOM we saw how to get SharePoint UserProfile Properties using the JavaScript Client Object Model. In this post lets have a look at how to get them using the REST API. Here is a quick reference for the REST API endpoints.

(List of All User Properties and UserProfile Properties at the end of the post)

1) Get all properties of current user:

http://siteurl/_api/SP.UserProfiles.PeopleManager/GetMyProperties

2) Get single property of current user:

http://siteurl/_api/SP.UserProfiles.PeopleManager/GetMyProperties/PictureUrl
OR
http://siteurl/_api/SP.UserProfiles.PeopleManager/GetMyProperties?$select=PictureUrl

3) Get Multiple Properties for the current user:

http://siteurl/_api/SP.UserProfiles.PeopleManager/GetMyProperties?$select=PictureUrl,AccountName

4) Get all properties of Specific User:

For Office 365/SharePoint Online:
http://siteurl/_api/SP.UserProfiles.PeopleManager/GetPropertiesFor(accountName=@v)?@v='i:0%23.f|membership|vardhaman@siteurl.onmicrosoft.com'

For SharePoint 2013 On-Premises:
http://siteurl/_api/SP.UserProfiles.PeopleManager/GetPropertiesFor(accountName=@v)?@v='domain\username'

5) Get Specific UserProfile Property of Specific User:

For Office 365/SharePoint Online:
http://siteurl/_api/SP.UserProfiles.PeopleManager/GetUserProfilePropertyFor(accountName=@v,propertyName='LastName')?@v='i:0%23.f|membership|vardhaman@siteurl.onmicrosoft.com'


For SharePoint 2013 On-Premises:
http://siteurl/_api/SP.UserProfiles.PeopleManager/GetUserProfilePropertyFor(accountName=@v,propertyName='LastName')?@v='domain\username'

6) Get Multiple UserProfile Properties for Specific User:

Update (01/06/2016): Since the time I wrote this post, REST API batching has been implemented in SharePoint Online. As a result, we can make multiple REST requests to the GetUserProfilePropertiesFor function in a single REST call. This way, we can get Multiple custom/OOB UserProfile Properties for a Specific User without making multiple calls.

Here is my post on it:
SharePoint Online: Get UserProfile Properties with REST API Batching

Original Post Continues:

http://siteurl/_api/SP.UserProfiles.PeopleManager/GetUserProfilePropertiesFor

_api/SP.UserProfiles.PeopleManager/GetUserProfilePropertiesFor

As far as my research is concerned, this method is NOT supported in the REST API. The call to this method returns the following error:

"The method GetUserProfilePropertiesFor cannot be invoked as its parameter propertiesForUser is not supported."

If anybody finds any additional information on this, then I would love to update my blog on it. Here is my code for executing the above method:



-------

List of User Properties (Use the GetPropertiesFor function for these):

AccountName
DirectReports
DisplayName
Email
ExtendedManagers
ExtendedReports
IsFollowed
LatestPost
Peers
PersonalUrl
PictureUrl"
Title
UserProfileProperties
UserUrl

List of User Profile Properties (Use the GetUserProfilePropertyFor function for these):

AboutMe

SPS-LastKeywordAdded

AccountName

SPS-Locale

ADGuid

SPS-Location

Assistant

SPS-MasterAccountName

CellPhone

SPS-MemberOf

Department

SPS-MUILanguages

EduExternalSyncState

SPS-MySiteUpgrade

EduOAuthTokenProviders

SPS-O15FirstRunExperience

EduPersonalSiteState

SPS-ObjectExists

EduUserRole

SPS-OWAUrl

Fax

SPS-PastProjects

FirstName

SPS-Peers

HomePhone

SPS-PersonalSiteCapabilities

LastName

SPS-PersonalSiteInstantiationState

Manager

SPS-PhoneticDisplayName

Office

SPS-PhoneticFirstName

PersonalSpace

SPS-PhoneticLastName

PictureURL

SPS-PrivacyActivity

PreferredName

SPS-PrivacyPeople

PublicSiteRedirect

SPS-ProxyAddresses

QuickLinks

SPS-RegionalSettings-FollowWeb

SID

SPS-RegionalSettings-Initialized

SISUserId

SPS-ResourceAccountName

SPS-AdjustHijriDays

SPS-ResourceSID

SPS-AltCalendarType

SPS-Responsibility

SPS-Birthday

SPS-SavedAccountName

SPS-CalendarType

SPS-SavedSID

SPS-ClaimID

SPS-School

SPS-ClaimProviderID

SPS-ShowWeeks

SPS-ClaimProviderType

SPS-SipAddress

SPS-ContentLanguages

SPS-Skills

SPS-DataSource

SPS-SourceObjectDN

SPS-Department

SPS-StatusNotes

SPS-DisplayOrder

SPS-Time24

SPS-DistinguishedName

SPS-TimeZone

SPS-DontSuggestList

SPS-UserPrincipalName

SPS-Dotted-line

SPS-WorkDayEndHour

SPS-EmailOptin

SPS-WorkDayStartHour

SPS-FeedIdentifier

SPS-WorkDays

SPS-FirstDayOfWeek

Title

SPS-FirstWeekOfYear

UserName

SPS-HashTags

UserProfile_GUID

SPS-HireDate

WebSite

SPS-Interests

WorkEmail

SPS-JobTitle

WorkPhone

SPS-LastColleagueAdded

Include Caching in jQuery getScript

While going through some MSDN documentation on SharePoint 2013, I noticed that Microsoft has suggested to use the jQuery.getScript method to load the SP.Runtime.js and the SP.js files on the page.
For Example:



I did not think about this twice but when I actually brought this into practice, I noticed that the function was fetching the files every time the page would load. After a bit of digging in the jQuery documentation, I found out that this is because the jQuery.getScript function disables caching. It gets the fresh copy of requested files every time by appending a current time time stamp at the end of the file path. You can see the firebug screen-cap of the call here:

This is not good for us because I don't want to spend extra time getting a fresh copy of the file on every page load. We know that once the file is fetched, the browser caches it and maintains a copy if any further requests for the same file are made in the future. jQuery.getScript by default does not allow us to take the advantage of this feature.

To overcome this limitation. I dug a little deeper into the jQuery docs and found that jQuery.getScript internally calls the good old jQuery.ajax function. This function has a "cache" parameter which we can use to set whether the ajax function looks into the browser cache for the requested file or it directly fetches it from the location. I created a handy function to wrap around the jQuery.ajax call to support caching. Here is the code:



After I run this code, I get the following output in firebug. As you can see, there is no time-stamp at the end of the second request and also the time taken to fetch the file is significantly less (about 90% less) than the call to get the fresh copy.

So as you saw, we have built our own wrapper around the jQuery.ajax function which allows us to get cached files and significantly improve page load times. Hope you find this tip helpful!

Happy JavaScripting!

Batch Operations using the JavaScript Client Object Model

To improve performance and to reduce the time taken for data to travel over the wire, we can do batch operations using the Client Object Model in SharePoint. This can really help in reducing load time of pages and make the user experience better. Batch operations can be done using the .NET as well as the JavaScript Client Object Model. In this post, we are going to focus on how to perform batch operations using the JavaScript Client Object Model. In each of the following operations, only one call from the client to server will be made. It will contain all the information needed to perform the necessary operation. So without further ado, here is the code:

1) Batch Add Items to List:

2) Batch Update Items from List:

3) Batch Delete Items from List:

Now let us analyze what happens behind the scenes when we make one of these batch operations. Here is the firebug screen grab of the call to batch create 5 items:

Now as you can see, only one call is made from the client to the server. It contains all the XML necessary for creating the 5 items. Here is the relevant XML:


Hope you enjoyed this blog post. Happy SharePointing!

Addendum: I would also like to point out one of the hidden gems of the SharePoint world: if you are using Server Side Code (Full Trust), there is a similar batch method available called SPWeb.ProcessBatchData which can be used to bulk add, edit and delete list items. This is really helpful because it can operate on large number of items at once without making repeated calls to the database.

Convert a SharePoint WebApplication from Classic authentication to Claims

Here is a quick Powershell script to convert a SharePoint WebApplication from Classic (Windows) Authentication to Claims Authentication. This script is tested in SharePoint 2010 only.

When working with SharePoint 2013, you will not need this in most cases as the default authentication provider is Claims.

Modify Search Center Settings with JavaScript Client Object Model

Although there is currently no API in the JavaScript CSOM which lets you change the search center url directly, SharePoint stores the search settings in the Property Bag of the root SPWeb object in a site collection. You can set these property bag values and your search settings should get modified.

"SRCH_ENH_FTR_URL" – Search Center URL

"SRCH_SITE_DROPDOWN_MODE" – Search Scope Drop down option

"SRCH_TRAGET_RESULTS_PAGE” – Target Search Results page

Using JavaScript Client Object Model, you can set the values like this:

For the Search Scope Drop Down Options, here is a full set of values you can set:

Do Not Show Scopes Dropdown, and default to contextual scope: "HideScopeDD_DefaultContextual"
Do Not Show Scopes Dropdown, and default to target results page: "HideScopeDD"
Show scopes Dropdown: "ShowDD"
Show, and default to ‘s’ URL parameter: "ShowDD_DefaultURL"
Show and default to contextual scope: "ShowDD_DefaultContextual"
Show, do not include contextual scopes: "ShowDD_NoContextual"
Show, do not include contextual scopes, and default to ‘s’ URL parameter: "ShowDD_NoContextual_DefaultURL"

SharePoint 2013: Modify Navigation Settings with JavaScript and JSOM

One of the new additions in the JavaScript Client Object Model in SharePoint 2013 is the Publishing Navigation API. Some of the other additions are the UserProfile API and the Taxonomy API which I have already posted about.

In this post, let us look at how to use the Navigation API to change the navigation settings in a SharePoint 2013 site.

The main reason I want to do these posts is that currently there is still no API Reference available on MSDN for them. So this might be helpful to people looking to achieve the same functionality.

Here are the things which you can change from this Navigation API: 

1) You can change the Navigation settings of Publishing Sites as well as Non-Publishing sites.

2) You can set the Navigation Provider of the Current Navigation (Quick Launch) as well as the Global Navigation (Top Navigation Bar)

3) You can set the Navigation Provider out of any of these three:

     a. Inherit from Parent Site

     b. Managed Navigation (Taxonomy) The navigation items will be represented using a Managed Metadata term set.
     c. Structural Navigation: Display the navigation items below the current site.

4) Since all this code is pure JavaScript, you can add it in a variety of places like Apps, WebParts, Pages, Page Layouts, Web Templates etc.

So without much further ado, here is the code to manipulate the Navigation Settings:

First, lets make sure that we have loaded all the required SharePoint JavaScript files on the page. I like to use the jQuery.getScript() for this. The scripts we will need are sp.runtime.js,  sp.js and sp.publishing.js.
Here is a simple way by which I load all the necessary files:



Now, the actual code:

1) Set the (Current/Global) Navigation to either "Inherit from Parent" or "Structural Navigation":

2) Set the (Current/Global) Navigation dependent upon a Term Set in the Term Store:

Hope you find this helpful!

SharePoint 2013: Provision AppPart/ClientWebPart through Elements.xml

In my last post, we saw how we can add an app part to page by directly adding the app part code in our .aspx pages. Here is a link to my last post for those interested: http://vrdmn.blogspot.in/2013/02/sharepoint-2013provision.html

Now lets take a look at how we can provision the app part declaratively through Elements.xml file. First, you will have to make sure that the App is installed on the site on which you are trying to deploy the app part. Otherwise your app part will not be provisioned correctly.

Here is the code to put in your Elements.xml file:



Keep in mind the following few properties:

ProductId: Its the ProductId of your App. A unique identifier which differentiates your app. Please see my last post on how you can get the ProductId of your App.

FeatureId: The same as ProductId. On first glance, it looks like it should be the GUID of the feature present in your app. But thats not the case as far as I know.

ProductWebId: A new Random GUID

WebPartName: The file name of the WebPart found in your Client WebPart XML file. See previous post for  more details.

Custom Properties: You can even provision custom properties and set their default values from here. In the example, I have the myEnumProp as a custom property in my App Part. Here is a link on how to add custom web part properties to your app part: 

http://msdn.microsoft.com/en-in/library/fp179921.aspx