JavaScript SharePoint People Picker

Yes.. JavaScript SharePoint People Picker… try saying that 3 times fast.

Anyway, I needed one for a form I was developing. It had to be client side, and it needed to work with SharePoint.

In SharePoint 2013, there’s already support for this:

But I need something for SharePoint 2010. I found several articles on manipulating the data in the people picker, but very little on creating a people picker. I continued to google, and my googling bore fruit:

Tanmay Shahane has a neat little bit of code that uses the EntityEditor.js to create a people picker – obviously you should be including jQuery into your page for Tanmay’s script to work. The complete post is here:

But if the link is broken or something, Tanmay’s code as follows:

function EntityEditorHandleCheckNameResult(result, ctx) {
    ULSGjk: ;
    EntityEditorCallback(result, ctx);
    //login name
    var loginName = $(“”).attr(“title”);
    //display name
    var displayName = $(“ div:first-child”).attr(“displaytext”);
//Your custom code can go here for populating rest of the fields in the form calling user profile through client object model

Paul Tavares has some interesting widgets for People picking and Uploading that look promising, but I have yet to try them out:

A tragic tale of mutliple lists and forms and IE9

I’ve been busy on a project for SharePoint. This particular environment is unique in that the developers do not have access to the farm, and must put any requests through a processed managed by the client to activate features, view ULS logs, etc. In addition, the client managed office has turned off several features, but cannot provide a list of features that are available. So sandboxed features that work in Dev, Test and Staging tend to die when they reach production of unspecified errors.

The use of SharePoint Designer is forbidden, so anything not “out-of the-box” must be created in Visual Studio. To avoid some of these headaches, I try to do everything I can out of box, or through JavaScript and web service calls.

This particular project had a customized form for 30 some lists. No Problem right? Just get the InfoPath form functioning correctly, create a content type, template and deploy, right?

Right…. until the client wants a change to that form, and the form is customized slightly for each list (e.g. pre-populating department name and disabling the field), and you don’t have access to save templates. – Yes, I am dealing with the nightmare of updating content types and then modifying each of the 30 lists back to it’s specific department customization. (Why 30 lists? there are 3 for each department, and no department wants the other one seeing it’s stuff). Oh and the customer wants to be able to import data from one form to another.


  1. I can customize the InfoPath forms and add a list lookup to the other lists for that department.
  2. Creating a single InfoPath form to handle everything really isn’t an option, because the user permissions will prevent some lists from connecting and importing data – preventing the form from opening.
  3. Create a single form using HTML and REST calls and URL parameters to import the appropriate lists and submit the data to the correct list.

I went for option 3. Which works great, except for one tiny issue…. Attachments. The client uses IE9, which is NOT HTML5 compliant, and does NOT support fileReader. Access to a server that can parse PHP is out. So my options are back-end (sandbox hole of death), or something else…

So I tried using Actionscript. Quirky, yes I know, but I trust ActionScript… it usually behaves, and there is already a nice little library for integrating ActionScript and SharePoint: sharepoint-as3-connector
And it worked beautifully until Friday. I suspect network latency to be the goblin behind my SWF not being recognized by IE, and not receiving the actions I send it from JavaScript for the past 2 days.
So I’ve thrown in a little try catch to hide my beautiful attachments flash object if there are issues.
If I find a better solution I’ll post it here.

Using Rest For Everything

I’ve ceased using the “Out of the Box” forms. I don’t even use the WebParts unless I have to.

To me the most useful part of SharePoint is the REST API.

I organize my sites into little armies of lists and document libraries that hopefully the user will never see.

My user will experience the site the way I want them to. I force them into custom home pages and dashboards cultivated with bootstrapped themes. The data pulled via SharePoint services into widgets and forms and charts that dance merrily beneath their cursors.

Microsoft all but abandoned Chart web parts in 2013. The ones you can make with Excel services are clunky and static. So I pull my data from REST and push it into FusionCharts or GoogleCharts or YahooCharts.

You could still use the OOB list view for some things and hack the DOM to spruce up the rendered layout… or you can consume that List into a JSON object and use Angular to bind it to a view with sorting capability.

For me it comes down to least amount of time involved… not just for set up, but for maintenance. If I know I’m going to be asked to group rows and columns, or add totals in a manner that isn’t possible with the OOB view, it’s worth it to set up the Single Page App to do it for you.

List Creation Naming Best Practice

When you create a new List or Document Library or “App” object in SharePoint, the name of Object is the new URL – in essence what we WordPress users would call the “slug” or permalink.

This is a pet peeve of mine. Users consistently create objects without consideration of this fact… Users who don’t understand that simply copying and pasting: cute kittens!

Into an email will actually send the user to:

This gives me heartburn because as the SharePoint admin, I get calls about the link being broken, the site missing, 404s, etc. When what is actually happening is the user or the email client did not encode the ” ” space as “%20” for a link. Why would they.. most users don’t understand why we do things like encode urls or characters.

To avoid this issue, I advise for object creation – ALL object creation, be they fields/columns or lists and apps – all objects should be initially named with numbers and letters – all lowercase, no spaces and no special characters if they can be avoided. It’s easy enough to change the Title or Friendly name of an object after creation, but often it is impossible to change the URL or real name of an object without access to the GAC.

SP Services jQuery

So I was searching for a people picker (more on that later) to implement in my JavaScript form for my SharePoint project, when I stumbled across this:

SPServices is absolutely wonderful. I love not having to code all the gooky CAML, GetList and onSuccess methods to retrieve list items via Web Service from SharePoint.

In my trials with it so far, it performs quickly too.

Some of the methods are only supported in SharePoint 2013, but I’ve success using it for several things in SP2010.

A Mini-Guide to Charts in SharePoint

This guide is primarily directed at SharePoint, but the method that uses REST can really be used on any site, or any CMS where you have access to data via REST.

There will come a day when someone will ask “Could you put that in a Graph?” or “This would be better in a Chart”.

Your first thought “I’m not a Graphic Artist”. Okay… maybe something in Excel will do…. then comes the follow up from the requester – “Oh, we want this for Boss-man’s dashboard” or “this will be on the company intranet”…. and… “it would be great if we could keep it updated in real time”.

I’ve been asked this question enough times by co-workers and managers that I just include chart capabilities standard in any SharePoint site or application I create.
To begin with, you are restricted in your charting capabilities based on:

  • Your SharePoint Environment Version
  • Your SharePoint Environment Location (Internal or External)
  • User Access to your site
  • Administrative file restrictions for your SharePoint Environment
  • Ability to upload and Activate custom WSPs for your SharePoint Environment
  • Your permission access level to the SharePoint site you’re placing the chart into
  • The location of the data you will be using for the chart
  • Type of Chart you want to create
  • Access level to public Shared Folder or location to place global resources (e.g. jquery)

SharePoint Charting Web Part
SharePoint 2010 and earlier have access to a Charting Web Part, which includes a wizard allowing you to browse for data sources within your SharePoint site and create charts from them. As this is a web part, you can set the part to Asynchronously update the chart using the Web Part Options panel. The Charting Web Part is NOT available in SharePoint 2013, however, if you have access to a 2010 instance (and the appropriate permissions) you can export the Charting Web Part, upload it into a 2013 instance and configure it like normal.Excel Charts
All versions of SharePoint support displaying Excel Charts. Excel Charts are useful for doing complex calculations, pivot tables in a local workbook file and displaying the results in a chart. The downfall of the Excel charts is editing and updating the data.

Multiple Lists and IE9.. it continues

So when last we left, I was frantically tearing what’s left of my hair out, attempting to debug what was going on with JavaScript and Flash and Internet Explorer to make them hate each other.
As It turns out, in my scripts, I hide my flash object when it is not being directly accessed by the user. (It’s mimicking an attachment popup, so why would I have it sitting in the middle of the page unless the user wanted to attach something anyway?) I was doing this using “display: none”.
Bad, bad, bad coder!
There is a browser quirk, where if the Flash object is not rendered (e.g. “display: block”), the browser doesn’t recognize the object.
I replace the “display: none” with the “left: -5000px” trick, and viola! Flash and JavaScript and IE are talking and everyone is happy again.

A Word about SharePoint Content Types

When Editing Content types, make sure you are not editing the core content types for your site collection. Editing “Item”, “Document” or “Event” in particular by adding or removing columns and pushing the changes to all content types that depend on these will potentially ruin the functionality of your site. These content types should be locked in a bin, wrapped in chains, put inside a steamer trunk, placed inside a large concrete block and dropped into the Mariana Trench where no-one in your organization will be able to access and modify them.

I mention this as I have just had a small aneurysm after watching 2 weeks of work get blown away because someone modified the “Item” Content type, which ruined the list dependencies I had associated with my InfoPath Form, right as a client was looking at the site.

SharePoint Calendar Colors with JavaScript

Yes, there is a “codeless” way to do this using views and calendars, but you may want to use the JavaScript method to get more than just the standard colors that ship with SharePoint 2010.

How to add color coded categories to your calendars with JavaScript:


This solution uses Calculated Fields to display colors related to a particular category. The Category column MUST be a choice column – a lookup column will not work as look-up columns are NOT allowed in Calculated Field Column equations.

You must be able to add a Content Editor Web Part to the pages where the calendar will be viewed.

Part 1: Setting up the JavaScript:

  1. Copy the following script into a text file: