Posts Tagged ‘Client scripts’
Posted by Mark Stanger in UI actions Tuesday, 31 August 2010 05:45 2 Comments
M
ost Service-now administrators and consultants know how to configure and use UI Actions. UI Actions are UI elements that can show up on a form or a list as a button, link, or context menu. When these UI elements are clicked they execute some JavaScript. Most of the time UI Actions are used to perform some server-side update to a record or records. In other cases, you can use the ‘Client’ checkbox on the UI Action record to execute some client-side JavaScript (including checking for mandatory fields).
But what if you need to do both? The classic case is when you want to click a button to make an update to a record, but only if the user has provided the correct input first. An example would be a ‘Reopen Incident’ button that changes the state on an incident record from ‘Resolved’ to ‘Active’. Usually you want to require the user to provide some sort of comment or additional information explaining why they are reopening the ticket. The problem is that you don’t always want the ‘Comments’ field to be mandatory so the validation needs to happen at the time the ‘Reopen Incident’ button gets clicked. Validation of mandatory fields needs to happen client-side but the update to your record needs to happen server-side. How can you accomplish both of these things with a single UI Action? This article shows you how.
Posted by Mark Stanger in System Definition Tuesday, 17 August 2010 09:43 No Comments
BSM
maps (Business Service Maps) are a central feature of Service-now.com that allow users to view a visual representation of the Service-now CMDB and the Business Services and CIs that those services are composed of. Service-now BSM maps also allow you to display additional information about (and take action on) the CIs represented in the map through the use of BSM Map Actions. I was recently working to create a BSM Map Action that I wanted to display for particular types of CIs and I couldn’t see how to set up a condition that would allow me to identify the type of CI.
What I learned is that each BSM Map has certain information available through URL parameters and through a ‘Data’ object about each node on the map. I just had to find the right piece of information! The solution was to use something like the following in my ‘Condition’ field on my BSM Map Action definition.
Posted by Mark Stanger in Client scripts Friday, 23 July 2010 09:40 No Comments
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…
Posted by Mark Stanger in Client scripts Friday, 18 June 2010 07:47 3 Comments
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.
Posted by Mark Stanger in Client scripts Thursday, 17 June 2010 13:38 No Comments
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.
Recent Comments