“When to use iterative development? You should use iterative development only on projects that you want to succeed.”
— Martin Fowler
I probably could have wrapped all of this up last time, but I had not really given a whole lot of thought to a couple of critical decisions related to the last two items that needed to be coded out, the Save button and the Cancel button. For the Cancel button, the main question is where are you going to land once you leave the page. For the Save button, which is the bigger question, I need to figure out where I am going to store the information now that I have collected it on the screen. Since that’s a more complicated deliberation, let’s focus on the Cancel button first.
One thing that I wanted to do with the Cancel button was to pop up a confirmation that you really did want to bail, but only if you had made any changes that you would be losing by leaving the page. I wasn’t keeping track of whether or not you had made any changes, though, so I needed to fix that first. I created a variable called dataAltered and initialized it to false, and then I set it to true if you added or removed a row or selected an icon. With that in place, I built the function to handle the Cancel button clicks.
$scope.cancel = function() {
if (dataAltered) {
spModal.confirm('Discard your recent changes?').then(function(confirmed) {
if (confirmed) {
goBack();
}
});
} else {
goBack();
}
};
Those of you paying close attention will notice that I still did not address the question of where to go after clicking the Cancel button; I just called a nonexistent function called goBack. That’s basically my way of putting things off until some future time when I am forced to deal with it, and usually I will create the function with a single line of code that pops an alert or write a log record to the let me know that I’ve made it that far. That let’s me test what I have done without having to deal with what I haven’t done. In this particular case, though, that was a short delay, because now it’s time to put real code in the goBack function, which means that it’s time to decide where people are going to land when they hit the Cancel button.
One of my first thoughts was that if this widget was sharing a screen with my Dynamic Service Portal Breadcrumbs widget, I could just go back one step in the chain to the previous screen. In order for that to work, I would need to know if I was sharing the page with that widget, which is not really possible at the moment. Ideally, that widget should announce its presence with some kind rootScope broadcast message that says something like, “Hey, I am here, and oh by the way, here is the URL for the previous page if you want to go back to it.” That actually sounds like a good idea, but it also sounds like a project for another day. I was planning on adding this widget to my existing Tools menu in the main UI, so I didn’t really see a lot of value in investing a lot of effort right now on getting it to work on the portal with breadcrumbs.
Ultimately, I decided to just go to the home page of the main UI, unless of course, we really were running in the portal, and in that case, I would just return to the home page of the portal. Since the main UI pages run inside of an iFrame, it seemed relatively simple enough to detect the difference by looking at the parent window. The final code turned out to be just this:
function goBack() {
var destination = '?';
if (window.parent.location.href != window.location.href) {
destination = '/home.do';
}
window.location.href = destination;
}
That takes care of the easy part. Now it is finally time to make a decision on where to store this information. The simplest thing to do seemed to be to just add another column to the sys_db_object table for the name of the icon. That ‘s a fairly foundational table to the whole ServiceNow platform, though, and I really do not like to mess with those if I can avoid it. A preferable alternative would be to create a simple m2m table that had a column for the CI class and another column for the icon name. That’s much better, but there is still a certain amount of work involved in creating the table, saving the data to the table, and then reading the data back in from the table whenever you wanted to use it. What I finally decided to do was to just keep the icon map hard-coded in my Script Include, and then just update the script column of the Script Include whenever the Save button is clicked. Look, Ma — no tables!
My plan was to grab the script, substring off the parts of the script before and after the property list, rebuild the property list from the data on the screen, and then rebuild the script from the before and after pieces and the new property list. There is probably some regex wizardry that would do all of that with a single line of code, but most of that is all voodoo magic as far as I can tell, and I like to build things that can be comprehended by a little bit larger audience. In the end, my approach seemed to have an awful lot of code and variables involved, but it does work, so there you go.
function save() {
var scriptGR = new GlideRecord('sys_script_include');
if (scriptGR.get('7b6ebf052f8e18104425fcecf699b6f6')) {
var original = scriptGR.getValue('script');
var i = original.indexOf('map: {');
if (i != -1) {
var preamble = original.substring(0, i);
var theRest = original.substring(i);
i = theRest.indexOf('\n\t},');
if (i != -1) {
var postamble = theRest.substring(i);
var separator = '';
var newScript = preamble + 'map: {';
for (i=0; i<data.itemArray.length; i++) {
newScript += separator + '\n\t\t' + data.itemArray[i].id + ": '" + data.itemArray[i].icon + "'";
separator = ',';
}
newScript += postamble;
scriptGR.setValue('script', newScript);
scriptGR.update();
gs.addInfoMessage('The Configuration Item icon assignments have been saved');
} else {
gs.addErrorMessage('The Script Include to update has been corrupted.');
}
} else {
gs.addErrorMessage('The Script Include to update has been corrupted.');
}
} else {
gs.addErrorMessage('The Script Include to update was not found.');
}
}
That’s a server side script, by the way, so we still need a client side script to send things over to the server. That one is pretty simple, though, and looks like this:
$scope.save = function() {
c.data.action = 'save';
c.server.update();
};
In fact, the whole client side script, including the code that we just added to detect changes and handle the two buttons now looks like this in its final form:
function CIIconAssignment($scope, spModal) {
var c = this;
var dataAltered = false;
$scope.addSelected = function() {
c.server.update();
$('#snrp').select2("val","");
dataAltered = true;
};
$scope.removeItem = function(inx) {
spModal.confirm('Remove ' + c.data.itemArray[inx].id + ' from the list?').then(function(confirmed) {
if (confirmed) {
c.data.itemArray.splice(inx, 1);
dataAltered = true;
}
});
};
$scope.selectIcon = function(inx) {
spModal.open({
title: 'Select Icon',
widget: 'icon-picker',
buttons: [
{label: '${Cancel}', cancel: true}
],
size: 'sm',
}).then(function(response) {
c.data.itemArray[inx].icon = response.selected;
dataAltered = true;
});
};
$scope.save = function() {
c.data.action = 'save';
c.server.update();
};
$scope.cancel = function() {
if (dataAltered) {
spModal.confirm('Discard your recent changes?').then(function(confirmed) {
if (confirmed) {
goBack();
}
});
} else {
goBack();
}
};
function goBack() {
var destination = '?';
if (window.parent.location.href != window.location.href) {
destination = '/home.do';
}
window.location.href = destination;
}
}
The last thing that I did was grab one of the existing sidebar menu options under my Tools section and use it as model for a new menu option to launch this page. After that, I used the new option to bring up the page and test everything out. Everything seems to work, and it came out looking pretty good, all things considered.
One thing that I did realize during my testing is that there is nothing to stop you from deleting the root cmdb_ci entry, which serves as my default. I don’t really want you doing that, so I added an ng-hide to the delete icon that will remove that option when the item.id is cmdb_ci. You can see in the image above that there is no delete option for that row. That’s much better.
After playing around and testing, I ended up saving my Script Include several times over. Right now, it looks like this:
var ConfigurationItemIconMap = Class.create();
ConfigurationItemIconMap.prototype = {
initialize: function() {
},
getIcon: function(ciClass) {
var icon = this.map[ciClass];
if (!icon) {
ciClass = this.getParentClass(ciClass);
if (ciClass) {
icon = this.getIcon(ciClass);
}
}
return icon;
},
getParentClass: function(ciClass) {
var parentClass = '';
var tableGR = new GlideRecord('sys_db_object');
if (tableGR.get('name', ciClass)) {
parentClass = tableGR.super_class.name;
}
return parentClass;
},
map: {
cmdb_ci: 'configuration',
cmdb_ci_aix_server: 'connect-viewdocument',
cmdb_ci_computer: 'hardware',
cmdb_ci_config_file: 'document',
cmdb_ci_database: 'database',
cmdb_ci_hardware: 'keyboard',
cmdb_ci_linux_server: 'sp-wishlist-sm',
cmdb_ci_server: 'server',
cmdb_ci_spkg: 'software',
cmdb_ci_unix_server: 'text-underlined',
cmdb_ci_win_server: 'vtb-freeform'
},
type: 'ConfigurationItemIconMap'
};
Of course, that will change the next time that I use the tool, but I like the fact that I did not end up creating any extra columns or tables to pull this off. For those of you who like to play along at home, here is an Update Set containing all of the parts and pieces.
