Forum Replies Created
-
Posts
-
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.clientPeoplePickerSearchUserMethod:
POSTHeaders (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”
}
}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
Hi Alexander,
That sounds like it is most likely the issue. Our company does remove the license when it disables a user account. Thanks for looking into this.
Joe
In addition, I rearranged the form fields between the forms just to be sure it wasn’t something to do with just the HTML fields. The fields stay in the DispForm order–they don’t switch to the EditForm order.
There must have been something unusual going on, but I don’t know what. I tried reproducing it, but I couldn’t do it with a simple clean list. Not sure exactly what was happening, but I did get it resolved by overwriting the form with an export from a mirror list. Sorry about the false alarm and inability to reproduce the issue! Thanks for your help.
It turns out the issue was a rule/form configuration mismatch. The rule which was supposed to trigger on form load included hiding many fields, but the fields had been deleted from the form itself where the rule was being applied. This did not trigger any errors, and I never could get any output in the console even with debugging on, which seems strange still. However, I was able to rebuild the form and only hide fields which were actually present. With this configuration, the rule triggers and outputs to the console as expected.
So my conclusion is, it seems if the rule which triggers on form load is referencing fields that do not actually exist in the form (even though they exist in the list), the rule may break or otherwise not run–even though the trigger conditions are met (but I never got any error messages to prove this theory).
It is just a normal choice field with “No” and “Yes” options. There may be more to this on our side. I am picking up where another user created the beginning of the form. I will do some more research into this and report back whether or not there is something that requires your assistance. Thanks for your willingness to help.
Oh, I assumed it was possible because in the rule it shows:
RuleID (for use in Custom JS)
I am trying to show or hide an element based on the value in a field. For some reason the rule does not apply when the form loads–just when the field is manually updated afterwards. We do have it set to trigger on “Form load and change of conditions for triggering this rule,” but it seems to only trigger on the change of conditions part. Our condition is just if a particular field is “Yes” and the “If yes” part uses the “Show elements” action while the “If no” part uses the “Hide elements” action. It works if the field is manually updated, but it doesn’t seem to run the rule when the form opens.
My thought was to run the rule on a button click that is part of the form navigation anyway. I will see if I can come up with another way to make sure the rule applies like I want it to.
If I do resort to an action in the button click, is there a built-in action to hide an element from Custom JS?
Hi Alexander,
Can you provide an example of triggering a rule in Custom JS? I am struggling to figure out how to do that with Modern DFFS, and I may be missing it, but can’t seem to find an example (for Modern DFFS) by searching the forum.
Thank you for your help.
Gotcha. Thanks for explaining.
I wanted to make sure you also saw the issue where the dffs_PostCancelAction() on a DispForm is getting triggered when you click the “Edit” button, not only the “Cancel” button. The dffs_PostCancelAction() executes before the form switches to the EditForm. I was seeing this behavior directly in the list when viewing an item and then clicking the “Edit” button.
Thanks again!
Sure, I just have the code below for testing to make sure there should be no delays:
function dffs_PostSaveAction() {
console.log(‘This is the post SAVE action.’);
location.href = ‘https://duckduckgo.com/’;
}
function dffs_PostCancelAction() {
console.log(‘This is the post CANCEL action.’);
location.href = ‘https://www.google.com/’;
}I added Source=https://www.bing.com/ to the URL on the site page with the web part and it always redirects to Bing no matter if I save or cancel – I never end up at Google or DuckDuckGo. I also never get either message printed in the console.
*** Both actions work properly if I cancel or save directly in the list, just not the site page with the web part.
A couple other things I noticed, which I thought I should mention:
It appears the redirect from the page with the web part executes BEFORE the dffs_PostSaveAction() and dffs_PostCancelAction() are executed. Because the redirect navigates away from the page, the post save or post cancel actions are never executed at all as far as I can tell.
Also, when the DispForm is open for an item (while in the list, not through the web part) it appears the dffs_PostCancelAction() is executed if you click the “Edit” button to edit the item. This causes problems if you are using the dffs_PostCancelAction() to redirect the user to a different page because the form was not actually cancelled.
Thanks again for all your work.
