How To Let A User Know Who Last Accessed An Incident

A common requirement I hear a lot is how to give itil users the ability to know that someone else is working on the same ticket as them. Out of the box, ServiceNow have provided an on submit client script which checks if there’s been an update since you’ve been working on the incident. However, my issue with this is it’s happening after the itil user has already spent some time working on the incident when someone else is already dealing with it.

It’s an inefficient way of working. So I came up with a different solution, one that checks when accessing an incident, whether someone else has accessed it since it’s last update within the last 30 minutes.

If someone other than you viewed the incident, an alert will be shown to the itil agent letting them know who accessed the incident and when. This simple solution provides enough information for the itil user to make an informed decision as to how they wish to proceed with the incident.

Continue reading

How To Pass Sensitive Data Via GlideAjax

Sometimes the data that you’re passing back from the client is sensitive data which nobody should be able to read (including administrators).

One particular instance for this is if you are passing a password back to do validation.

Also, sometimes some GlideAjax’s you just do so many times, that it’ll clog up the logs and possibly cause performance issues with the constant writing.

The logs I am talking about here are the Apache Tomcat logs (https://instance.service-now.com/channel.do?sysparm_channel=logtail)

Give it a go, have one window open with the logs and in another window run a GlideAjax and watch the information that’s written to the logs.

There’s a very simple parameter which you can use to prevent this logging:
Continue reading

Help With Debugging ClientSide Scripts

Client side scripts are used extensively in ServiceNow. Whether from client script, UI scripts, UI policies, or back-end JS file includes (and a few other places but you get the point!).

It’s all fine until a script falls over and you get a javascript error. Checking the error in the javascript debugging console in whichever browser you choose will show you where it fell over but it’s not always clear exactly where this script lies and therefore where to fix it.

The issue (which is usually a very good thing by the way), is ServiceNow automatically puts all these client scripts that are needed to be loaded into big js_includes files. This basically gets all the scripts that need to be loaded, throws them into one big file and delivers it all at once, saving multiple round trips back and forward fetching each file.

So when a script fails, a lot of the times it’ll be in the js_includes file which doesn’t really help with debugging at all (well it does slightly help).
Continue reading

Quicker Way To Dynamically Add Options

There are many scenarios when you want to dynamically populate a select box with the appropriate options. ServiceNow have even given us a shortcut method to populate the choice field in the GlideForm API using g_form.addOption.

This is usually adequate for populating select fields. However, if you have a large number of values that you need to add, you may notice a performance hit on the end users screen (of course as it’s client side, this is dependant on a number of factors including, but not limited to, browser specification, operating system, machine specification).

This was brought to my attention on a project I was working on and I was tasked with finding a solution. I had one of two routes to go down:

  1. Remove the dynamic select field
  2. Find a more efficient way of adding the options

As the select field was a requirement, I of course went for option 2 (plus it seemed a lot more fun to solve! 🙂 ). Let’s take a closer look shall we…

Continue reading

Client Side GlideRecord Security

 

This bug had me scratching my head and pulling my hair out for a good couple of days before I finally realised there must be a bug. Let me explain….

Server side GlideRecords do not adhere to ACLs. For example, if you have a write rule on a field which prevents anyone from writing to this field, if a UI action attempted to write to this field using a server side GlideRecord it would work just fine.

This is intended as an end user cannot run custom GlideRecords themselves so any attempt at any CRUD (create, read, update and delete) operation is actually intended by the ServiceNow implementer.

As anyone can write a custom client side GlideRecord using any browsers javascript console, client side GlideRecords must follow and evaluate all CRUD rules. So far so good right? Wrong! CRUD rules on client side GlideRecords aren’t evaluated quite right!

Continue reading