Sunday, Sep 05, 2010
Login

Category: Scripting

Returning Random Records Using GlideRecord

I

had a request from a client recently to generate a random list of records from a given table (specifically the Configuration Item table). These items would be used as a pool of records for a random audit of the records in that table. I don’t think this will be used all that often but I figured I’d throw it out here so that people could use it if they needed it. Here’s the code…


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.


Calculating Change Dates From Change Tasks

C

hange management in Service-now includes the use of a parent ‘Change request’ ticket and (usually) the use of multiple ‘Change task’ tickets that can be assigned to separate groups or individuals to perform specific pieces of work. Because these change task tickets should factor into the overall plan for the parent change request, it often makes sense to take the expected start and end dates of change tasks into account when setting a planned start and end date for the parent change request. The purpose of this script is to allow you to automate the calculation of the planned start and end dates for the parent change request based on updates made to the child change tasks. Whenever an update is made to the expected start or end dates of a change task, this script will run and evaluate the start and/or end dates of the other change tasks for the same change request. The earliest start date and latest end date from the tasks are then populated as the overall planned start and end dates for the change request.


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.


 

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...