SATURDAY, MAY 19, 2012

Category: Client scripts

H

ere’s a useful script I’ve used before to grab parameters from a URL in Service-now.com. Simply pass the name of the parameter into the function and it will return the corresponding parameter value.

So if you had a Service-now.com URL that looked like this…

https://demo.service-now.com/incident.do?sys_id=-1&sysparm_query=active=true&sys_myparm=abcde

You could get the value of the ‘sys_myparm’ URL parameter by calling the function below like this…

var myparm = getParmVal('sys_myparm');

Here’s the ‘getParmVal’ function…

Learn more ...

S

ervice-now.com has a nice tabbed form interface that allows users to save some screen real estate by collapsing all form sections and related lists and presenting them in a tabbed format. Tabbed forms are explained on the Service-now wiki.
This post explains how you can use client scripting to change the active tab selection in a form section or a related list. This might come in handy if you want to make a particular tab of information more visible in different situations. Special thanks to Joseph Bennett for doing the real work figuring this out for me :) .

Learn more ...

J

ust a quick post today about something that I end up dealing with on most deployments. The requirement often comes to me as this…

How do I hide this form icon for some users but not others?

This request can apply to different types of icons, but is often asked about the ‘Search Knowledge’ (KB Search) icon that shows up in a default Service-now installation next to the ‘Short Description’ field. This article shows how you can remove this icon (or any other icon image) selectively using client scripts.

Learn more ...

Service-now allows administrators a lot of flexibility in defining which elements appear on a particular form or list. The set of fields and related lists that appear are collectively defined as a View. One common configuration task is to somehow limit access to a particular view based on a user role or some information on the record being viewed. Instructions for working in some of these scenarios can be found here…

View Rules
Restricting Form Views by Role

Neither of these methods work if you need to change the view of a form from a client script or a UI action. In order to do that, you can call the ‘switchView’ function as follows…

Learn more ...

H

ere’s a cool catalog client script that I figured out for a client. It allows you to move one or more selected options from one side of a list collector variable slushbucket to another. Using the script is pretty straight forward. Just supply the name of the list collector variable you are working with, and then make sure you provide an array of option IDs to move from one side to another. The option IDs need to be added to the ‘selectedIDs’ array in the middle chunk of code. The code below is set up to move ALL options in the right column of a slushbucket to the left.

Learn more ...

L

ist collector variables are a great way (currently the only way) to allow a user to select multiple options from a referenced table in a single variable on a service catalog item. The list collector variable allows you to choose from one to many (potentially hundreds or more) selections. What if you wanted to limit the number of items that a user could select? This script does exactly that. It restricts the selected items list on a list collector variable to whatever amount you choose. Just use the catalog client script below and set the variables for the maximum number of selections and the name of the variable to apply the restriction to.

Learn more ...

T

oday I came across a scripting issue that I actually see quite often. I can’t ever remember it when I need it so I’m going to document it here. The issue is this: when working in a client script or business rule, I need to only have the script run if the record is a valid record. For me, this issue really only comes into play when working with client scripting or UI policies. For example, I only want a script to run if the record hasn’t been submitted yet. The following scripts show how you can test if a record is a new record or not in your scripts.

Learn more ...

A

while ago I helped to answer a forum posting for someone who was looking for a way to present catalog variables to an end-user on a Request Item form but restrict the editing of those variables. At the time, I came up with a solution that worked, but that I really wasn’t happy with. I recently came across another forum posting where the poster wanted to do something similar. The difference for the most recent poster was that the variables were to be shown on an Incident form (which had been generated by a record producer). There were some subtle differences in the way variables were presented on the different forms that made my original script unusable for the incident form. So, I’ve had to revisit this topic to come up with a better solution and I’ve decided to compile all of the different options for making variables read only on a regular form. These solutions can be used in a variety of places, but will most often be applied to the Catalog Item, Catalog Task, Incident, or Change Request tables. Enjoy!

Learn more ...

A while ago I wrote about some of the different ways to customize the autocomplete search behavior for a reference field. I saw a forum post the other day where the poster asked if it was possible to create aliases for records so that they could be searched on. For example, what if you had a CI called ‘ABC’ but everybody knew it by the name of ‘XYZ’? While support for this type of searching isn’t really built into Service-now, it is possible to add this kind of behavior to a reference field. If the CI just had a single alias, you could probably just customize the display value and do a ‘contains’ autocomplete search as described in the article previously. For this specific scenario I think that there might be a better way to accomplish the same thing.

Learn more ...

F
orm buttons and context menus are usually a desirable piece of functionality to include on your form. I have seen scenarios before however, where I needed to limit the options available to a user so that they could really only perform one action. The first options that I would consider in these situations is to simply modify the ‘Condition’ field (for role-specific or other criteria) or the ‘UI Action Visibility’ related list (for view-specific criteria) on the particular UI action that I wanted to remove from the user’s view. This is obviously the best and simplest method since it falls in line with the design of the product and doesn’t really require any unusual override of other system behavior.

Remove Buttons-Roles View
But what if you need to disable something like the ‘Submit’ button on just a single view of a single form? What if you wanted an easy way to disable everything BUT one button based on a change to a particular field? Modifying the UI action condition in these scenarios might not make sense because you don’t want to include a one-off condition for just a single use case or (in the onChange scenario), the UI action conditions are only evaluated on form load so they wouldn’t apply anyway.

This article shows a couple of client script functions that allow you to remove (show/hide) any button (or all but one button)…and, if necessary, disable the form header right-click context menu entirely.

Learn more ...


Latest Comments

  • Jim Coyne: I’m not sure exactly what you are looking for, but can you use “window.location” in your...
  • Ian: Might want to check the single quotes around ITIL in the condition line, they gave an error for me until I...
  • Mark Stanger: That’s correct. This returns instance URLs. I don’t have an equivalent currently that...
  • ND: Hi Mark, This is very useful information. I am looking for similar method to find URL of a site created by us. We...