Enhancing the Attachment User Experience in ServiceNow

Attachment Dialog

To attach a file to a record in ServiceNow the user needs to click the “paperclip” button on the top right corner of the screen. The icon is small and thus I usually have clients wanting to make it bigger, move it, or somehow make it more obvious. Note that the code we go through below uses jQuery to manipulate the paperclip element in the DOM; normally it’s best to use the API but unfortunately we do not have any API methods so this is necessary. To do this it depends on where it is, if it is a UI Page or UI Macro (usually Catalog Item) then attachment dialog can be triggered in HTML as below:

Generate a Link on a Form in a UI Macro or UI Page:

<img title="Attachments..." src="images/icons/attachment.gifx" width="16" height="16" border="0" /> Click HERE To Attach Your File.

This solves the issue of making it more obvious and makes it more intuitive. If you wanted to simply make the icon bigger then that is fairly straightforward using jQuery and CSS:
Catalog Item

 function onLoad() { 
    jQuery('button.sc_paperclip').css("font-size","37px");
}

Task Form (Incident/Problem/Change, etc.)

 function onLoad() { 
    jQuery("button#header_add_attachment").css("font-size","35px");
}

So these methods work well in making the Attachment functionality more obvious, but what about if you wanted to automatically “trigger” the Attachment dialog functionality (shown when user clicks the paperclip) when something changes, then you can do so using the following:

Client Script

function onChange(control, oldValue, newValue, isLoading) {
    if (isLoading || newValue == '') {
        return;
    }
    saveAttachment(g_form.getTableName(), g_form.getUniqueValue());
}

How to Make Variables Read Only Using g_form in ServiceNow

Variables Read Only

I was recently working with a colleague who mentioned that he had seen a new (un-documented) g_form method which allows you to set all catalog item Variables to Read Only. As you can probably imagine, this is great news for all ServiceNow developers who in the past had to resort to DOM manipulation, custom Business Rules or lots of UI Policies (thanks to my mentor Mark Stanger for providing information on these options in the past) just perform this trick (makes it so fulfillers of tasks update variables but they can’t be updated from the catalog item request). Without further waiting; here’s the magic:

g_form.setVariablesReadOnly(true);

ServiceNow Brings Real-time Simultaneous Updates in UI16 for Geneva (and some Interesting Results)

Realtime Update Icon

I was recently working with a colleague at Crossfuze (BIG shout out to Eric LeMonnier who found the solution for this) on a weird issue in Geneva. His onChange Client Scripts were triggering even though he wasn’t updating those fields. Upon closer examination it was because another user had modified the same record he was on for a field that his onChange Client Script was looking at (this is what triggers the blue icon seen above). This happens because ServiceNow has added a capability to handle multiple-users updating the same record at the same time, and as a result the fields will change dynamically as other users are updating the form. While this is a very nice feature, and handles the simultaneous update issue that used to occur, there may be some use cases where this is not a desired result. One of the downsides to this behavior is that ServiceNow does not upate “.modifiedFields” (g_form.modifiedFields) and thus it does not appear possible to find out if another user has changed a field using any of the g_form API “published” methods. In order to work around this, we found that it is possible to detect the change using an internal method “_internalChange”. Here is what an onChange script would look like, it will return true or false if it’s an internal or client update and if there hasn’t been a real-time update then it will return “undefined”:

function onChange(control, oldValue, newValue, isLoading, isTemplate) {
if (isLoading || newValue == '' || g_form._internalChange)
return;
}

Please Note: This script should only be used in a limited fashion as it does use a non-published/internal method of g_form, called “_internalChange”. While this does work currently (Geneva Patch 4), it is possible that ServiceNow could change this method later (perhaps publishing it and calling it “.internalChange”) and this script would need to be updated in any areas it has been used.

Please let me know your thoughts and comments. Happy Coding!