Create Custom Date Range Slider Bar With Graph for the Office 365 / SharePoint Search Refinement Panel

When you're refining search results on an Office 365 / SharePoint search page by a date, the Date Range Slider Bar with Graph is a nice graphical way to restrict results to date ranges.

Out of the box this control only works with dates in the past. But what if you wanted to refine based on future dates? Well, like most stuff in Office 365 / SharePoint, it's configurable. The only caveat is, you have to swim in "undocumented waters" (it's a little fiddly)!

Out of the box Date Slider (dates in the past)	Customised Date Slider (daters in the future)

At this point I need to give a quick shout out to IThinkSharePoint, for a blog post that helped point me in the right direction for creating a custom date refiner. That blog shows you how to change the properties of the refinement webpart to include different date ranges. The example they give shows ranges that go back several years.

This blog post focuses on dates in the future, and also on customising the date range control (so that you see the dates displayed in a graphical way).

The process to create a custom date range filter is;

1. Decide on the date ranges
2. Copy the OOTB date range filter Display Template
3. Modify the new Display Template
4. Export the search refinement webpart and update the properties (can be done with PowerShell alternatively)
5. Import the search refinement webpart back on the search page

1. Deciding on the date range

The date range that you decide on will be set in the refinement webparts properties, as well as in the date range filter template (Filter_SliderBarGraph). 

Because the values are directly interconnected, decide up front what the intervals will be. For this example, I've used 7 days, 30 days, and 90 days. This will allow me to filter items (in this case, events) that are:

• In the next 7 days
• Between 7 - 30 days time
• Between 30 - 90 days time
• And any combination in between. E.g:
• Events later than 90 days from now
• Events that occur within 7 - 30 days

2. Copy the OOTB date range filter Display Template

A display template called Filter_SliderBarGraph.html is used to render the date range filter, and it lives in the "/_catalogs/masterpage/display templates/Filters" directory.

Make a copy of the template, and then open the copy. In this example, I've saved mine as Filter_SliderBarGraph_LookAhead.html

3. Modify the new Display Template

Open the copy of the Display Template you just renamed.

The template needs to be slightly modified to cater for the different date range that will be sent to it. It's important to note that this template (that you will modify) will be directly tied to the date range values that you set in the refinement webpart (decided on in step 1).

There's no documentation on how to customise the date range filter control. I used Chrome and the developer tools to experiment with the JavaScript until I worked out what needed to be customised.

From the image above, you can see we need to customise the BucketedFilterData object that gets populated when the template is rendered.

Though the date ranges are correct, we need to update the labels used for each date range. The number of BoundaryValues (and the date ranges they include) directly relate to the number of date intervals set in the refinement webparts properties (see the next step).

Once you've experimented and got this right, add code to the display template (html) file that will override the labels.

Open the display template, and insert the code just after line 66 (ctx.BucketedFilterData = AjaxControlToolkit.SliderRefinementControl.GetDefaultBuckets(ctx);)

ctx.BucketedFilterData.BoundaryValues[0].Label = "Oldest"
ctx.BucketedFilterData.BoundaryValues[0].NextIntervalLabel = "Older"
ctx.BucketedFilterData.BoundaryValues[1].Label = "Today"
ctx.BucketedFilterData.BoundaryValues[1].NextIntervalLabel = "Next 7 days"
ctx.BucketedFilterData.BoundaryValues[2].Label = "7 days"
ctx.BucketedFilterData.BoundaryValues[2].NextIntervalLabel = "Within 7 - 30 days"
ctx.BucketedFilterData.BoundaryValues[3].Label = "30 days"
ctx.BucketedFilterData.BoundaryValues[3].NextIntervalLabel = "Within 30 - 90 days"
ctx.BucketedFilterData.BoundaryValues[4].Label = "90 days"
ctx.BucketedFilterData.BoundaryValues[4].NextIntervalLabel = "90+ days"
ctx.BucketedFilterData.BoundaryValues[5].Label = "90 days onwards"
ctx.BucketedFilterData.Labels.min = "Now - {0}" //"min" //{0}"
ctx.BucketedFilterData.Labels.range = "Between {0} - {1}"
ctx.BucketedFilterData.Labels.value = "{0}"
ctx.BucketedFilterData.Labels.max = "Between {0} - Furthest Event" //"max" //"{1}"

Your display template should look similar to this:

You'll also need to do a little massaging of the ctx object.

I found when I did this on O365 (as opposed to SharePoint on prem), I needed to use existing managed properties for the date refinement (e.g. RefinableDate00) (I didn't have the option of creating new Managed Search properties that use the DateTime type).

When using the RefinableDate managed property, the date range filter control doesn't render. I used the Chrome developer tools to inspect the JavaScript to see what was happening. The call to GetDefaultBuckets wasn't returning any Boundary objects.

Hmm. I un-minified the GetDefaultBuckets function (courtesy of unminify.com) and stepped through the function. It turns out that ctx has a property that gets parsed by this function. That property needs to be modified to ensure the function returns the BoundaryValues.

I won't lengthen this post (anymore than it already is) with going through why this happens. All you need to know, is to add a line of JavaScript to correctly format the string value right before the call to GetDefaultBuckets (line 79 below). That line of code is:

ctx.RefinementControl.spec = "(" + ctx.RefinementControl.spec.substring(ctx.RefinementControl.spec.search(/discretize=manual/i));

Your display template file should now look like this:

Next, update the name of the filter. Go to line 2, and change the name of the template. I changed mine to Slider with bar graph (Look Ahead).

Finally, save the display template (and if you're not editing the file via webdav, upload the file to the Filters folder).

4. Export the search refinement webpart and update the properties

Once you've saved a modified version of the Filter_SliderBarGraph display template you're nearly there! All you need to do now is update the webpart properties of the refinement webpart.

The first thing to do is ensure the date property you want to filter on has been included in the refinement filters.

Edit the refinement webpart properties, and select Refinements.

In the Refinement configuration dialog, select the date managed property that you intend to include (I mapped my crawled property to RefinableDate00).

For the Display template setting, select the new display template.

Save the changes to the webpart.

Next, export the refinement webpart. Once exported, open the webpart file in a text editor.

Find the SelectedRefinementControlsJson property. The property contains a serialised JavaScript object (some JSON). You need to edit two of the properties of that JSON string.

The first property is the "useDefaultDateIntervals". Ensure the value of this property is "false".

The next property to edit is the "intervals". Remembering back to step 1, where we decided on the date interval we were going to use. This property needs to reflect that. It's an array of numbers representing the date range intervals. I've used "-1, 7, 30, 90", to give me items that are for today (-1), next 7 days (7), next 30 days (30), and the next 90 days (90).

Save the changes.

5. Import the search refinement webpart back onto the search page

The final task is to remove the original refinement webpart from the search page, and replace it with the refinement webpart you just edited. I'm sure most people reading this will know how to do that, but for completeness, I'll outline the task in bullet points.

1. Edit the search page
2. Remove (delete) the refinement webpart
3. Using the same zone you removed the old refinement webpart from, click "Add webpart"
4. On the ribbon, click "Upload webpart"
5. Browse to the location you saved the refinement webpart to (step 4), and select the webpart
6. Click OK to upload the webpart
7. In the same webpart zone (again), click "Add webpart" (again).
8. Select the "Refinement" webpart from the ribbon, and click OK
9. Check-in and save the page.

Wollah! If you done everything correctly (assuming I've documented the process thoroughly), you should have a new look ahead date refiner!

Building Document Set Apps on Office 365 (or SharePoint)

What’s a Document Set App?

I made the term up, so it’s not anything really, other than a name to describe a small application that stores its data in the metadata fields (properties) of a Document Set.

For those who haven’t used Document Sets in Office 365 (or SharePoint), they're similar to a folder in a document library, only a little bit smarter. Document Sets are added to document libraries, and are generally used to group together a collection of documents that share something in common. For example tender responses, sales proposals, product information, employee files, etc.

Document Sets are like other Office 365 “list items” in that they can contain metadata fields (properties).

The properties of a Document Set can optionally be “pushed” onto files within the Document Set. In this way, you can have any document that is stored within a Document Set inherit key properties from the Document Set it belongs to. That makes finding those documents easier when using search.

Document Sets share a common page for displaying these properties. The common page for displaying these properties is used whenever someone navigates to (or clicks on) a Document Set.

This is where the “Document Set App” comes in.

The common page used for displaying a Document Set is a configurable webpart page, like most other pages in Office 365. The default webparts (that display an image and the properties in a simple table view) can be removed. A new webpart can be added in its place to customise how the properties are displayed and add new rich functionality.

As an example, let’s look at an Office 365 document library used to store an employees work goals.

This example Document Set App stores information about the goal setting review as properties on the document set. The data might include things like, goals, action plans, KPI’s, self-assessment ratings, training plans etc.

These properties can be edited on the Document Set form before, during and after the review process. The properties can contain advanced fields, repeating questions, validation, and conditional properties.

Conditional, mandatory and read-only/editable properties can be changed during different stages of the review process.

A standard workflow can be added to control the flow of the review. Workflow tasks would then be displayed inline on the form.

Indicators and graphs can be added as visual aids to show progress and status information.

Finally, the data (Document Set) can be secured so that only Personnel (HR), the employees manager and the employee themselves can see it.

Why would you use this approach to build a business app on Office 365?

There are a number of reasons why this works well.

Office 365 and the on premises version, SharePoint, offer a lot of functionality out of the box. A lot of this functionality is exposed via web services (the REST API), and can be leveraged by browser applications.

This means you can invest time into building the apps business logic, and forget about the all work that needs to be done behind the scenes to load, search, save and secure data. That’s a big saving in time, and in risk.

Time savings are easy to understand. If it would have taken three weeks to build the functionality to load, save, search and secure data, then that’s three weeks that's been saved. But what about risk?

There are always risks when building any system. Risks that requirements are misinterpreted, performance wasn’t thoroughly considered, bugs in the code, etc. Reducing the amount of code that needs to be written to provide core functionality directly reduces risk. There is less code to write, less to test, less to maintain, and ultimately, less that’s likely to go wrong.

If you don't need to spend the first few weeks of development building the "backend", you're free to focus on business logic from the beginning. That lowers the effort required to build the first version. This is particularly beneficial if you’re following a minimum viable product (MVP) approach.

The quicker a first version can be produced, the quicker feedback can be given, and the earlier issues can be caught. The business has more control through the development phase to focus on the best features, or even abandon the project if the system doesn't warrant further investment.

Here's a summary of some of the benefits I see for this approach:

• Common look and feel – lower barriers to adoption.
• Quick to build – CRUD operations (create, read, update, delete), search, versioning, auditing, workflow and security features are built into Office 365. 
• SharePoint Search.
  SharePoint search results are easily be tailored to display Document Sets from specific libraries. This gives you an easy way to search for particular items. Clicking on a Document Set takes you to the common Document Set homepage – which loads the custom form.
• List views, Export to Excel, and PowerBI.
  Power users can create views and reports to filter and analyse data. 
• Easy to upgrade. The application is mostly made of “out-of-the-box” (fields, content types, lists, search, REST web services) components. When O365 gets an update (which happens often), it’s very unlikely to cause a problem with your application.

But what about the "when"?

There are definitely scenarios that lend themselves to building this type of app, and other scenarios where you would steer clear of this approach.

When you're planning an application you need to ask a few fundamental questions before determining its suitability to the Office 365/SharePoint platforms.

You wouldn't use this approach (or the platform) for apps that have the follow characteristics. The platform just isn't designed to support these requirements:

• Time critical performance
• Highly transactional
• Complex relational data models
• Very granular permissions
• Large volumes of data (e.g. typically more than hundreds of thousands of records)

However, they can be a great fit for business apps with these requirements or characteristics:

• You want a quick build time (focus on business logic, not background services)
• You're building small "business productivity" apps, and you want to keep a common approach
• The ROI for the app can't justify a large investment in development time
• You have a reasonably simple data model
• Simple requirements for permissions 
• You want to leverage (existing) workflows (e.g. K2, Nintex)
• You want to consume other information already in Office 365 / SharePoint (think CRM, Email, Documents, User Profile information, relevant search results, Office Graph api)
• Where reporting and analytical data can be based on search indexes (realtime results not needed)

So, how do you build them?

This post hasn't been log enough already? Jeez! I think I'll leave that for part two!

(Updated) Using the Microsoft Client-side People Picker as an AngularJS Directive

I wrote about wrapping the Microsoft Client Side People Picker into an AngularJS Directive a few months back (eight months to be precise).

The original post is here: Using the Microsoft Client-side People Picker as an AngularJS Directive

I've made a few improvements to it recently, which I want to highlight in this post. The source code's been updated on GitHub, and can be downloaded here: AngularJS-Directive-for-SharePoint-People-Picker.

Summary of Improvements

• Wrapped a parent DIV around the peoplepicker 
• Works with SharePoint groups
• Listens to model changes and updates the control appropriately
• Re-factored code (better structure)
• Raises events on the root scope when starting and finishing resolving users

Designed for REST

The other thing I want to draw attention to, is that this directive is built with REST in mind. It's designed to work with models received from a REST query, and it formats the model (when new users are added) in a format that can be used to submit a REST.

Before we get started, let's look at what SharePoint sends us when we query a list that has people fields, using REST.

I've used the following REST query. The query requests the people fields, and expands the Id, Name and Title properties.

https://matthewyarlett.sharepoint.com/sites/appcenter/_api/web/lists/getbytitle('peoplePickerTestList')/items(1)?$select=multiUserColumnId,singleUserColumnId,multiUserColumn/Name,singleUserColumn/Name,multiUserColumn/Title,singleUserColumn/Title,multiUserColumn/Id,singleUserColumn/Id&$expand=multiUserColumn,singleUserColumn

The following screen shot is from Fiddler, and shows the response from SharePoint (Office 365).

There are a few things worth noting here. The first is the field names that are appended with "Id".

For example, the two people fields, multiUserColumn and singleUserColumn, both have corresponding fields multiUserColumnId and singleUserColumnId. These corresponding fields don't actually exist on the list, but are returned by REST for lookup fields.

The fields appended with "Id" only every contain the Id of the lookup item. When you update a SharePoint list using REST, it's easiest to update the list using these fields, passing in just the look Id(s).

The next thing to notice is the difference in the object returned for a single user field verse a multi-user field.

The single user field contains direct properties for the user values. In the example above, these values include Name, Id, and Title.

The multi user field is slightly different. It returns an object with a single property, "results". "results" is an array of user objects. Each user object in the array has the expanded fields we specified in the REST request; Name, Id and Title.

The people picker directive is designed to work with these two different models. It will read and update a model using this format.

Using the People Picker Directive

Added a reference to the people picker directive

<!-- Load third party scripts required by the people picker -->
<script type="text/ecmascript" src="/_layouts/15/SP.UI.Controls.js"></script>
<script type="text/ecmascript" src="/_layouts/15/clienttemplates.js"></script>
<script type="text/ecmascript" src="/_layouts/15/clientforms.js"></script>
<script type="text/ecmascript" src="/_layouts/15/clientpeoplepicker.js"></script>
<script type="text/ecmascript" src="/_layouts/15/autofill.js"></script>
<script type="text/ecmascript" src="/_layouts/15/sp.RequestExecutor.js"></script>
<!-- AngularJS-->
<script type="text/ecmascript" src="../angularjs-peoplepicker/scripts/angular.min.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/scripts/angular-sanitize.min.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/scripts/angular-resource.min.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/scripts/angular-route.min.js"></script>
<!-- All of this scripts are used to create the app. -->
<script type="text/ecmascript" src="../angularjs-peoplepicker/app.js"></script>
<!-- ****** The following script contains the people picker directive. ****** -->
<script type="text/ecmascript" src="../angularjs-peoplepicker/config/config.peoplepicker.js"></script>
<!-- ****** The following script contains the controller. ****** -->
<script type="text/ecmascript" src="../angularjs-peoplepicker/controllers/controllers.js"></script>

Add the people picker directive to the app

(function () {
    'use strict';        
    var app = angular.module('app', [
  'ngSanitize',
       'ngResource', 
     'ui.People'
    ]);
})();

Add one or more people pickers to the HTML (ensure you use a different id for each picker)

<div data-ng-disabled="false" ui-people ng-model="vm.data.su" pp-is-multiuser="{{false}}" pp-width="220px" pp-account-type="User,DL,SecGroup,SPGroup" id="peoplePickerDivAT"></div>

Conditionally, add some code to the controller to pre-populate the people picker (this would normally be a REST query to SharePoint to get some list data).

//App Controller
(function () {
 'use strict';
 var controllerId = 'appCtrlr';
 angular.module('app').controller(controllerId, ['$scope', '$timeout', appCtrlr]);

 function appCtrlr($scope, $timeout) {
  var vm = this;
  vm.webUrl = null;
  vm.data = {
   su:null,
   mu:null
  };   
  vm.getPresence = getPresence;
  var service = function () {  
   this.webAbsoluteUrl = _spPageContextInfo.webAbsoluteUrl;
   this.webRelativeUrl = _spPageContextInfo.webServerRelativeUrl;
   this.currentUserId = _spPageContextInfo.userId;
   this.webAppUrl = document.location.origin || document.location.href.substring(0, document.location.href.indexOf(document.location.pathname));  
  }
   
  init();

  function init() {
   //Normally you would get this information from a REST call to Office 365 / SharePoint
   getData(); 
   //Update the weburl property
   //This is to demo passing in a Web URL to the people picker via the pp-web-url attribute.
   $timeout(function(){
    var s = new service;
    vm.webUrl = s.webAppUrl;
    if (!$scope.$root.$$phase) {
     $scope.$apply();
    }     
    },500);
  };
  
  function getData(){
   $timeout(function(){
    vm.data.su = {
     //You'll need to add a valid claims based identity, and the SPUSER ID here
     Name:'i:0#.f|membership|someone@sometenant.onmicrosoft.com',
     Id:'19', 
     Title:'Matthew Yarlett'
     };
    //Add a user to the mulitple-user model
    vm.data.mu = {results:[]};    
    vm.data.mu.results.push({
     //You'll need to add a valid claims based identity, and the SPUSER ID here
     Name:'i:0#.f|membership|someone@sometenant.onmicrosoft.com',
     Id:'19', 
     Title:'Matthew Yarlett'});
    //Add a SharePoint group to the mulitple-user model
    vm.data.mu.results.push({
    //You'll need to add a valid claims based identity, and the SPUSER ID here
     Name:'App Center Owners',
     Id:'3', 
     Title:'App Center Owners'});
    if (!$scope.$root.$$phase) {
     $scope.$apply();
    }
   },100)
   
  }
      
  function getPresence(userId, userTitle) {
   if (userId && userTitle) {
    return '<span class="ms-noWrap"><span class="ms-spimn-presenceLink"><span class="ms-spimn-presenceWrapper ms-imnImg ms-spimn-imgSize-10x10"><img class="ms-spimn-img ms-spimn-presence-disconnected-10x10x32" src="'+service.webAbsoluteUrl+'/_layouts/15/images/spimn.png?rev=23"  alt="" /></span></span><span class="ms-noWrap ms-imnSpan"><span class="ms-spimn-presenceLink"><img class="ms-hide" src="'+service.webAbsoluteUrl+'/_layouts/15/images/blank.gif?rev=23"  alt="" /></span><a class="ms-subtleLink" onclick="GoToLinkOrDialogNewWindow(this);return false;" href="'+service.webAbsoluteUrl+'/_layouts/15/userdisp.aspx?ID=' + userId + '">' + userTitle + '</a></span></span>';
   }
   return '<span></span>';
  }
 }
})();

Possible attributes and they're values

Note: The data-pp-ready-to-load attribute has been removed from this version (the directive listens to model changes and updates the people picker accordingly).

Attribute	Possible values	Default value	Required?
data-ng-model	For single-user fields, an object: model = { 'Name': object.Name, 'Title': object.Title, 'Id': object.Id } For multi-user fields, the model needs the "results" object (which is an array) of people object. model.results = [{ 'Name': object.Name, 'Title': object.Title, 'Id': object.Id }] Where, name is a claims based user principal, Title is the display name of the principal, and Id is the lookup Id of the person or group	null	Yes, but can be null
data-pp-is-multiuser	true | false	false	No
data-pp-width	Any numerical value, followed by 'px'	220px	No
data-pp-account-type	Any combination of the following values, separated by a comma; User,DL,SecGroup,SPGroup	All	No

Screen shot

Update the Choices of an Office 365 or SharePoint Choice Field using PowerShell and CSOM

Today I needed to update some SharePoint Choice fields with new values using PowerShell and CSOM. To my surprise, I didn't find much on the web about doing this, hence this post!

The code is pretty rudimentary, but hopefully you get the picture! The example is for an Office 365 site, but it works the same with SharePoint on premises, except that you need to pass in a different credential object (see the commented code).

#Add the Client dll's
Add-Type -Path 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.Client.dll' -EA 0
Add-Type -Path 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.Client.Runtime.dll' -EA 0

#Set some variables
$url = "https://sometenant.sharepoint.com/sites/somesite"
$listTitle = "ListWithSomeFields"

#Create the credentials
$username = Read-Host -Prompt "Enter your password" 
$securePassword  = Read-Host -Prompt "Enter your password" -AsSecureString
#Create the credential for Office 365
$O365Credential = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($username, $securePassword)
#If you're doing this on SharePoint on premises, then you need to create the credential like this:
$onPremCredential = Get-Credential -Message "Enter your SharePoint on-premises credentials"

$ctx = new-object Microsoft.SharePoint.Client.ClientContext($url)
$ctx.Credentials = $O365Credential;
$ctx.RequestTimeout = "500000"; 

#Load the site and web that contains the field
$Site = $ctx.Site
$ctx.Load($Site)
$ctx.ExecuteQuery()
$rootWeb = $Site.RootWeb
$ctx.Load($rootWeb)
$ctx.ExecuteQuery()

#Get the list that the field exists on
$list = $rootWeb.Lists.GetByTitle($listTitle);
$ctx.Load($list);
$ctx.ExecuteQuery()

#Get the fields collection from the list (or from the web)
$FieldCollection = $list.Fields
$ctx.Load($FieldCollection)
$ctx.ExecuteQuery()

#Get a reference to the field
$field = $FieldCollection.GetByInternalNameOrTitle("MySingleChoiceField");
$ctx.Load($field);
$ctx.ExecuteQuery();

#Define your choices
$choices = @("Fred","Barney","Wilma");
#"CAST" the field to a Microsoft.SharePoint.Client.FieldMultiChoice
#This works the same whether the field you're updating is a single or multi choice field
$choiceField = New-Object Microsoft.SharePoint.Client.FieldMultiChoice($ctx, $field.Path)
#Load the Multichoicefield
$ctx.Load($choiceField);
$ctx.ExecuteQuery();
$choiceField.Choices.Clear()
$choiceField.Choices = $choices            
$choiceField.UpdateAndPushChanges($true);
$ctx.ExecuteQuery();

Using the Microsoft Client-side People Picker as an AngularJS Directive

[UPDATED]: I've written an updated post for this that include some feature enhancements and fixes. You can read that post here: (Updated) Using the Microsoft Client-side People Picker as an AngularJS Directive

Last year I wrote about using the Microsoft Client Side People Picker with an AngularJS app (here).

In this post, I'm building on that idea, and I'm going to demonstrate how to use the People Picker within an AngularJS Directive. Using a directive simplifies the code and makes it much more re-usable!

I'm going to break the post up into parts. This part will outline how to use the directive. The next post will cover a bit more about how the directive was created and how it works.

The code example is up on GitHub, here: AngularJS-Directive-for-SharePoint-People-Picker

Let's get into it!

1. Add the script references to your apps html page.

You need to add a reference to the JS file the directive is declared in, as well as all of the Microsoft Scripts that the SharePoint People Picker requires

<!-- Load the constant variables -->
<script type="text/ecmascript" src="../angularjs-peoplepicker/config/config.constants.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/models/models.js"></script>
<!-- Load third party scripts required by the people picker -->
<script type="text/ecmascript" src="/_layouts/15/SP.UI.Controls.js"></script>
<script type="text/ecmascript" src="/_layouts/15/clienttemplates.js"></script>
<script type="text/ecmascript" src="/_layouts/15/clientforms.js"></script>
<script type="text/ecmascript" src="/_layouts/15/clientpeoplepicker.js"></script>
<script type="text/ecmascript" src="/_layouts/15/autofill.js"></script>
<script type="text/ecmascript" src="/_layouts/15/sp.RequestExecutor.js"></script>
<!-- AngularJS, Sanitize, resource -->
<script type="text/ecmascript" src="../angularjs-peoplepicker/scripts/angular.min.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/scripts/angular-sanitize.min.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/scripts/angular-resource.min.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/scripts/angular-route.min.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/scripts/ui-bootstrap.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/scripts/xml2json.min.js"></script>
<!-- All of this scripts are used to create the app. -->
<script type="text/ecmascript" src="../angularjs-peoplepicker/app.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/config/config.js"></script>
<!-- ****** The following script contains the people picker directive. ****** -->
<script type="text/ecmascript" src="../angularjs-peoplepicker/config/config.peoplepicker.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/common/common.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/common/logging.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/services/dataservices.js"></script>
<script type="text/ecmascript" src="../angularjs-peoplepicker/controllers/controllers.js"></script>

2. Add the directive as a dependency to your app.

(function () {
    'use strict';        
    var app = angular.module('app', [
    //inject other Angular Modules
    'ngSanitize',
    'ngResource', 
    'ui.bootstrap',
    //inject the People Picker directive
    'ui.People',
    //inject App modules
    'common'
    ]);
})();

3. Add the directive to the page (you can add multiple instances of it).

When add the directive, it has several attributes that can be set to control the behaviour of the people picker.

Most aren't mandatory, but you must add the data model (via ng-Model), and you must add the pp-ready-to-load attribute (which tells the directive the data model has updated, and is ready to be used).

Possible attributes and they're values

Attribute	Possible values	Default value	Required?
data-ng-model	An array, containing a list of users, in the following format: var userArray = [{ 'Name': object.Name, 'Title': object.Title, 'Id': object.Id }] Where, name is a claims based user principal, and Title is the display name of the prinicpal	null	Yes (you must supply a model to the data-n-model attribute, but it contain a null value)
data-pp-ready-to-load	true | false	false	Yes (the people picker will not render until this value is set to true)
data-pp-is-multiuser	true | false	false	No
data-pp-width	Any numerical value, followed by 'px'	220px	No
data-pp-account-type	Any compination of the following values, seperated by a comma; User,DL,SecGroup,SPGroup	User,DL,SecGroup,SPGroup	No

An example of adding a single user picker;

<div ui-People ng-model="vm.data.su" pp-ready-to-load="{{vm.loadPeoplePickers}}" pp-is-multiuser="{{false}}" pp-width="220px" pp-account-type="User" id="peoplePickerDivAT"></div>

An example of adding a multiple user picker:

<div ui-People ng-model="vm.data.mu" pp-ready-to-load="{{vm.loadPeoplePickers}}" pp-is-multiuser="{{true}}" id="peoplePickerDivAP"></div>

4. Load the data for the model.

Before initialising the directive (via changing the value of the property used in the data-pp-ready-to-load attribute to true), ensure you up the data model used for the people picker with the current data (if any).

For example, you might perform a REST call to get the current values in a list item. You would then create the model for the user picker when data from the REST call is returned.

After updating the data in the people pickers model, you would then change the value of the property used in the data-pp-ready-to-load attribute to true.

The code below shows an example of doing this.

function init() {   
   //Pre-populate the single user field
   //Normally you would get this information from a REST call to Office 365 / SharePoint
   vm.data.su = populatePickerModel({
      Name:'i:0#.f|membership|someone@sometenant.onmicrosoft.com',
      Id:'19', 
      Title:'Matthew Yarlett'});
   vm.loadPeoplePickers = true;
   if (!$scope.$root.$$phase) {
      $scope.$apply();
   }
};

That's it - as far as initialising and using the control goes.

To use the value(s) of a the people picker directive while the page is open, simple reference the people picker model.

E.g.

<p>
    <span data-ng-repeat="r in vm.data.su track by $index">
        <span data-ng-bind-html="vm.getPresence(r.Name, r.Title)"></span>&nbsp;
    </span>
</p>

The example above uses a function on the controller to return the users name including the presence icon, It's just some standard html that I've exported (and slightly tweaked) from a SharePoint user field. Note that it uses a "constweb" variable to get the weburl - you would need to set this!

function getPresence(userId, userTitle) {
   if (userId && userTitle) {
      return '<span class="ms-noWrap"><span class="ms-spimn-presenceLink"><span class="ms-spimn-presenceWrapper ms-imnImg ms-spimn-imgSize-10x10"><img class="ms-spimn-img ms-spimn-presence-disconnected-10x10x32" src="'+constWeb+'/_layouts/15/images/spimn.png?rev=23"  alt="" /></span></span><span class="ms-noWrap ms-imnSpan"><span class="ms-spimn-presenceLink"><img class="ms-hide" src="'+constWeb+'/_layouts/15/images/blank.gif?rev=23"  alt="" /></span><a class="ms-subtleLink" onclick="GoToLinkOrDialogNewWindow(this);return false;" href="'+constWeb+'/_layouts/15/userdisp.aspx?ID=' + userId + '">' + userTitle + '</a></span></span>';
   }
      return '<span></span>';
}

Persisting the value(s) of the a people picker control is just as easy. You use the data in the people pickers model to write back to the server.

In the example below, I have a model used in a REST call for updating a list item that has a people picker field. Data from the people picker directive's model is formatted for the REST call. The ID (SPUser.Id) of each resolved principal (user or group) is added to an array of ID's, which is passed to the server via a REST call.

var sr = sr || {};
sr.models = sr.models || {};

sr.models.listItemModel = function (id) {
   this.Id = id ? id : -1; 
   this.srSingleUserField = null;
   this.srMultipleUserField = {
      results: []
   };   
   this.__metadata = {
      //The type is unique to your list. You can find out the type byte
      //looking at the list using a REST via the browser
      //E.g. http://my.site.com/_api/web/lists/getlistbytitle("YourListName")
      type: 'SP.Data.SrListItem'
   };
}

function populatelistItemModel(srcModel, tagsTerms) {
   var dstModel = new sr.models.listItemModel(srcModel.Id);            
 //Single user field
 if(srcModel.su){
  if(srcModel.su.length == 0){
   dstModel.srSingleUserField = null;
  }
  else{
   var user = srcModel.su[0];
   dstModel.srSingleUserField = user.Id
  }
 } 
   //Mutli user field
   if (srcModel.mu) {
      if(srcModel.mu.length == 0){
         dstModel.srMultipleUserField.results = [];
      }
      else{
         for(var i = 0; i < srcModel.mu.length; i++){
            var user = srcModel.mu[i];
            dstModel.srMultipleUserField.results.push(user.Id);
         }
      }
   }
   dstModel.__metadata.etag = srcModel.__metadata.etag;
   dstModel.__metadata.id = srcModel.__metadata.id;
   dstModel.__metadata.uri = srcModel.__metadata.uri;
   return dstModel;
}

I also added some CSS to override a few of the People Pickers classes, that fixes a few style issues. It's optional, but I've added it below for completeness.

The CSS classes are prepended with div#strk (the parent DIV of my sample), to ensure these classes only affect the app.

/* People Picker Modifications */
div#strk .sp-peoplepicker-autoFillContainer{
 z-index: 20;
 background-color:#fff;
}
div#strk .sp-peoplepicker-topLevel{
 background-color:#fff;
}
div#strk .sp-peoplepicker-topLevel{
 min-height:34px;
}

When it's all said and done, it looks like this;

Saving a Managed Metadata (Taxonomy) Field Value to Office 365 using REST

In this post I want to demonstrate how to save a Managed Metadata (Taxonomy) field value (single or multiple terms) to a Managed Metadata (Taxonomy) Field in Office 365 via the REST API.

The Hidden Managed Metadata Field

The trick to being able to save a taxonomy field value via REST, is knowing the name of the hidden text field that gets created when you create a Managed Metadata field.

When you make a REST call to update the Managed Metadata field, you need to pass a string representation of the managed metadata terms that you're saving into this hidden field.

The string representation of the terms is in the format of "termName|termId;".

In the screen shot below, you can see the field value of a hidden Managed Metadata field (the hidden field name is pa28754972f84ff7a6bf3e4762f23e23).

Finding the Name of the Hidden Field

Finding the name of the hidden text field of a Managed Metadata field is easy. The fastest way to do it, is by using the REST API via a browser.

1. Open Internet Explorer
2. In the address bar, enter the URL for your Office 365, followed by the REST API endpoint for to list the fields in your list.

https://matthewyarlett.sharepoint.com/sites/appcenter/_api/web/lists/getbytitle('srShipRegister')/fields

3. Use the browsers find function (Ctrl+F) to locate your field name in the xml

4. Look at the TextField property, and copy the copy
5. Use the browsers find function (Ctrl+F) to locate your field name in the xml, by searching for the guid
6. Make note of the hidden fields static name

Formatting a taxonomy field value

Now that you know the name of the hdden Taxonomy text field, you need to format the term values you want to save.

The terms should be formatted in the format of "termName|termId;".

An example model for updating the list in the above screens could look like this:

Loading ....

... and this is what the JSON looks like when you post it back to Office 365

Drag'n'drop Error within a DocumentSet

I came across a strange bug yesterday. I couldn't drag files into the Documents webpart within a DocumentSet.

When I tried dragging documents onto the page, the normal "Drop here..." dialog wasn't shown, and dropping the document wouldn't upload the file to SharePoint.

After a little experimenting (on both Office 365 and SharePoint 2013 on prem) it seems to be a bug in the SharePoint CSS.

The bug is manifested only when you change the webpart chrome from Default to Title Only or Title and Border for the documents webpart.

(Why would you do that anyway? I had a requirement to display the documents webpart title, showing the label "Supporting Documents".)

To workaround this bug, add some CSS to a Content Editor webpart, that re-positions the "Drop here..." div. If you only want that CSS, skip to bottom.

So here is how you work around it... mostly in pictures!

1. Drag'n'drop in a normal Document Set - works fine

2. Change the Webpart chrome to display the Webpart Title

3. Try the drag'n'drop again... Ahhgg! It doesn't work anymore!

4. If you zoom the page out, you'll notice that the Drag'n'drop box is further down the page and off to the right... what the?

5. With a little element inspection, we can see that Drag'n'drop div has some values set for the Top and Left properties.

These values are causing the div the be misplaced when the parent div (for the webpart) contains another child div, which appears in the HTML layout flow before the Webparts contents div (where the Drag'n'drop div lives).

In this case, that child div is the Webpart title container.

6. To fix this issue, all we need to do is:

a). Change the position CSS property for the Webparts "contents" div to Relative. This is requred because the Drag'n'drop div has a position value of absolute - an absolute position element is positioned relative to the first parent element that has a position other than static. See http://www.w3schools.com/css/css_positioning.asp for more info.

b). Override the Left and Top CSS properties on the Drag'n'drop div, with new values.

We can achieve this through a couple of CSS selectors that target these two div's. All we need to do is add the CSS to the page.

7. Add the CSS the page by adding a new Content Editor webpart, editing the source, and adding the new CSS styles.

Don't forget to hide the webparts title, by changing the Chrome property to None

8. Save the changes

9. Presto... problem fixed!

The CSS: