In SharePoint 2013 I implemented a custom claim provider with search and resolve functionality and everything appeared to work fine. I was able to search and resolve users, grant them permissions to the site, and they were able to login successfully. Everything was good until a user reported a problem with the People Picker. When the user creates a task (in the OOTB Task list), and picks a user for the Assigned To field and save the item, they get the error message “Input string was not in a correct format” against the Assigned To field.
It turns out that this was because I was populating the PickerEntity objects with inappropriate values, namely UserId.
When implementing custom claim providers, you return search and resolve results to the People Picker by creating PickerEntity objects. This class has a property, namely EntityData, which is a Hashtable of additional information that you can populate for the particular user.
Typically you set a property in the EntityData table using a member of the PeopleEditorEntityDataKeys class, as shown below.
entity.EntityData[PeopleEditorEntityDataKeys.Email] = "email@example.com"; entity.EntityData[PeopleEditorEntityDataKeys.PrincipalType] = SPPrincipalType.User.ToString();
One of the members of the PeopleEditorEntityDataKeys class is UserId. I was setting this key to the login name for my user – and this is what caused the problem.
This key should be set to an integer, and should be the SPUser.ID property of the user – which means you typically would not set this key in a custom claim provider. I removed this key from the EntityData table for my users and the issue was resolved.
Other interesting observations
When you select a user, e.g. for the Assigned To field in this instance, and save the list item (or grant permission to the user), that user is created in the User Information List for the site collection if it doesn’t already exist (this list can be found at http://server/site/_catalogs/users). Some, not all, of the values you set in the PickerEntity.EntityData hashtable is actually used to populate the fields for the new user list item. In my testing however, only the PeopleEditorEntityDataKeys.Email and PeopleEditorEntityDataKeys.MobilePhone values work. Being able to set the Email for the user is really important though. It means that the user will straight away be able to receive notifications from SharePoint.
The other observation is that the People Picker seems to be doing some caching on the client side. If you are debugging your claim provider, it is best to test using a new browser session each time.