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