Unlicensed user issue

[Joe Penland]

I am encountering an issue I am struggling to properly address, and I was wondering if you might be able to resolve it in code or have any suggestions. We have modern DFFS handling forms on some lists which have people fields. When a user leaves our company, their account is disabled, and their license is removed. I am finding when a form is edited which includes one of these disabled and unlicensed users, the form cannot be saved because of an error in the “validateupdatelistitem” call that occurs prior to the form being saved. The error is, “We couldn’t find an exact match.”

I have also noticed that when one of these users exist in a list item, they do appear in the display form, but when I go to edit the form, the user does not appear in the people field because they did not resolve properly in the people picker. However, unless I modify the people field, the unresolved user will be sent to the “validateupdatelistitem” endpoint—even though they are not visible in the edited form—and cause the error explained above.

I can see the network calls to “_api/SP.UI.ApplicationPages.ClientPeoplePickerWebServiceInterface.clientPeoplePickerSearchUser” where the unlicensed users return empty values and the licensed users return all the data the people picker needs. Is it possible for you to handle removing users who do not resolve when the edit form loads the people fields so they are not passed to “validateupdatelistitem” prior to saving?

[Alexander Bautz]

Hi,
Which version of Modern DFFS are you running?

Alexander

[Joe Penland]

1.0.68.0

I can upgrade to the latest if needed.

[Alexander Bautz]

I did one change in v1.0.67.0, but I’ll look into it again and se if I can get a fix into the next upcoming release. I plan to release it over the weekend.

Alexander

[Joe Penland]

Thank you. I’ll test it out as soon as I see it.

[Alexander Bautz]

I have included a fix for this issue in the new v1.0.71.0 – see change log here – Let me know how it works out.

Alexander

[Joe Penland]

Hi Alexander,

I apologize for the delay in responding. I upgraded to 1.0.71.0 last Monday and still saw the same behavior. I thought I would let it settle overnight and check again to be sure the new version was being used, but then I forgot to follow up until today. I am still seeing the “We couldn’t find an exact match.” message. It appears the unresolved user is still being submitted when I save the form. I am using the web part to show the form, so I thought maybe it works directly in the library, but when I tried there, it didn’t work either.

Joe

[Alexander Bautz]

Do you see the same in the developer console as you originally did?

The fix I attempted does a “ensureUser” call for each of the users when the form loads – can you look at the developer console (network tab) and try to identify the calls and see what they return?

Email me some screenshots of what you can find so I can try to figure out why it doesn’t work in your setup.

Alexander

[Joe Penland]

Interestingly enough, the “ensureUser” call resolves the user properly. I wonder if this is because it is checking against the cached users on the site. The user does exist there, but the “validateUpdateListItem” call still fails because the user is still present. The user still exists in the tenant, they have just been disabled and the license has been removed.

I notice that when the edit form loads there are calls to “_api/SP.UI.ApplicationPages.ClientPeoplePickerWebServiceInterface.clientPeoplePickerSearchUser”. This appears to be made by the people picker fields, and I see one call for each user to resolve. The check on the user who is unlicensed and disabled returns an empty array, while the checks for all normal licensed users return data. I tested this myself to see if this endpoint could be used and it worked for me. Would it be possible for you to use that endpoint (or tie into the calls the people picker fields are already making)?

Endpoint:
_api/SP.UI.ApplicationPages.ClientPeoplePickerWebServiceInterface.clientPeoplePickerSearchUser

Method:
POST

Headers (this is what I used in testing based on mimicking the network calls, not sure what is required):
{
“accept”: “application/json”,
“content-type”: “application/json”,
“content-length”: “LENGTH_OF_BODY”
}

Body:
{
“queryParams”: {
“AllowEmailAddresses”: true,
“AllowMultipleEntities”: false,
“AllUrlZones”: false,
“MaximumEntitySuggestions”: 1,
“PrincipalSource”: 15,
“PrincipalType”: 1,
“QueryString”: “EMAIL_ADDRESS_TO_TEST@domain.com”
}
}

[Alexander Bautz]

Thanks for the detailed feedback. I’ll check out the endpoint and see if it might work better than the EnsureUser endpoint in this case.

I’ll try to get a new version out next week.

Alexander

[Author]

Posts