Monday, Sep 06, 2010
Login

Category: Client scripts

Change Form View Client Script

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…


Move List Collector Options

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.


Limiting Number of Selections in a List Collector

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.


Testing for a Valid Record

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.


Readonly Variables on a Standard Form

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!


 

Recent Comments

  • Scott Stechmesser: Awesome script to use. Works great. How would you modify it to be able to copy a Catalog UI Policy?
  • Tulio: Perfect!!! Thanks for this.
  • Ron Methias: Another reason why I have stopped going to the official SN documentation sites and make the GURU my...
  • Richard Huss: Ingenious – and somewhat simpler than the way the Incident Resolution best practice plugin does...
  • valor: Joe, that’s one of the reasons why I’m parsing out the URL instead of trying to get the page...