Category: System UI
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 UI actions Tuesday, 27 July 2010 10:42 No Comments
A
few months ago I wrote about copying change requests using a UI action. While that method works great, it does require you to specify each and every field and value that you want to populate into the new change request. If you’ve got a lot of fields to copy over then you might end up with a pretty big script and a lot of items to copy over. You also need to be aware of any new fields that get added after you create the script and make sure that they get copied if necessary.
The following method works in much the same way, but it copies by performing an insert against the current record (rather than starting from a brand new change record and supplying each value). Because of this, you’re concerned about overriding any of the values (such as start and end dates) that you don’t want to be copied over from the record you are copying. This method works better if you know you want to copy over all (or the majority) of the field values from a given change.
Posted by Mark Stanger in Scripting, UI actions Wednesday, 19 May 2010 07:41 1 Comment
T
his script was designed specifically for easily creating a copy of a variable set but it could be easily adapted to create a copy of any other record (and associated records) in Service-now. Rather than use a field-by-field copy technique, this script works more like an ‘insert’ on the records it touches. Because of this, you get an exact copy without having to specify each and every field to copy. If you don’t want an exact copy of a particular field, you can overwrite it in the script. You can implement this copy functionality to copy a variable set by creating a UI action with the following settings…
Posted by Mark Stanger in UI pages Monday, 8 March 2010 08:43 3 Comments
S
ervice-now’s service catalog interface is designed to give users a more familiar “Amazon.com-like” ordering experience. While this interface meets the needs of most customers, there are areas where certain modifications may be desirable. One of these areas may be the catalog checkout page. The out-of-box setup always presents every user with a specific checkout or ‘ess’ view for the ‘sc_request’ (Request) table. This checkout page is forced every time any user attempts to view a request record using the ‘ess’ view.
But what if you would rather use the standard ‘ess’ view that is similar to the rest of the forms in the system? Something like this…?
While this isn’t a typical modification, this article shows how you could accomplish it.
Recent Comments