Month: December 2019

Today (today when I am writing this–not today when the scheduled post will go live), I came across an interesting behavior in ServiceNow that I wasn’t expecting.

I had noticed previously that when you add a custom field to a table, that field is automatically added to the table’s form (at least one of the forms).

Today, I added a field to a table that is parent to a whole bunch of other tables. I had a passing thought that I should check the child tables to see if the field was added to them as well.

As it turns out, it is, but only under certain circumstances. It appears that if you’ve never opened a form up before, then the first time that you open the form up it has some logic that it follows to add some/all/most of the fields in the order that they were created.

So, if you’ve never opened up the form for a child table, and you add a custom field to a parent table, then when you open up the child form, it will have the new field on it.

However, if you’ve ever opened up that form, then adding a field to a parent table won’t impact the fields that are on the child table’s form.

A big thanks to Cory S. from the ServiceNow devs Slack channel for pointing me in the direction of how all of this worked!

Just a quick reminder–when working with the client script on a widget, you can’t use document.getElementById() like you would with normal JavaScript, but the gel function works to fill that need.

A little while ago I needed to set up a new user criteria to restrict access to a catalog item.

As is my usual pattern, once I had set up what I thought was a valid user criteria, I tested my work by impersonating a user who shouldn’t have access to the catalog item and then attempting to access the catalog item.

Much to my surprise, the impersonated user was able to access the catalog item. I went back and checked my script on the user criteria and realized that I had a typo there which was causing it to authorize everyone.

I fixed the script, saved the user criteria, and then impersonated the user again so that I could confirm that they no longer had access to the catalog item.

Contrary to what I was expecting, they were still able to access the catalog item. After several iterations of making changes to the script and then checking the user’s access, I realized that the script had been working correctly from version 2 onwards.

The issue wasn’t with the script, but rather with the fact that ServiceNow caches the access somewhere. As nearly as I can tell, it checked the user criteria the first time that my impersonated user tried to access the catalog item, and then after that it just checked whatever flag it had saved off that indicated that the user had access to that catalog item.

When I pulled up another user–with identical flags to the first user, they were correctly barred from accessing the catalog item.

The next day, my first user was no longer able to access the catalog item, so it appears that some kind of scheduled job either clears out the caching or updates the caching to the latest user criteria on some kind of regular (probably nightly) basis.

 

A little while ago, I needed to create a new notification. The best way to explain what I needed to explain on the resulting email was to include an image in the email.

Actually attaching the image to the email notification was a simple matter, but predictably, the image wasn’t caught in the update set.

I initially though that I was going need to go find where the image was stored in the table that contains all of the attachments, but that didn’t work.

Instead, the solution was simply to export the notification itself to XML, which was a little counterintuitive since everything else about the notification (other than the image) was picked up by the update set, but there you have it.

Exporting the notification to XML allowed me to easily move the notification and attached image up our development stack.