Usando Edit in grid view su uno SharePoint 2016 mi è capitato questo errore
L'utente non esiste o non è univoco
The user does not exist or is not unique
e il campo veniva sbiancato
Errore in quick editErrore in quick edit
ma ovviamente l'utente esisteva, era SharePoint che non riusciva a risolverlo.
Inoltre il comportamento era corretto se l'utente era già esistente sul database.

Indagando nel trace log si capiva che l'errore veniva generato nel metodo GetUserInfoFromMembershipProvider

Medium Exception in SPUtility.ResolvePrincipal. LoginName: 'i:0#.w|sgartit\utenteNuovo', bIsRole: 'False' Scope: 'site', ScopeID: '1ecebccf-a496-4e43-8d58-ff964ad3a1d2', Exception: 'System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.SharePoint.SPManagedCodeInterop.<>c__DisplayClassa.<GetUserInfoFromMembershipProvider>b__6() at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode) at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param) at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode) at Microsoft.SharePoint.SPManagedCodeInterop.GetUserInfoFromMembershipProvider(Guid siteId, String loginName, Boolean bIsRole, Boolean& ... b3261da0-3cfd-207e-4219-40e388a5114e
Medium ...userExists, String& email, String& title, String& userKey, String& mobilePhone, Boolean& isShareByEmailGuestUser)'. b3261da0-3cfd-207e-4219-40e388a5114e
Medium ensureUserExistsInternal2: managedCodeInterop.getUserInfoFromMembershipProvider return values. bSuccess: 'False' wzLogin: 'i:0#.w|sgartit\utenteNuovo' wstrUserKey: b3261da0-3cfd-207e-4219-40e388a5114e
igh L'utente non esiste o non è univoco. b3261da0-3cfd-207e-4219-40e388a5114e
High SPRequest.UpdateMembers: UserPrincipalName=i:0).w|s-1-5-21-1170282442-1734407707-319393842-936, AppPrincipalName= ,bstrUrl=https://sgart.sharepoint.local/hd ,dwObjectType=0 ,bstrObjId= ,lGroupID=462 ,lGroupOwnerId=3 ,bRemoveFromCurrentScopeOnly=False ,bSendEmail=True b3261da0-3cfd-207e-4219-40e388a5114e
...
Analizzando con ILSpy il codice della DLL, si può vedere che il metodo si comporta in modo differente in base alla presenza o meno dell'utente Super Reader sulla WebApplication
ILSpyILSpy
un controllo di questi valori ha evidenziato che non erano impostati.

Una volta impostati
PowerShell: Set super user e super reader
$wa = Get-SPWebApplication -Identity https://sgart.sharepoint.local
$wa.Properties["portalsuperuseraccount"] = "i:0#.w|sgart\SPCacheSuperUser"
$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|sgart\SPCacheSuperReader"
$wa.Update()
tutto ha ripreso a funzionare correttamente.
Potrebbe interessarti anche: