Skip navigation

Developer Community

2 Posts authored by: Deepak Ingale

NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER, ACCENTURE.

 

Ever come across the scenario where you want to restrict the entries in watch list and work notes list on incident form to particular domains or want to allow all domains but prevent certain?

 

Below solution is a customization to out of the box functionality.

 

1) Configure a property as shown below. You may want to make changes to name of the property. Set the value of this property as comma separated domain ids like yahoo.com, gmail.com etc.

 

 

2) Configure display business rule on incident form to set scratchpad variable value from system property created in step 1

 

 

(function executeRule(current, previous /*null when async*/) {


// Add your code here
g_scratchpad.blackListedDomains = gs.getProperty('u_black_listed_domains');


})(current, previous);

 

 

 

3) Configure onLoad client script on incident form.

 

function onLoad() {
   //Type appropriate comment here, and begin script below
   alertOnBlackListedDomains();
}
//addEmailAddressToList('select_0incident.watch_list', gel('text.value.incident.watch_list'), 'Email address is invalid'
function alertOnBlackListedDomains() {
var blackListedDomains = g_scratchpad.blackListedDomains.split(',');


try {
var emailIcons = document.getElementsByClassName('icon icon-mail');
if (emailIcons) {
var watchListIcon = emailIcons.item(0);
var worknoteListIcon = emailIcons.item(1);


watchListIcon.addEventListener('click', function(){
var emailUserInput = gel('text.value.incident.watch_list').value;


for ( var i = 0 ; i < blackListedDomains.length; i++ ) {
if (emailUserInput.indexOf(blackListedDomains[i]) > -1) {
g_form.showFieldMsg('watch_list' , 'Email id entered is from black listed domains' , 'error');
gel('text.value.incident.watch_list').value = ' ';
}
}
});


worknoteListIcon.addEventListener('click', function(){
var emailUserInput = gel('text.value.incident.work_notes_list').value;


for ( var i = 0 ; i < blackListedDomains.length; i++ ) {
if (emailUserInput.indexOf(blackListedDomains[i]) > -1) {
g_form.showFieldMsg('work_notes_list' , 'Email id entered is from black listed domains' , 'error');
gel('text.value.incident.work_notes_list').value = ' ';
}
}
});
}
}
catch(e){
jslog("Error occurred onLoad script " +e);
}
}

 

4) To test, go to incident form and try to enter email id as abc@yahoo.com in watch list of work note list field , you will notice email address is not written inside that field and error message is displayed at the bottom of the field.

 

 

5) This solution is built around the principal that certain domain email ids must be blacklisted. You may have a reverse requirement, like allow certain domains only. In that case, you will require to make changes to property name , associated changes to display business rule and onLoad client script function logic.

 

Note : This is a custom solution which uses DOM or document object manipulation. If ServiceNow happen to change any underlying class associated with dom element, this solution will require maintenacne.

A Race between UI Policy and Client script

 

I happened to work on one issue in past for debugging UI Policies and client scripts.

 

Issue was something like:

 

For one particular state, UI Policy was suppose to set some fields as Mandatory and it was not happening. This was happening when form was loading.

I checked other UI policies as well which were of  higher order than the one which was not working as expected.  But I  could not find anything.

 

I was under the perception that client scripts always run first and then the UI Policies. But, I figured out one exception to this case which is being documented in this blog.

 

So let us start off with some test cases which I had built for this experiment. I have used multiple client scripts and UI Policies for this testing and used one global scratchpad variable to keep track of when particular script gets fired.

 

Steps :

 

1) Configure onLoad client script , you can use any table, In my experiment, I have used "Database Instance"

 

Expected result : set "Description (short_description) " field as "Mandatory" when script is executed.

I got my expected result when this script got executed, so far so good.

 

 

 

2) Now let us try to prove the fact that UI Policies are executed after the client script.

So now let's configure the UI Policy as show below.

I am now setting "Description" field to "Non Mandatory" to test if result of client script are applied in case 1 or result of this UI Policy is applied when form is loaded

 

 

 

Once done, open any of the record form on "Database Instance".

 

You will notice two alert messages, first alert message comes from onLoad client script which we built in step 1 and second message comes from UI Policy which we built in  this step.

Now let's try to figure out what is happening

a) Our onLoad client script when gets fired ahead of UI Policy, it tries to set "Description" field as mandatory.

 

 

b) UI Policy when gets fired after onLoad client script, it then tries to set "Description" field as non mandatory.

 

 

Now let's see what we get on the form.

We see "Description" field is non mandatory. And this is the expected behavior as well since UI Policies are executed later than client script.

3) Now configure onChange client script which gets fired when field "Operational Status" changes

 

 

 

Now intension is to set "Description" field as Mandatory.

Note that, we expect this script should gets fired only when field value on "Operational Status" changes.

Let's see what we get

.

 

 

4) Now, let's configure new UI Policy, lets make this UI Policy as conditional.

Configure the condition when operation status is  "Non - Operational", this script should fire and set "Description" field is "Non Mandatory"

 

 

 

 

 

 

Now change the "Operational " to "Non Operational" and see what we get. You will notice first our "onChange" client script gets fired, and then our "Conditional UI Policy" which we have configured in this step

 

 

 

 

 

 

 

 

This is also an expected result since UI Policy is fired at the very last, so far so good.

 

5) Configure onChange client script as per below screenshot. You will see there is an "isLoading" property which we have used in this script.

 

 

Reload the form and see observations.

 

 

 

 

 

 

 

 

You will notice

1) onLoad client script is executed first when form is loading

2) UI Policy which has no condition is executed, it has a lower order compared to next UI Policy

3) UI Policy which is conditional is executed

4) onChange client script gets executed, but if you closely notice, it the "isLoading" part within a client script is getting executed. This is really important and stood out to be the culprit which was causing field to alter its behavior since it is the part which got fired at very last. Someone has set the field action of mandatory is this portion of the script which was conflicting with the UI Policy.

 

Some of the observations:

 

1) onLoad client scripts are fired first

2) UI Policy with increasing order are fired.

3)onChange client scripts gets executed (onChange) if you put something into the isLoading portion when form is loaded irrespective of field is changed or not. Also it gets executed after the UI Policy.

So make sure not to set fields as mandatory or read only or visible using isLoading property. If you encounter similar issue, that would be hard to debug. Make sure to use "UI Policies" for this case always.

4) onChange client script gets executed if field value is changed for which it is configured, also make sure to put return is true in isLoading portion.

 

 

 

Kindly do not forget to like or bookmark this post if it assists you.

Filter Blog

By date: By tag: