Monthly Archives: July 2016

How to disable SharePoint People Picker suggestion cache

Recently, I run across strange issue with People Picker in SharePoint 2013. Our customer who uses Windows classic mode authentication, reported, that after saving the item by clicking on Save in standard NewForm or EditForm, the value specified in User Field is different from the value that they provided in People Picker.

They filled out the user field with the value X, and it was saved with different user Y.

Symptoms:

After saving the standard item form, the item is saved with different user than previously specified in the form.

Applies to:

SharePoint 2013 – Classic Windows Authenticaton mode

Explanation:

By default users resolved through PeoplePicker are stored in LocalStorage (window.localStorage), so next time it doesn’t have to load user details from SharePoint.
However in Windows classic mode it stores SPUserId which is then used when saving value to SPUserField. This causes the problem when the same user reside in 2 site collections and has different IDs.
So basically it works only in the first site collection where the user was resolved. In any other site collections it resolves fine, but SharePoint then uses SPUserId from the local storage, which is the ID from the first collections and completely different value is stored in the field.

Solution:

There is couple solutions for this:

  1. Switch to Claims based authentication
  2. Disable local storage for ClientPeoplePicker (and be aware of the consequences) by setting roperty UseLocalSuggestionCache on the ClientPeoplePicker. This can be done by inserting following javascript into masterpage (directly if you have custom masterpage or through delegate control)

    Please consider the consequences. Local Storage is there for a reason. Evaluate in your farm if disabling local storage for client people picker does not considerably degrade the performance.
  3. There is a way how to just clear the cache used for People Picker (instead of completely disabling it)