After a bit of digging I was able to figure out how ServiceNow was doing those types of comparisons for update sets and versions of Business Rules, UI Pages, etc. They’ve got a number of different script includes that take the different XML updates and then compare the various parts of them. Down under the hood a little ways there is a class that they have to compare between actual text values. Finding this was the jackpot since it allowed comparing just those things that I specifically wanted to compare. Using this class ended up being a relatively straight forward process, but did require some scripting (including JellyScript) so it may not be for the faint of heart.

Here’s what it will look like in the end:

Here’s what it will look like in the end.

The biggest part of the challenge is handled by ServiceNow’s “Differ” script include. This class has one main function that is used to do the magic: diff.

The diff function takes in four parameters:

• text1 – The first string that will be used in the comparison
• text2 – The second string that will be used in the comparison
• name – The label for what you’re comparing. Most likely going to be the field label for the field that you’re comparing. This shows up in a column on the left of the comparison
• change – An optional parameter that indicates whether to return a result if the strings match

The end result of this is a string with part of a table that contains the strings compared line by line just like you see when comparing differences in an update set preview. It is assumed that the results of this function will be included as part of a table given a specific class so that the rows are formatted correctly. There is an XML header that needs to be removed from the result but essentially this is the code needed to use the result of the function:

diff_output
<table class="diff">
<thead>
<tr>
<th class="top_left_field"></th>
<th class="texttitle" colspan="2">Left Label</th>
<th class="texttitle" colspan="2">Right Label</th>
</tr>
</thead>
</table>

The left and right labels identify what it is that you’re comparing and diff_output is the output from the function.

There are a few different ways this functionality can be used; after looking at it I opted to use a GlideDialog window and UI Page to provide a similar experience to what is already used in other places. To do this a UI Action needs to be set up to open the dialog window and a UI Page needs to be set up to do the comparison and show the results.

Here’s what’s needed in the UI Action. It’s relatively generic other than the UI Page that is referenced. For the fields that I haven’t included you can use the default or adjust it as you see fit:

Name: Compare to Current
Table: table that has the version info you want to compare to the current record
Client: true
Form link: true
List context menu: true
Onclick: showTheComparison()
Script:

function showTheComparison(){
//Get the values to pass into the dialog
var sysId;
// Check if this is called from a List, if so, rowSysId will have the Sys ID of the record
if (typeof rowSysId == 'undefined'){
// If it's called from a form, get the Sys ID of the record being shown
sysId = gel('sys_uniqueValue').value;
} else {
sysId = rowSysId;
}
//Initialize and open the dialog
//Instantiate the comparison dialog, the parameter is the name of your UI Page
var dialog = new GlideDialogWindow("compare_kb_to_version");
//Set the dialog title
dialog.setTitle("Version Comparison");
// Pass in the Sys ID of the record to compare
dialog.setPreference("version_sys_id", sysId);
// Set the size
dialog.setSize('95%', '95%');
//Open the dialog
dialog.render();
}

The UI Page has a little more to it since it needs to reference the specific tables and fields where the two versions are stored.

Name: compare_kb_to_version
HTML:

<!--?xml version="1.0" encoding="utf-8" ?-->


/*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Diff magic using the SN Differ class
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*/
// variable to aggregate the differences for the fields into
var diff = "";
// get the SN object that does the comparing
var differ = new Differ();

/*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Values needed for the diff
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*/
var left_label = "Published Article";
var right_label = "";

// Get the version info from the dialog property
var version_sys_id = RP.getWindowProperties().get('version_sys_id');
var version = new GlideRecord("kb_submission");
if (version.get(version_sys_id)) {
// Set the label for the right side of the difference
right_label = "Version: " + version.number;

/*~~~~~ Short Description field ~~~~~*/
// Pass in the strings that need comparing
// u_kb_article is the reference field that refers to the KB article that the version is for
var kb_short_description = differ.diff(version.u_kb_article.short_description, version.short_description, version.short_description.getLabel(), true);
// Strip off the XML header
var starter = kb_short_description.indexOf("?>");
kb_short_description = kb_short_description.substring(starter + 2);
diff += kb_short_description;

/*~~~~~ Text field ~~~~~*/
// Pass in the strings that need comparing
var kb_text = differ.diff(version.u_kb_article.text, version.text, version.text.getLabel(), true);
// Strip off the XML header
var starter = kb_text.indexOf("?>");
kb_text = kb_text.substring(starter + 2);
diff += kb_text;

}

 

${diff}
<table class="diff">
<thead>
<tr>
<th class="top_left_field"></th>
<th class="texttitle" colspan="2">${left_label}</th>
<th class="texttitle" colspan="2">${right_label}</th>
</tr>
</thead>
</table>

The first section of code in the g:evaluate tag sets up the Differ class. Then we get the labels for each side of the comparison. Then we get the comparisons for each of the fields that we’re trying to compare. In this case we’re comparing the Short Description and the Text fields. The comparison results are cleaned up and concatenated in a string to be used inside the wrapper HTML code that sets up the header and styles.

Once you’ve got all of that in place, seeing the differences is just a click or two away.

The post Comparing the Differences Between Two Strings appeared first on ServiceNow Guru.

function addApprovalGroups(){
   //Open a dialog window to select Approval Groups
   var dialog = new GlideDialogWindow('add_approval_groups');
   dialog.setTitle('Add Approval Groups');
   dialog.setPreference('sysparm_groupQuery', 'active=true');
   dialog.render();
   //Make sure to not submit the form when button gets clicked
   return false;
}

The UI action opens the dialog with a call to a specific UI page. The UI page is what contains most of the logic for the slushbucket. It includes the actual HTML (which pulls in the slushbucket and UI buttons from UI macros) as well as the client script that loads the groups and makes a call to insert group approval records.

<?xml version="1.0" encoding="utf-8" ?>
<j:jelly trim="false" xmlns:j="jelly:core" xmlns:g="glide" xmlns:j2="null" xmlns:g2="null">
   <TABLE BORDER="0">
      <TR>
         <TD>
            Please select the groups you wish to add as approvers.
         </TD>
      </TR>
      <TR>
         <TD>
            <!-- Include the 'ui_slushbucket' UI macro -->
            <g:ui_slushbucket/>
         </TD>
      </TR>
      <TR>
         <TD align="right">
            <!-- Include the 'dialog_buttons_ok_cancel' UI macro -->
            <g:dialog_buttons_ok_cancel ok="return continueOK()" cancel="return continueCancel()" ok_type="button" cancel_type="button"/>
         </TD>
      </TR>
   </TABLE>
</j:jelly>

//Called when the 'OK' button gets clicked
function continueOK(){
   //Get the selected values from the right slushbucket
   var values = slush.getValues(slush.getRightSelect());
   //Get the sys_id of the current record
   var taskID = g_form.getUniqueValue();
   //Make sure we have at least one selection
   if(values == ''){
      alert("At least one group must be selected");
      return;
   }

   //Add the group approval records
   var ajax = new GlideAjax('GroupSelectAjax');
   ajax.addParam('sysparm_name', 'groupsAdd');
   ajax.addParam('sysparm_taskID', taskID);
   ajax.addParam('sysparm_values', values);
   ajax.getXML(addGroupResponse);
}

//Called when we get a response from the 'continueOK' function
function addGroupResponse(){
   GlideDialogWindow.get().destroy();
   GlideList2.get('').setFilterAndRefresh('');
   return false;
}

//Called when the 'Cancel' button gets clicked
function continueCancel(){
   //Close the dialog window
   GlideDialogWindow.get().destroy();
   return false;
}

//Called when the form loads
addLoadEvent(function(){
   //Load the groups when the form loads
   slush.clear();
   var ajax = new GlideAjax('GroupSelectAjax');
   ajax.addParam('sysparm_name', 'getGroups'); 
   ajax.getXML(loadResponse);
   return false; 
});

//Called when we get a response from the 'addLoadEvent' function
function loadResponse(response){
   //Process the return XML document and add groups to the left select
   var xml = response.responseXML;
   var e = xml.documentElement; 

   var items = xml.getElementsByTagName("item");
   if(items.length == 0)
      return;

   //Loop through item elements and add each item to left slushbucket
   for (var i = 0; i < items.length; i++) {
      var item = items[i];
      slush.addLeftChoice(item.getAttribute('value'), item.getAttribute('text'));
   }
}

Many times, you can stop with the UI page. In this case, it makes sense for us to do some of our heavy-lifting for populating the groups in the slushbucket and creating group approval records at the server. The client scripts in the UI page make GlideAjax calls to the functions in a script include. The script include performs the query and returns an XML response back to the client so that it can continue.

var GroupSelectAjax = Class.create();

GroupSelectAjax.prototype = Object.extendsObject(AbstractAjaxProcessor, {
   //Get and return a list of groups (name and sys_id)
   getGroups: function() {  
      var gr = new GlideRecord("sys_user_group");
      gr.orderBy('name');
      gr.addQuery('active', true);  
      gr.query(); 

      //Add the available groups to select from
      while (gr.next()) {
         var item = this.newItem();
         item.setAttribute('value', gr.getValue('sys_id'));
         item.setAttribute('text', gr.getValue('name'));
      }
   },

   //Take a taskID and group sys_id values and add 'sysapproval_group' records
   groupsAdd: function() {
      var taskID = this.getParameter('sysparm_taskID');
      var values = this.getParameter('sysparm_values').split(',');
      //Iterate through the group sys_id values
      for(x in values){
         var rec = new GlideRecord('sysapproval_group');
         rec.initialize();
         rec.parent = taskID;
         rec.assignment_group = values[x];
         rec.approval = 'requested';
         rec.insert();
      }    
   }
});

The post Creating a Custom Slushbucket Popup Dialog appeared first on ServiceNow Guru.

This article is an extension of an idea presented on the ServiceNow wiki that shows one way to approach this problem. The solution described here overcomes some of the problems with the wiki solution and gives a little bit more detail about how the solution works so that it’s easier for you to customize on your own. I’ll also include some formatting examples and show how you can add more than one additional field to the checkout screen.

Add your new field(s) to the checkout screen

1Modify the ‘servicecatalog_cart_template’ UI Macro as follows…
Look for the section of code that has hidden input elements (designated by ‘input type=”HIDDEN”‘) and insert the following line directly after the other hidden elements. This line of code is used to store the unique cart ID for the user session. This ID will be referenced later on in a UI Page client script.

<input id="cart_id" name="cart_id" type="HIDDEN" value="$[sc_cart.sys_id]" />

Next, find the section of code that looks like this…

${gs.getMessage('Requested for')}:<label for="requestor_location">${gs.getMessage('Deliver to')}:</label>$[SP]
$[sc_cart.requested_for.getDisplayValue()]



<textarea id="requestor_location" style="width: 100%;" name="requestor_location" rows="4" wrap="soft"><br />
$[sc_cart.delivery_address]<br />
</textarea>$[SP]

And insert the following code directly below it. This sample code adds a ‘Company’ reference field to your checkout form. You’ll need to customize this code to add your own field(s).

Company:$[SP]
$[SP]

If you need to add multiple fields you can do so by adding the appropriate html. It’s also pretty simple to change the layout of the fields and their columns if you understand a little bit about html tables. Here’s an example that shows how to add two fields (Company and Requested Date) to the checkout form in a 2-column layout.

Company:Requested Date:$[SP]

$[SP]

Passing the field values to the catalog cart and request

2Add the following script to the ‘Client Script’ field on the ‘servicecatalog_checkout_one’ UI Page (note that this sample is for the 2-field checkout addition and you’ll need to modify this script on the ‘var newField1’ and ‘var popVal’ lines if you’re only using one field). Its purpose is to get the values from the new checkout fields as they change and send them to the request ticket when the request is generated. You’ll want to pay attention to the separators used here to designate when a new field/value pair starts. The underlying code reserves some characters in this situation so I made a judgment call based on what I thought would work most of the time. The bottom line is that these need to match what you look for in the business rule in the next step.

If you need to add additional fields to your checkout page you’ll need to customize this function to include those additional field/value combinations.

function setCartValue() {
var fieldSeparator = '^'; //Cannot be ':' or '='
var nameValSeparator = 'IS'; //Cannot be ':' or '='

//Get the new field elements we've added
var newField = gel('core_company');
var newField1 = gel('requested_date');

//Query for the user cart
var cart_item = new GlideRecord('sc_cart_item');
cart_item.addQuery('cart.user', g_user.userID);
cart_item.addQuery('active', 'true');
cart_item.query();

//If found, add the field/value pairs to the 'hints' parameter for the cart
if(cart_item.next()) {
//Aggregate all of the field-value pairs
var popVal = 'company' + nameValSeparator + newField.value + fieldSeparator + 'requested_date' + nameValSeparator + newField1.value;
//Send the values to the request record
cart_item.hints = "";
cart_item.update();
}
}

If you’re just adding a single field to the checkout page (and have no plans to potentially add more fields) then you could simply modify the script above to eliminate the ‘u_cartpop’ and ‘popVal’ pieces all together. These pieces exist for the sole purpose of passing multiple field/value pairs on to the request. If you just need a single field, comment out the first ‘popVal’ line, change ‘u_cartpop’ to the name of the field on the request form you need to populate, and use the single field example included in step 1 above.

If you are looking for a more extensible solution that you could add to in the future, or if you already know that you will need more than one field added to the checkout form, read on!

Populating the field values

—This final portion is the major piece that I’ve changed from the solution described on the ServiceNow wiki. The whole purpose of these last steps is to allow you to populate more than one field on the request ticket. The ‘hints’ parameter in the UI Page client script above only accepts a single name/value pair to set. To work around this limitation, the script above concatenates all of the name/value pairs and passes them in as a single string to a custom field you need to create called ‘CartPop [u_cartpop]’.

3Create a new string field on the Request [sc_request] table named ‘CartPop’.
The field will be used to capture the field/value pairs string being passed from the checkout page. It should have a length that is long enough to accommodate all of the field/value pairs being passed in from your checkout page. A 1000 character limit should be more than enough to pass in values from several additional fields. This field can be removed from the request form once it is created.

4Create a new business rule on the Request [sc_request] table with the settings as shown below. The purpose of the business rule is to get the value of the ‘u_cartpop’ field, parse the field/value pairs out of it, and populate those values into the correct field(s) on the request record.

//Get the values to populate and split into name/value pairs
var popVals = current.u_cartpop.split("^");
for(x in popVals){
//Split each pair and populate the correct field
var popVal = popVals[x].split("IS");
if(popVal.length == 2){
eval('current.' + popVal[0] + '="' + popVal[1] + '";');
}
}

If you’ve done everything correctly you should be able to order a catalog item, view and populate your new fields on the checkout form, and see those fields populated on the Request record as shown here…

Validating checkout fields / Making checkout fields mandatory

One last step that you may need to take is to make sure that certain checkout fields are filled out or validated before submission. I’ve written about how to do this in a separate article found here.

The post Adding Fields to the Service Catalog Checkout Screen appeared first on ServiceNow Guru.

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.

1Navigate to the ‘Navigation Handlers’ table by using the following URL (‘https://your-instance-name/sys_navigator_list.do’) or by typing ‘sys_navigator.list’ in the left navigation search bar.

2Open the ‘sc_request’ record and change the ‘Table’ field value to ‘–None–‘. This effectively disables the navigation handler that overrides the ‘ess’ view for the ‘sc_request’ table.

Next, you need to force the standard ‘ess’ view when a user sees the request record immediately after submitting a request.

3Open the ‘com.glideapp.servicecatalog_checkout_view’ (‘com_glideapp.servicecatalog_checkout_view_v2’ for newer instances) UI page under ‘System UI -> UI pages’ and change the name to ‘com.glideapp.servicecatalog_checkout_view-OLD’ (‘com_glideapp.servicecatalog_checkout_view_v2-OLD’ for newer instances)

4Create a new UI page with the following settings…

<!--?xml version='1.0' encoding='utf-8' ?-->


var item_id = '${sysparm_sys_id}';
var item_table = 'sc_request';var sc_req_item = new GlideRecordSecure('sc_req_item');
sc_req_item.addQuery('request', '${sysparm_sys_id}');
sc_req_item.query();
if(sc_req_item.getRowCount() == 1){
sc_req_item.next();
item_table = 'sc_req_item';
item_id = sc_req_item.sys_id;
}

<script language='javascript'>
        addLoadEvent(overrideView);
        function overrideView() {    
            var url = '$[item_table]' + '.do?sys_id=' + '$[item_id]' + '$[AMP]sysparm_view=ess';
            window.location = url;
        }  
    </script>

5Verify the security for all of the elements and related lists on the new form. Since this view is not designed for use by ‘ess’ users out-of-box, you’ll need to make sure that the security on the request and request item tables meets the needs of your organization.

Overriding the Request Item (sc_req_item) ess viewThe default behavior for users with no role is to force the ‘ess’ view for the Request Item table. If you find it necessary to override the ess view for the Request Item table you can modify or disable the ‘Catalog Scripts’ AJAX Script record. You can find this record by navigating to ‘System Definition -> AJAX Scripts’ if that module is active in your instance or you can enter ‘sys_script_ajax.list’ in your left navigation filter to navigate directly to the list without a module.

The post Overriding the ess Checkout View for Catalog Requests appeared first on ServiceNow Guru.