“A person who never made a mistake never tried anything new.” — Albert Einstein
Well, it turns out it didn’t take all that long to figure out why I was losing the buttons and icons on my customized Data Table widget whenever I sorted the data. It was definitely my fault, which was easily predictable based on the The First Rule of Programming. I actually had one of those this is not right feelings at the time that I did it, but I ignored that and did it, anyway. When I was parsing the JSON string for the button configuration to obtain the actual JSON array of button specs, I reused the same variable to hold the array as the original variable that held the string. Here is the offending code:
if (data.buttons) {
try {
var buttoninfo = JSON.parse(data.buttons);
if (Array.isArray(buttoninfo)) {
data.buttons= buttoninfo;
} else if (typeof buttoninfo == 'object') {
data.buttons = [];
data.buttons[0] = buttoninfo;
} else {
gs.error('Invalid buttons option in SNH Data Table widget: ' + data.buttons);
data.buttons= [];
}
} catch (e) {
gs.error('Unparsable buttons option in SNH Data Table widget: ' + data.buttons);
data.buttons = [];
}
} else {
data.buttons = [];
}
The problem with doing that, which is just a bad practice in general and I’ve been around long enough to know better, is that we pass through this same code again and again whenever the table is sorted. Reusing the same variable means that when you come through this logic the next time around, things are not the same as they were the first time through. That’s not good. I tried several failed attempts at detecting and avoiding the problem, but I finally broke down and just created a new variable to hold the button spec array and left the original JSON string intact. That solved the problem. Here is what it looks like now:
if (data.buttons) {
try {
var buttoninfo = JSON.parse(data.buttons);
if (Array.isArray(buttoninfo)) {
data.btnarray = buttoninfo;
} else if (typeof buttoninfo == 'object') {
data.btnarray = [];
data.btnarray[0] = buttoninfo;
} else {
gs.error('Invalid buttons option in SNH Data Table widget: ' + data.buttons);
data.btnarray = [];
}
} catch (e) {
gs.error('Unparsable buttons option in SNH Data Table widget: ' + data.buttons);
data.btnarray = [];
}
} else {
data.btnarray = [];
}
Of course, once I changed the name of the variable, then I had to hunt down and modify every reference to that variable, which was a task in itself. But I’ve done the work now, and retested everything, so here’s another Update Set with the corrected code. Lesson learned (yeah, right!).
“Quality is not an act; it is a habit.” — Aristotle
In order to test my Data Table buttons and icons, I’m going to need a way to trigger both options, navigating to a new page and processing the global broadcast. Since my initial test page was configured to use the sys_user table, bouncing over to the User Profile page seems like easiest thing to do to demonstrate the first. But, to demonstrate the second, I’m going to have to create another widget, one that I will build just to prove that the other option works as well. Before we do that, though, let’s set up the button configuration JSON object to create one button and one icon, and have one implement the first option and the other implement the second. That will set things up for our testing.
[
{
"name":"button",
"label":"Button",
"heading":"Button",
"color":"primary",
"page_id":"user_profile",
"hint":"Clicking this button should take you to the User Profile page"
},{
"name":"icon",
"label":"Icon",
"heading":"Icon",
"icon":"user",
"hint":"Clicking this icon should open a modal pop-up"
}
]
We can enter that configuration using the Page Designer and clicking on the Edit icon (pencil) to bring up the options screen:
Entering the button configuration in the widget options panel
With that configured, we can actually test the button right away, as that one is configured to branch to another page (user_profile). We can’t test the icon, though, until we build a widget to listen for the broadcast.
So, I went over to the Service Portal Widgets list and clicked on the New button to create a net new widget to listen for the broadcast message. The only things this widget will do is listen and take action, so I didn’t need a Body HTML template and I didn’t need a Server script, so I just left those blank. For the Client controller, I just entered this:
This was about a simple as I could think of and still test out the process. Unfortunately, when I tested it, it didn’t work. It turns out that the stock user-profile widget cannot accept a sys_id from input. Well, that’s easily enough fixed, but I had to clone the user-profile widget to add in the code, and then I had to have my new listener widget launch the cloned snh-user-profile widget instead of the original. Now, that worked.
Modal pop-up opened by example listener widget
The listener widget has no HTML body, so you can pretty much drag it anywhere on the page. Once it shares the page with the customized Data Table widget, it will be able to pick up the broadcast and do whatever it is that you want to do. My example just checks for a ‘button-click’ event, but if you have more than one button on your page, you may also what to check to see which button was clicked before you take any action. I’ll leave that to those of you who want to try all this out on your own.
One unfortunate bit of bad news, though: in the process of testing all of this out, I clicked on one of the column headings to sort the list and my buttons disappeared. That was deflating! That’s why we pull on all of the levers and twist all of the dials, though. It’s important to check everything out thoroughly. Still, I hate to be reminded that I don’t really know what I am doing. It will probably take me a while to dig around, find the source of the problem, and come up with a viable solution. Still, I did promise to publish an Update Set soon, so I think I am going to go ahead and do that, even though this version violates Rule #1. If you don’t mind playing around with something that is obviously broken, you can get the version 1.0 Update Sethere. Just be aware that there is a flaw that has yet to be corrected. Speaking of which, I better get busy diagnosing and correcting that problem.
“All life is an experiment. The more experiments you make, the better.” — Ralph Waldo Emerson
Now that we’ve tweaked the Data Table widget to support reference links and action buttons and icons, it’s time to add the code that will process the clicks on the buttons and icons. There are a number of things that we could do here, but since I like to start out small and build things up over time, today I think I will just handle a couple of the options: 1) navigating to another page, and 2) broadcasting the click and letting some other widget or function take it from there. The first is basically just a copy of what is already being done for the primary row link and the reference links and the second is just the weasel way out of building other options into the Data Table widget itself. By broadcasting the details of the click, users can pretty much do whatever it is that they would like to do by setting up listeners for the broadcast, and then I won’t have to add any additional logic or options on my end.
But before we get into all of that, I do have to admit that I got a little sidetracked the other day and started to tinker. Since I had already opened up the code and was messing with it anyway, I decided to go ahead and see if I could add a user avatar to any reference to the sys_user table. I had to dig around a little bit to see how that was done, but it is actually pretty simple with the sn-avatar tag.
Custom Data Table with User Avatars and Presence
I had to play around with the classes for various things to get everything to come out visually the way that I wanted, but the end result turned out to be a relatively simple addition to the HTML:
Now, back to our regularly scheduled programming …
In the main Data Table widget’s Client Controller, I virtually copied the existing go function and then just added in a quick loop to hunt through the configured buttons to find the one that was clicked so that we could pass it on. Other than that, it’s virtually the same as the original:
$scope.buttonclick = function(button, item) {
spNavStateManager.onRecordChange(c.data.table).then(function() {
var parms = {};
parms.table = c.data.table;
parms.sys_id = item.sys_id;
parms.record = item;
for (var b in c.data.buttons) {
if (c.data.buttons[b].name == button) {
parms.button = c.data.buttons[b];
}
}
$scope.ignoreLocationChange = true;
for (var x in c.data.list) {
c.data.list[x].selected = false;
}
item.selected = true;
$scope.$emit(eventNames.buttonClick, parms);
}, function() {
// do nothing in case of closing the modal by clicking on x
});
};
Then, on the wrapper widgets, I copied the original listener and hacked it up to look into the button spec to see if there was a page configured. If so, then I navigate to the page; otherwise, I simply broadcast the click on the root scope so that another, independent widget can pick things up from there:
$scope.$on('data_table.buttonClick', callButtonClick);
function callButtonClick(e, parms) {
if (parms.button.page_id) {
var oid = $location.search().id;
var p = parms.button.page_id;
var s = {id: p, table: parms.table, sys_id: parms.sys_id, view: $scope.data.view};
var newURL = $location.search(s);
spAriaFocusManager.navigateToLink(newURL.url());
} else {
$rootScope.$broadcast('button.click', parms);
}
}
That was all there was to it. Now all that’s left is to write a sample independent widget to listen for the broadcast and test all of this out to make sure that it all works. That should wrap all of this up quite nicely and should turn out to be the final installment in this particular series.
“Many of life’s failures are people who did not realize how close they were to success when they gave up.” — Thomas Alva Edison
In addition to the reference links that I wanted to add to my version of the Data Table widget, I also wanted to add the capability to add buttons or icons to each row for specific actions. This seemed like something that could be accomplished relatively easily, and configured just like the many other options associated with the various flavors the Data Table. My thought was to be able to configure things to look something like this:
Data Table with example button and action icon
For the icons, my plan was to just leverage the Retina Icons that I had stumbled across the other day, and then lift the associated HTML right out of the old snh-form-field tag. But first, I had to come up with a way to pass in all of the information needed to configure each button. There is a way to use a table as a source for complex widget options, but this was just an experiment at this point, so I decided to go the quick and easy way and just pass in a JSON array of button specification objects that would look something like this:
[
{
"name": "button",
"label": "Button",
"heading": "Button",
"color": "primary",
"hint": "Click this button to do something",
"action": "doSomething"
},{
... etc ...
}
]
I haven’t worked out all of the details yet, but you get the idea. That’s the basic concept, anyway … all we have to do now is to code it up!
The first order of business is to create the new widget option to hold the button specifications. One quick way to do that is to just edit the Option Schema directly, as it just happens to be a JSON object itself. In fact, there is already one option defined (enable_filter), so it is a simple matter to just use that one as an example and create a second one for our purposes:
[
{
"hint":"If enabled, show the list filter in the breadcrumbs of the data table",
"name":"enable_filter",
"default_value":"false",
"section":"Behavior",
"label":"Enable Filter",
"type":"boolean"
},{
"hint":"A JSON object containing the specification for row-level buttons and action icons",
"name":"buttons",
"default_value":"",
"section":"Behavior",
"label":"Buttons",
"type":"String"
}
]
Once we have updated the Option Schema, editing an instance of the widget will include a place to enter the specifications for any desired buttons. Now we have to add code to the widget’s Server Script to pull in the value of the new option and turn it from a String to an Object. Since there is no guarantee that the instance author will provide a parsable JSON object, we will have to put in a little defensive code to check for a few possibilities.
if (data.buttons) {
try {
var buttoninfo = JSON.parse(data.buttons);
if (Array.isArray(buttoninfo)) {
data.buttons = buttoninfo;
} else if (typeof buttoninfo == 'object') {
data.buttons = [];
data.buttons[0] = buttoninfo;
} else {
gs.error('Invalid buttons option in SNH Data Table widget: ' + data.buttons);
data.buttons = [];
}
} catch (e) {
gs.error('Unparsable buttons option in SNH Data Table widget: ' + data.buttons);
data.buttons = [];
}
} else {
data.buttons = [];
}
And finally, we have to alter the HTML to include any configured buttons or icons. Modifications will need to be made in two places, one for the column headings and the other for the data columns. Here is what we will add for the column headings:
That puts everything on the screen and clickable, but we still some code to perform whatever action each button is intended to perform. That’s a tad bit more complicated, so I think we’ll tackle that the next time out ….
“It always seems impossible until it’s done.” — Nelson Mandela
Today I am going continue on with my little Data Table widget customization by tackling the HTML portion of project, and then set things up so that we can do a little testing. Currently, the HTML that displays a single row in the data table does so in a way that the entire row is the clickable link to the details for that row. My intent is to change that so that the first column is the link to the details for that row, and then any other column that contains a reference field can be a link to the details of that specific reference. So, let’s take a look at the HTML structure that is there now:
I’m not quite sure what purpose is served by that first <TD> that doesn’t repeat, but there is a column heading to match, although neither appear to have any value or content. Maybe it’s a spot for a row-level checkbox or a glyph or something, but I’m not really smart enough to figure it out. The first thing that I did on my version was to delete it, along with the associated column heading — if I don’t understand why it needs to be there, then it just needs to go. Of course, that has nothing to do with what I am trying to accomplish, but if you happen to notice it gone in my version, that’s because I made it gone. I may end up having to go out and look for it one day when I finally figure out its value, but for now at least, it sleeps with the fishes.
With that out of the way, we can focus on the actual table columns, which are all treated the same in this version. The entire cell, not just the content, is the link to further information on the row, and with every column the same, no matter where you click on the row, the result is the same. We don’t want to do that in our version, though, so we can keep the ng-repeat on the <TD>, but the rest will be dependent on the column. Since we want the links to be on the content and not on the entire cell, we don’t really need anything else at the <TD> level anyway.
The first column will always be a link, and it will perform the same function as clicking anywhere on the row in the original version. For all other columns, they will also be links if the data type is reference, and there is a value. We can use the $first property to detect the first column, so the code for that link can basically be lifted from the original, with the addition of an ng-if to target the first column.
<a ng-if="$first" href="javascript:void(0)" ng-click="go(item.targetTable, item)" title="${Click for more on }{{::item[field].display_value}}">{{::item[field].display_value}}</a>
The remaining columns will require a few more lines. Not only do we need to determine that this not the first column, we also need to check to see of the type is reference, and if there is a value (if there is no value, then there is no need to code the link). Wrapping the whole thing in a <SPAN> will allow us to separate all of this from the first column, and then we can use an anchor tag for the links and a simple <SPAN> for the rest.
<span ng-if="!$first">
<a ng-if="item[field].value && item[field].type == 'reference'" href="javascript:void(0)" ng-click="go(item[field].table, item[field].record)" title="${Click for more on }{{::item[field].display_value}}">{{::item[field].display_value}}</a>
<span ng-if="!item[field].value || item[field].type != 'reference'">{{::item[field].display_value}}</span>
</span>
At this point, I am leveraging the existing go function to handle the clicks. That function takes a table and a record as an argument, so I figure that I can just pass in the name of the referenced table and a mocked-up record (more on that later) and simply reuse the existing function. I may want to rethink that later and create a function specifically for reference field clicks, but for now this works, so it’s good enough. My earlier server-side additions did not originally create mocked-up record for each reference field, so I had to go back and that in to bring all of this together. I added that to the same block of code where I was adding the name of related table.
Well, that should do it — at least, for this initial version. Now we just need to take it out for a spin and make sure that everything works. For that, we’ll need to create a test page and then put the widget on the page and configure it. Then we can hit the Try It! button.
First test of the customized Data Table widget
Well, that wasn’t too bad. Everything seems to work as I had intended. Nothing happens right now when you click on anything, but that’s because the go function simply broadcasts the click events, and I don’t have anything listening for that in this version. This was a clone of the core Data Table widget, and the listeners are in the wrapper widgets that implement the various ways to configure the display and contents. I’ll have to clone those wrapper widgets as well, or maybe modify them to choose between the stock Data Table widget and my customized version. Either one seems like a lot more work than I want to dive into right now, so I’m going to leave that for a later installment.
“The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.” — George Bernard Shaw
After spending some time playing around with my Data Table Widget Content Selector, I realized that there were a few things that I wanted out of the Data Table widget that just weren’t on its list of features. For one thing, the entire row was the source of the link to further details. In the standard ServiceNow UI, the first column on any given list is the link to further details on the subject of the the row, and links in other columns took you to details related to that specific column. On a list of Incidents, for example, clicking on the link on the first column will take you to the Incident, but clicking on a link in any other column, say Assignment Group or Location, will bring up information on the Assignment Group or Location. I wanted to have a Service Portal list that behaved in the same manner. I started rooting around in the code for the Data Table and realized that this would be more than a simple hack, so I decided to clone the widget and create my own SNH Data Table.
One thing that I discovered while playing around with my copy of the Data Table widget was that there was a minor bug in widget related to the fields option, which was the subject of my earlier hack of the Data Table from URL definition widget. Throughout the widget, this option is referenced as fields, but in the actual widget options, it is named field_list. The statement that copied fields from the options didn’t really copy anything, as the actual data was stored under the variable name field_list. So the first thing that I ended up doing with my copy was to change this:
if (!data.fields) {
if (data.view)
data.fields = $sp.getListColumns(data.table, data.view);
else
data.fields = $sp.getListColumns(data.table);
}
… to this:
if (!data.fields) {
if (data.field_list) {
data.fields = data.field_list;
} else if (data.view) {
data.fields = $sp.getListColumns(data.table, data.view);
} else {
data.fields = $sp.getListColumns(data.table);
}
}
That seemed to have rectified that little shortcoming, so now back to my intended purpose, which was to provide column-level links rather than the current row-level link. First things first: I needed to find out if we had enough information on hand to provide the links, or if we needed to add some code to gather up more details for columns that could contain a link. Unfortunately, the code the code that gathers up the row data doesn’t reveal much detail on what, exactly, is gathered up for each field in each row:
while (gr._next()) {
var record = {};
$sp.getRecordElements(record, gr, data.fields);
. . .
}
I would have to dig out the code for $sp.getRecordElements() to know what data was being pulled for each field, which sounded a lot like a major hunting expedition. Instead, I took the lazy way out (my favorite!), and just dumped out the result with a gs.info(JSON.Stringify(record)); statement right after the $sp.getRecordElements(). After that, all I had to do was to bring up a list using the widget and then dig through syslog.list. What I learned was that each field in the record object contained a type, a value, and a display_value, but not the name of the table for the reference fields, which I would need if I was going to create a link. So, I needed to add a little code to pick up that extra bit of info for each field where type=reference. There was actually some similar code right above where I needed to insert my own, so what I ended up adding turned out to be a bastardized copy of the preceeding logic:
for (var f in data.fields_array) {
var fld = data.fields_array[f];
if (gr.isValidField(fld)) {
if (record[fld].type == 'reference') {
record[fld].table = gr.getElement(fld).getED().getReference();
}
}
}
Basically, we just loop through all of the fields in the record, look for those where type=reference and then go fetch the reference table from the source GlideRecord. Now that we have everything that we need in the underlying data, the last thing that we need to do will be to alter the HTML to provide individual column links instead of a single link for the entire row. That seems like a good place to start, next time out …
