Unable to check record history through context menu list if onSubmit functionality fails on the form

[siva krishna M2]

Unable to check record history through context menu list if onSubmit functionality fails on the form but able to check the calender history of the form.

I want to check the history (list) of the closed incident. Through context menu when i go through History=>List the page is not redirecting to audit page and i found that it is checking on-submit scripts. Is there a way to turn off the functionality of checking on submit scripts instead of modifying the on-submit scripts for the form.

Could you please elaborate the functionality working in the backend when we go click on History=>List in context menu? Where(in which technical component) the on-submit validation is checking?

[Maik Skoddow]

Hi @siva krishna M2 

to my mind, everything works as designed/intended.

Basically it's a bad user experience if any client scripts prevent form submit, although nothing has changed. The question is: How could the form saved before if the client script is preventing this?

Maik

[siva krishna M2]

Hi @Maik Skoddow 

There were existing closed incidents with short description as "test" before creation of onSubmit client scripts. when we are checking the audit history of those closed records from the form we encountered this issue.

As a workaround, we updated the onSubmit client script using below script

function onSubmit() {
//Type appropriate comment here, and begin script below
var b = "test";
var k = g_form.getValue('short_description');

var t = g_form.getValue('state')

if(t!=7)//state is not closed

{
if(k.indexOf(b)!=-1)
{
return false;
}
}

}

Finally concluded that this is functioning like UI action gsftSubmit(null,g_form.getFormElement(),action name) which works similar like this first it will validate the onSubmit scripts then go for the server side scripting function

We don't know which technical component checking the onSubmit validations when we click on History=>list in the form context menu

Apart from it there are other ways as well:

1) We can create incidents through server side scripts with short description as "test" which won't check onSubmit client scripts validations.

[xiaix]

What the OP is referring to is, IMO, easily understandable as to what's happening.  If a table has auditing turned on (dictionary collection), if you're viewing a record (in OP's case an incident record), you can right-click in the header of the record and choose History -> List.

When you click on "List" to view the history of that record, the form "submits" by default.  This is in fact very frustrating because the incident ticket could have fields you don't want to update and all you want to do is view the **bleep** history, not update the form.  IMO, this is bad design on ServiceNow's part to force an update.  

Anyway, there's an OOB "UI Macro" called context_form_header.  In that UI macro, near the bottom of that script it calls in yet another UI Macro '<g:history_context />'. Within that history_context UI Macro, there's this code:

        <script>
            function showHistoryList(){
               if(g_form)
                  g_form.checkMandatory = false;
               if (window.g_sc_form)
                  window.g_sc_form.checkMandatory = false;
               gsftSubmit(gel('show_history'));
            }
            mHistory.addHref("${gs.getMessage('List')}", "showHistoryList()");
         </script>

So you can see, it's calling gsftSubmit(gel('show_history'));

That's how and why the form is submitting, which like I said, is a poor design choice by ServiceNow.