Securing .list And .do Pages Via ACLs

Within ServiceNow, anyone can go to any table by manipulating the URL or via the navigation menu.

I.E, if you want to go to the incident table, even if you haven’t access to the incident module, you can just:

  1. go directly via the url: https://sn-instance.com/incident_list.do or https://sn-instance.com/incident.do
  2. in the navigation menu search bar, type incident.list or incident.do

Having ACLs in place makes sure that the actions that you don’t want to happen don’t happen (create, write, read, delete). However, what if you just want to stop navigating to that URL in the first place?

You can stop users getting to the page via the navigation menu by editing the ‘NavFilterExtension’ UI Script (it has very good comments in there and easy to edit to do what you want).

I accidentally stumbled across a neater solution, again using ACLs.
Continue reading

Intercepting Record Access

For years I’ve been working with ServiceNow and every time, one thing that always got to me that I never understood how it was accomplished was when viewing a sc_request record in self service view, it always re-directed to the order summary UI page.

order_summary

I just couldn’t figure it out and just assumed it was some hard-coded logic hidden away from us… until now! (yes, I’m a little excited about this…)

Continue reading

How To Prevent View Inheritance

Issue: For one of my projects, we had different views on the tasks than we did on the parent case. However, if you click on a task with a view called ‘Task view’, when you clicked the parent, the parent would inherit this view (even though we didn’t want it to). It would even ignore view rules set up specifically for that record. This was the same with all reference fields.

Solving this turned out to be a one line piece of code.
Continue reading

Force A View From A Module

Views in ServiceNow are a very useful tool, but there are a lot of little ‘gotchas’ you need to be aware of.

One of these is using the ‘View’ field when creating a module. The expected behaviour is simple, you enter for example the ess view, you’d expect whenever the module was clicked, the ess view would be displayed.

Not exactly how it works though! The video attached shows this in action… The first time you select the module, it’ll select the view you entered into the module. But, if you manually change the view, it will remember this and even the next time the user clicks this module, it’ll use the view which you changed to rather than the view that you selected!

A simple argument to the URL can resolve this issue, and force the view to be what you selected it as.
Note: sysparm_view does NOT work and sysparm_force_view only allows one view to be selectable which isn’t what we’re looking for.

So, the answer? Simply add these details to the arguments:
Continue reading