Decrypting Password Fields Automatically

We had an issue recently with some interfaces after client’s Istanbul upgrade. Initially we thought someone may have updated a password on one of the data sources. We had to then do some simple coding as a background script to see what the password actually was (and repeated per interface during debugging).

This led me to write the attached code below. Very simply it adds a padlock icon next to each password2 field, when clicking the icon, it’ll pop up showing the decrypted value.

(password2 fields can be decrypted whereas password type fields such as the password field on the sys_user table use a one way encryption method so this functionality can’t be used on those fields.)

Aug 30 2017 1-01 PM

Note: This uses JQuery to insert the icon so will flag up on an ACE report. It inserts the action in the same manner which g_form.addDecoration uses

Continue reading

Accessing Field Information From GlideRecord

I made an accidental discovery a few days ago. I searched the wiki and couldn’t see any documentation around it. It turns out every field returned in a GlideRecord also comes with a property that contains all the dictionary values.

Why is this useful? For around 99% of the time it’s not and you can pretend it’s not there. For me, I have been writing functionality that automatically checks all scripts in the system that they have adhered to a particular rule set. To do this, I needed to know if a table had any scripting fields on there. Initially I was doing a GlideRecord on the sys_dictionary table searching for the details. However, with this route, no database query was required anymore.
Continue reading

Restricting Returned Client Side GlideRecord Data

The credit for this one goes to Billy Matthews from a comment on one of my previous posts.

Client side GlideRecord is never really recommended to use. There are two main reasons for this:

  • ACLs are enforced and so you will need to ensure that the table and the fields you want have the correct ACLs to enable the user to access the data
  • Performance is not as good as GlideAjax because it brings back all GlideRecord data rather than just relevant data

As for the first point, this still remains an issue and needs to be handled. However, Billy let me know of an undocumented feature within the client side GlideRecord object to restrict what data comes back. Continue reading

Option For Handling UX During Ajax Calls

Update: Added a short video showing the functionality in this example


The above GIF shows the functionality – as you can see the UI gets blocked with a message to “Please wait” – this is customisable by following the documentation on BlockUI page. Also, in the example, it takes a few seconds to get the “Managers name” – this is hardcoded to wait so that you can see the code in action for longer.

Ajax is a great technology and extremely useful for updating a form without the need to save and reload the form.

Often we use it in ServiceNow to facilitate form entry and giving the user additional data/restricting their data etc.

For example, a user enters a server CI on the form, we then update additional fields with current RAM and HDD space. The issue is however, these fields are editable while retrieving the data, and so a user might enter the data while the Ajax call is being created (sometimes the Ajax call is super fast, other times… not so much). So the solution I’m proposing below will automatically add a pop over to block the UI while the Ajax call is being made until it’s returned. Continue reading