Showing posts with label JSOM. Show all posts
Showing posts with label JSOM. Show all posts

Wednesday, 23 March 2016

Search a Taxonomy term in a TermSet using JSOM

Here is some code I put together to search a term within a term set. This is for scenarios when you have a large term set and need to efficiently find a term with a specific label.

Here is a link which describes the exact combinations needed to make this work (Thanks Jose!)
https://msdn.microsoft.com/en-us/library/hh626704%28v=office.12%29.aspx

In this code, I am searching for all terms which start with an "A" in a term set which contains locations from around the world:

Note: I am using JSOM here but this also works with CSOM



Result:


Tuesday, 17 November 2015

Custom multilingual text in SharePoint Online using Taxonomy and JSOM

I have been working on an Office 365 intranet which will be rolled out globally. Naturally, one of the core requirements of the solution is that it should be multilingual. In my previous posts on this topic, Modify Site Regional and Language settings with JSOM and JavaScript, we had a look at how to set alternate languages for a site and in Update user language and regional settings with CSOM, we saw how to set the preferred display languages for a user.

This allows a user to see the SharePoint site chrome in their own preferred language. Now in this post, lets have a look at how to have localized custom text so that the user can see custom labels, headings etc. in their preferred language.

Some notes around this:

1) This approach is based on the multilingual features of SharePoint Term Sets:


It is possible to have multi-lingual term sets because each term in a term set has a unique ID and each term can have multiple labels. You can designate a default label for a term in each language available for a term store. A term can then have multiple synonyms in each of these languages, as well as labels and synonyms in other languages.

Users will also see managed terms displayed in their preferred language, regardless of the actual default language of the term store.

If no labels are specified for terms in the language in which a user is viewing a term, then the default label for the term in the default language of the term store will be displayed to users.

https://support.office.com/en-us/article/Work-with-multi-lingual-term-sets-D04098AF-282B-45C3-97CB-59363042C1B3

3) Based completely on JSOM, JavaScript and the SharePoint Term Store.


4) This approach is built on top of the MUI features in SharePoint. Which means that the user created content such as list item data, documents etc. will NOT be translated.


5) The SharePoint Online Term Store is treated as a "data source" for custom multilingual text. Each custom text is a term in the "Translations" term set. For each language that you have to support add a new label to the term for that language.


Lets get started:

1) Setup the Term Store to support term labels in multiple languages


I have set the default language of the Term Store as English and then added Dutch as a Working Language. This means that the term store will be able to support labels for a term in English as well as Dutch.



After adding the working languages, I have created a new Term Group called "My Group".
Under "My Group", I have created a Term Set called "Translations".
Under "Translations", I have created 3 terms: Communications, Marketing and News.
We will use these 3 terms to show the custom multilingual text.

We need to add the default language labels for each term:



After a label has been specified for each term, they will appear in the following way:

When English (default) is selected:



When Dutch is selected:



The translation framework will work in the following way:

If I am an English user and I have set my preferred language as English, when the terms for the "Translations" term set will be returned,  JSOM will return the English language labels by default. 

If I am a Dutch user and I have set my preferred language as Dutch, when the terms for the "Translations" term set will be returned,  JSOM will return the Dutch language labels by default. 

If I am an Italian user and have set Italian as my preferred language in my user profile,  SharePoint will return the English labels for the Translations term set as we have not selected Italian as one of the Working Languages of the Term store, nor have we set any labels in Italian.



2) Add Local Custom Properties to Terms


Next, we will add a local custom property for each term to identify it regardless of the language. This will serve as the ID of the term when we fetch it from JSOM:



This is the list of the local custom properties I have created for my terms:

Term
Local Property Name
Value
Communications
TranslationID
MUITextCommunication
Marketing
TranslationID
MUITextMarketing
News
TranslationID
MUITextNews

We could use the Term GUID here but I prefer using a custom ID as it is more readable. Also, if someone deletes one of the terms by mistake, it is easy to create a new Term and set the custom ID in the properties. If we were using a GUID, we would have to use code to create a new term with a specific GUID.

3) The Translation framework


After the Term Store is correctly setup, all we need to do is get the terms from the "Translations" term using the JavaScript Client Object Model (JSOM) and display them in the UI:
  • Query the term store to get the terms from the "Translations" term set.
  • SharePoint will return the term labels in the current user's preferred language if:
    • The alternate language is enabled on the current site
    • The current user has set the language as a preferred language in their user profile
    • The term store supports the language as a "Working Language" as shown in step 1
    • A default label is defined for the terms in that language.
  • If any one of these conditions is not fulfilled, then the English labels for the terms will be fetched as it is the default language of the Term Store. 
  • The term labels will be stored in the cache.



4) Performance/Caching


Since it is not advisable to make a call to the Term Store on every page load, it is a good idea to cache the labels for a particular user. My recommendation would be to use the browser web storage. Whether you use session storage or local storage depends on the implementation of the solution. MDN has a great article on this https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API

For demo purposes, I am using the sessionStorage and storing the term labels as a JSON object.

When the preferred language of the current user is English:


When the preferred language of the current user is Dutch:


5) Using the framework to show localized text


After the framework is correctly setup, all we need to do is call the framework correctly to show the custom text in the language of the current user:



When this code runs, if the preferred language of the current user is English, they will see the English text:




If the preferred language of the current user is Dutch, they will see the custom text in Dutch:


This way, you can utilize the multilingual features of the SharePoint Taxonomy Term Store to show multilingual custom text in your solution.

Thursday, 6 August 2015

Modify Site Regional and Language settings with JSOM and JavaScript

Recently, the ability to modify the Regional and Language settings of a site has been added to the client APIs in SharePoint 2013 and SharePoint Online. While the support for SharePoint 2013 was added in the December 2014 CU (as announced by Vesa here), the support for SharePoint Online has been a more recent addition.

There are some really nice code examples for the CSOM Regional and Language APIs in the Office Dev PnP Library:
https://github.com/OfficeDev/PnP/tree/master/Samples/Core.Settings.LocaleAndLanguage

But, I could not find JSOM code example of these APIs. So I am listing down some of the most frequently used Regional and Language functions here.

1) Add a Supported UI Language:



2) Remove a Supported UI Language:



3) Disable Multi Lingual and Remove all UI Languages:



4) Get Regional Settings:


A full list of all the regional settings properties is available here:
https://msdn.microsoft.com/EN-US/library/office/jj244880.aspx



5) Set Regional Settings:




6) Set Time Zone of a site:


This one was a bit tricky but I finally got there in the end. You will need to know the ID of the Time Zone you want to set in the site. A full list of SharePoint TimeZone IDs is here:
https://msdn.microsoft.com/library/microsoft.sharepoint.spregionalsettings.timezones.aspx



Hope this helps!

Sunday, 26 July 2015

JSOM Provisioning: Creating SharePoint artifacts without declarative XML

The recent guidance from Microsoft regarding the provisioning of SharePoint artifacts is pretty clear. The recommendation is to completely move away from declarative creation of Site Columns, Content Types etc. and instead, create them completely from code.

To support this approach of programmatically creating artifacts, a lot of work is being done on the "Provisioning Engine" in the OfficeDev Patterns and Practices Library on GitHub. To put it very simply, the Provisioning Engine reads a predefined XML file called the "PnP Provisioning Schema" and creates all the SharePoint artifacts using CSOM. Since this engine predominantly uses C#/.NET, it is expected to be run from somewhere like an Azure Web Job, a Web Application on an IIS server or a simple console application.

This method of provisioning is great for clients who opt for Azure subscriptions or IIS servers along with their SharePoint roll-outs. But this is not necessarily true with clients who only want to go for SharePoint or who do not have enough budget for additional Azure or IIS installs. So far, the only option in these cases is to go with the traditional declarative XML based provisioning using No Code Sandbox Solutions (NCSS). This approach is still valid at this time and Microsoft has stated that No Code Sandbox Solutions continue to remain supported:
http://blogs.msdn.com/b/sharepointdev/archive/2014/01/14/deprecation-of-custom-code-in-sandboxed-solutions.aspx

Still, in this post I am going to explore another form of provisioning SharePoint artifacts completely based on the JavaScript Object Model (JSOM). Since the provisioning is done completely from JavaScript running in the browser, there is no need for a platform like Azure or IIS to run this code. I came across the following project in Office Dev PnP which shows how to use a SharePoint hosted Add-In (App) to create artifacts like Site Columns and Content Types etc. in the host web.

https://github.com/OfficeDev/PnP/tree/master/Samples/Provisioning.Jsom

Some code examples from the project:

1) Create Site Column:




2) Create Content Type:




Here are my observations about this approach:


1) This project uses a SharePoint Hosted Add-In (App) to run the JSOM code. But with a few modifications, it can be made to run from a JavaScript file provisioned to a document library with a No Code Sandbox solution. The readme file of this solution mentions an additional project "Provisioning.Jsom.Ncss" which seems to be missing from the solution. My guess is this project did the exact same thing. With this approach, we remove the dependency on the Add-In (App) Model for provisioning.

2) Currently for values like site column names, types, content type names etc hard coded strings are being used. This can be modified to be read from an XML file, preferably the PnP Provisioning Schema. The schema XML file can be deployed with the Provisioning JavaScript file in the NCSS itself.

3) This approach can be used to create sub sites but not site collections as there is no way right now to create site collections through JSOM. So the deployment process will have to be manual creation of a Site Collection with an empty web template, and then to upload the WSP which will deploy the JS file to the SharePoint site. This file will then do the artifact provisioning.

I am going to explore these options and will post something in the future around this approach.

Thanks for reading. Hope you find this information useful in some way!

Wednesday, 28 January 2015

Set user profile properties using JSOM & JavaScript

User Profile properties were recently made writable from the CSOM. Vesa Juvonen has a great post about it here . In addition to that, I have also blogged about how a Tenant admin can set the user profile properties of the users in the tenant.

In this post, I will show you how to set the current user's profile properties using the JavaScript Client Object Model (JSOM). Please refer to the 2 posts I have mentioned for any additional details around this.

Right now this functionality is only available in SharePoint Online/Office 365. If you want this functionality to come to SharePoint 2013 On-Premises, please create or up-vote on the feedback here: https://officespdev.uservoice.com/

Monday, 25 August 2014

Start SharePoint Workflows with JavaScript Client Object Model

This will be a quick post to follow up on couple of my previous posts. In this post we will see how to start SharePoint 2013 Workflows which are created using the SharePoint 2010 Workflow engine. If you have Workflows created with the SharePoint 2013 engine, please see my previous posts:

1) Managing SharePoint 2013 Workflows with CSOM

2) Using the SharePoint 2013 Workflow Interop Service in CSOM

In this post, I will show you basically the same thing as in the previous posts, but by using the JavaScript Client Object Model (JSOM).

I recently had a requirement for which I had to start a Nintex Site Workflow with JavaScript. Now due to my previous posts, I had an idea that we can use the Managed CSOM to manage workflows but wanted to see if the same is possible from the JavaScript CSOM.  Nintex Workflows utilize the SharePoint 2010 Workflow Engine and hence we require the Interop Service to work with them in JavaScript.

Here is the code I put together to start my Site Workflow:



You can  have a look at my previous posts and the SP.WorkflowServices.debug.js file to see how to start other workflows such as List Workflows or SharePoint 2013 Workflow Engine workflows from the JavaScript Client Object Model.


Friday, 15 March 2013

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"

Sunday, 3 February 2013

SharePoint 2013: Working with User Profiles & JavaScript CSOM

SharePoint 2013 has added a variety of functionality to the Client API. One of them is the ability to fetch User Profile data. Now you can directly query the user profiles and get the required data from the client site. This can be really useful if you are building apps.

If you want to use the REST API to work with user profiles, please see one of my other posts: http://www.vrdmn.com/2013/07/sharepoint-2013-get-userprofile.html

In this post, I will show you how to work with User Profiles using the JavaScript Client Object Model

Before we get started with the code, lets make couple of things sure. First,  you will need a reference to the following JavaScript files in your page:


(jQuery is not required but I have added it because we will need it for the $.ajax function when doing REST queries)

Second thing, you will need the domain\username of the user you want to get the user profile data for. This can be easy to get if you are in an On-Prem environment. But if you are working with SharePoint Online, this can be quite tricky. Your username might not always be in the domain\username format. It is stored in the LoginName property if you are querying the Site User Information List:

https://yoursite.sharepoint.com/sites/pubsite/_api/Web/GetUserById(17)

and it is stored in the AccountName property if your querying the User Profile Service:

https://yoursite.sharepoint.com/sites/pubsite/_api/SP.UserProfiles.PeopleManager/GetMyProperties

In SharePoint Online, it will most probably be in the following format:

i:0#.f|membership|vardhaman@yoursite.onmicrosoft.com


Quick Note: If you are using the REST API, you will need to encode the username before you use it in your call. The encodeURIComponent( ) function can be helpful here.

Enough talking. Lets jump into some code right away:

1) Get Multiple User Profile Properties:



2) Get Single User Profile Property:



3) Get User Profile Properties of the Current User:



4) Get Properties of Multiple Users in Single Request:



For this last example, Let's observe the XML which is sent to the server:



With this, we can confirm that only one call was made to the server to retrieve the properties of multiple users. This way, you can even retrieve multiple properties of multiple users in one call.

Wednesday, 19 December 2012

Working with Taxonomy and JavaScript in SharePoint 2013

SharePoint 2013 has introduced some nice new features, one of which is the ability to manipulate managed metadata with the JavaScript Object Model. Unlike SharePoint 2010, we can now do a variety of operations with the Taxonomy Items in SharePoint 2013. Unfortunately, at the time of this writing, there is not a lot of documentation available on MSDN with regards to this particular feature.There is some preliminary documentation available for the Taxonomy in .NET Managed Client Object Model but the JavaScript API Reference has not been updated yet. So hopefully this blog will come in handy for someone looking to explore. All right lets get started:

First and foremost, you will have to load the SP.Taxonomy.js on your page explicitly as it is not loaded by default in SharePoint. Also make sure that you have loaded the SP.Runtime.js and SP.js files before continuing with your taxonomy code. Various errors like "SP.Taxonomy is not defined" or "Unable to get property 'TaxonomySession' of undefined or null reference" might come up if you have not loaded all the 3 necessary files on your page.

A simple way to load all the 3 files is with the jQuery.getScript function:



Now lets see some actual code which you can use to Manipulate the Taxonomy Items:

1) Query a particular Term Set and get all the Terms under it:




2) Create new Term Group under the Term Store:




3) Create new Term Set under a Term Group:




4) Create new Term under a Term Set:




5) Get Value of a Single Value Taxonomy Column in a List:




6) Get Values of a Multi Value Taxonomy Column in a List:




Hopefully you found this helpful. Happy SharePointing!

Monday, 27 August 2012

Paging in SharePoint JavaScript Client Object Model

Paging can be of great help when you want to improve the performance of your code especially when you are working on front-end development and want to reduce the page response time. Let us see how can be implement paging when working with the JavaScript Client Object Model.


The important parts to note in this code are the RowLimit element in the CAML query and the SP.ListItemCollection.get_listItemCollectionPosition(); property. Please have a look at the comments to know more details about the individual lines of code.

The ListItemCollectionPosition.pagingInfo determines the id of the last item fetched along with the filter and sorting criteria. It specifies information, as name-value pairs, required to get the next page of data for a list view.