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

[Kalaiarasan Pus]

Is the client script onsubmit or onchange?

[eurban]

Good question!   It is onSubmit.

[Kalaiarasan Pus]

That shouldn't happen unless some script is breaking and thus not allowing other scripts to run. First I will open the browser console and move the ticket till closure and see if any scripts are breaking.

Also, how are you checking it? Can you share the script?

[eurban]

I put a console log statement at the beginning of the client script while reproducing the behavior.   I was suspicious of a conditional return statement near the top of the script that it may have been short-circuiting it as there was a check for the field using:

!g_form.getControl('close_notes')

The log line is not written to the console log in the case where I am able to close the incident without filling in the resolution notes, so it seems that the client script isn't even entered for this case.   Along with that, I noticed every time that this undesirable behavior occurs, I am getting the error:

Uncaught TypeError: $j(...).popover is not a function(…)                                                                               FormAdditionalOptionsMenu.jsx?v=05-23-2016_1554:4
         (anonymous function)   @ FormAdditionalOptionsMenu.jsx?v=05-23-2016_1554:4
         k                                         @ js_includes_doctype.jsx?v=05-23-2016_1554&lp=Mon_Aug_08_12_38_05_PDT_2016&c=8_115:22013
         fireWith                           @ js_includes_doctype.jsx?v=05-23-2016_1554&lp=Mon_Aug_08_12_38_05_PDT_2016&c=8_115:22013
         ready                                 @ js_includes_doctype.jsx?v=05-23-2016_1554&lp=Mon_Aug_08_12_38_05_PDT_2016&c=8_115:22013
         D                                         @ js_includes_doctype.jsx?v=05-23-2016_1554&lp=Mon_Aug_08_12_38_05_PDT_2016&c=8_115:22013

I believe this is going to be a HI incident.