I ran into an issue recently where I discovered that if I set a dot-walked field to mandatory, the form would still submit regardless of the red mandatory indicator.
I had worked (what I thought was) a simple Incident to modify a client script for a newly dot-walked field name instead of the old field name. We had decided that instead of copying the comments journal entries from sc_task up to the request, we would instead just uniformly use the request comments field. The onChange client script which required customer communication notes when placing a Catalog Task in a Pending state were simply overlooked.
Easy ticket - "done before my second cup of coffee" - so I thought!
I modified the client script and visually confirmed the mandatory indicator on the dot-walked journal field when I placed the sc_task.state field in Pending. The idea being that we should notify the customer why their request is now pending.
I returned from a mid-morning meeting to find the incident reporter asking me which environment I wanted her to test in because it still wasn't working. I pulled up a test sc_task record and proudly displayed the red splat of mandatoryness on the form.
"Go ahead..." she said, "Click Submit."
I submit the form. No errors.
"Oh man... That's not good. I'll get on it." I tell her. I start guessing there's somehow a javascript error in one of our onSubmit scripts causing it to bypass the mandatory field checks.
"Easy fix" I think to myself. (I always think that)
After I work on this a little while, I decide to ask for help and open a ticket in HI. I'm told this is working as designed. They point me to Creating New Fields - ServiceNow Wiki where it says this:
A form can be saved with an empty mandatory field, if that field is a reference field (derived from another table) and if the parent field is also blank. However, if the mandatory reference field shows a value from the parent field, then the form cannot be saved if this value is deleted. It is important to note that if the value in the referenced field is changed, the value for that field is changed everywhere it appears.
I was a bit confused by this, and while trying to wrap my mind around it, I notice that if I click into the field, type something and remove the value, then the tab section suddenly indicates a mandatory field is present. Sure enough when I try to submit the form now, I can't do it without entering something in this mandatory field. I can even toggle the mandatory off and on again using the state field's onChange script. The 'fix' seems to hold once I've entered text into that field.
| Section not Mandatory | Section has Mandatory field |
|---|---|
 |  |
I took a look at the DOM and noted the onkeyup function for this field:
I was then able to add the line 9 here to my client script so that my mandatory field enforcement was in place:
function onChange(control, oldValue, newValue, isLoading, isTemplate) {
if (isLoading) {
return;
}
//If we are hitting the pending state or closed incomplete, require a comment
if(newValue == -5 || newValue == 4){
g_form.setMandatory('request_item.comments', true);
//workaround for PRB569134 where SN Dev states this is working as designed
multiModified(g_form.getControl('request_item.comments'));
} else {
g_form.setMandatory('request_item.comments', false);
}
}
I plan on writing a blog post soon about debugging the client side code, which is where we actually find the multiModified function declaration.
7 Comments
