“Everything can be improved.”
— Clarence W. Barron
Last time, I promised that we would get into providing aggregate column support to the remaining data table wrapper widgets and the Content Selector Configuration Editor, but before we do that, there is one little extra feature that I would like insert. As you may recall, when I set up the filter for the initial test page, I hard-coded the list of sys_ids for the members of the Hardware group. It would have been much easier to use the sys_user_grmember table and set the filter to group.name=Hardware, but the problem with that would be that the sys_id of the row would then be the sys_id of the sys_user_grmember record, and not the sys_id of the sys_user record. The reason that that is a problem is because there are no Incidents assigned to sys_user_grmember records, so the aggregate column values would all be 0.
There is, however, a way to make that work. We just need to add one more property to our aggregate column configuration object. If we add an optional source property, then we can allow developers to configure an alternate source for the sys_id rather than just relying on the sys_id of the primary record of the row. It could be optional, as we could always default to the sys_id of the row if you did not specify an alternate source, but if you did enter a value, then the contents of that field would be the sys_id that we would use in place of the standard behavior. Using that approach, we could develop a configuration that could look like this:
name: 'sys_user_grmember',
displayName: 'User',
all: {
filter: 'group.name=Hardware',
fields: 'group,user,user.title,user.email,user.department,user.location',
aggarray: [{
label: 'Incidents',
name: 'incidents',
heading: 'Incidents',
table: 'incident',
field: 'assigned_to',
filter: 'active=true',
source: 'user'
}],
btnarray: [],
refmap: {},
actarray: []
}
Of course, in order to do that, we would have to add some additional logic inside the for loop that puts together the data to be sent to the getAggregateValue function, but the changes should not be that significant. I simply created a new variable called sysId, set it initially to the sys_id of the record, then checked to see if there was a source defined, and if so, overrode the initial value with the value found in the source field of the current record.
for (var j=0; j<data.aggarray.length; j++) {
var config = data.aggarray[j];
var sysId = record.sys_id;
if (config.source) {
sysId = gr.getValue(config.source);
}
record.aggValue.push(getAggregateValue(sysId, config));
}
That’s all there is to that. Now we just need to put together a test case to see if it will actually work. Rather than muck up my original test page, I decided to clone the page and the configuration script so that I could run tests both with and without a source defined. I called my copy of the configuration script AggregateTestConfig2, and it turned out like this:
var AggregateTestConfig2 = Class.create();
AggregateTestConfig2.prototype = Object.extendsObject(ContentSelectorConfig, {
initialize: function() {
},
perspective: [{
name: 'all',
label: 'All',
roles: ''
}],
state: [{
name: 'all',
label: 'All',
}],
table: {
all: [{
name: 'sys_user_grmember',
displayName: 'User',
all: {
filter: 'group.name=Hardware',
fields: 'group,user,user.title,user.email,user.department,user.location',
aggarray: [{
label: 'Incidents',
name: 'incidents',
heading: 'Incidents',
table: 'incident',
field: 'assigned_to',
filter: 'active=true',
source: 'user'
}],
btnarray: [],
refmap: {},
actarray: []
}
}]
},
type: 'AggregateTestConfig2'
});
Now all we have to do is pull up the new test page and see how it looks.
So now you can define an alternate source for the sys_id that drives the aggregate, or you can choose not to and have the original functionality remain intact. Sweet! I like it. We still don’t have a way to click on the aggregate and pull up a list of the records represented there, but that’s something that we can always add in a future version. For now, we still have work to do involving the remainder of the core data table widget wrappers and the configuration file editor. I know that I said this last time, but this time for sure, we will jump right into that next time out.
