Client Script mandatory fields not enforced when moving quickly through UI

[eurban]

On our Incident form, we are using a Client Script to enforce that the resolution code and resolution notes are mandatory when clicking the "Resolve Incident" button.   We are using

g_form.setMandatory('close_notes', true);

in the Client Script to make the field mandatory.

This resolution notes (close_notes) field is hidden until the Resolve Incident button is clicked, so the button must be clicked to display the field.   Our service desk has become so efficient navigating around the UI that they are experiencing behavior that they click the Resolve Incident button as soon as it appears on the screen, which seems to be executing before the Client Script loads so allows them to resolve Incidents without filling out this resolution notes.   I was able to recreate this behavior with just a little bit of practice.

I looked in a personal developer instance and see they set the comments field to be mandatory, also using g_form.setMandatory(), but that they do it in the script of the UI Action "Resolve Incident".   I wasn't able to recreate the issue in the personal developer instance.

Has anyone seen this behavior before or are there any opinions on whether or not this should be expected?

UPDATE:

I compared our Client Script "(BP) Close Mandatory on Close or Resolve" with the out of the box one and ours is almost identical to the OOB one with the exception of us setting one additional field.

In my personal developer instance, I modified the UI Action "Resolve Incident" to comment out the part of the script that makes the comments field mandatory:

     /*
     if (g_form.getValue('comments') == '') {
           //Remove any existing field message, set comments mandatory, and show a new field message
           try {g_form.hideFieldMsg('comments');} catch(e) {}
           g_form.setMandatory('comments', true);
           g_form.showFieldMsg('comments','Comments are required when resolving an Incident','error');
           return false;   //Abort submission
     }
     */

Once I made that adjustment, I was able to recreate this in my personal dev instance after trying it a few times so appears that this behavior is something that can be seen in an OOB.

When I recreated in my personal dev instance, I received the same error that   I mentioned in my response to Kalai below:

Uncaught TypeError: $j(...).popover is not a function(…)                             VM4398 FormAdditionalOptionsMenu.jsx?v=05-21-2016_0850:4
         (anonymous function)   @ VM4398 FormAdditionalOptionsMenu.jsx?v=05-21-2016_0850:4
         k                                         @ VM4385 js_includes_doctype.jsx?v=05-21-2016_0850&lp=Sat_Oct_08_10_44_17_PDT_2016&c=2_42:22021
         fireWith                           @ VM4385 js_includes_doctype.jsx?v=05-21-2016_0850&lp=Sat_Oct_08_10_44_17_PDT_2016&c=2_42:22021
         ready                                 @ VM4385 js_includes_doctype.jsx?v=05-21-2016_0850&lp=Sat_Oct_08_10_44_17_PDT_2016&c=2_42:22021
         D                                         @ VM4385 js_includes_doctype.jsx?v=05-21-2016_0850&lp=Sat_Oct_08_10_44_17_PDT_2016&c=2_42:22021

[Oliver D_sereck]

Do you by any chance use the "UI16 Developer Patch" Application?

I just had the same error "$j(...).popover is not a function(…)" but only on the update set form.

After deactivating and reactivating the UI Script, the issue has gone away.

[eurban]

We don't have this UI16 Developer Patch application installed on any of our instances.   I also received this error while recreating this issue on my personal developer instance, which is kept very close to an OOB deployment.

[Ben Vargas]

Thanks Oliver... I can confirm that I've just seen the same thing in a client instance running UI16 Developer Patch.

It only occurred for one user name which could be replicated on other browsers on his system, and on other computers, including by impersonation. Furthermore, on the developer's system, he could impersonate my account and have no problem while in the exact same sessions (minus the impersonation)... deactivating the UI Script and re-activating it solved the problem. Odd.

james.neal

[cczernia]

The popover is not a function error is usually a cache issue. Clearing the cache (cache.do) usually resolves it.

[eurban · Accepted solution]

I felt it would be helpful to post the response I received from ServiceNow on this issue:

I went over this with my team and we discussed into it and determined that this is how the platform functions. Client scripts, UI polices, and the like cannot be invoked until the document has fully loaded. It's sort of how javascript works as a page can't be manipulated safely until the document is 'ready' 

The best prevention against this that we can think of right now is to create Data Policies or Business Rules as it's server side. I was able to reproduce the issue here OOB as well and then created a Data Policy to prevent update if the close_code and code_notes are not filled out when state switches to Resolved. That worked fine for me as even if I'm able to bypass client side events the system won't still do the update as it will do a server side check prior. 

So it looks like this is expected behavior. In addition to the Data Policy and Business Rule suggested by the ServiceNow tech, I should also mention again that I couldn't reproduce this behavior when the script on the UI Action enforced the mandatory fields.

Since this answers my question of whether or not this is expected behavior and also includes three potential workarounds, it is being marked as the correct answer.