“We must accept responsibility for a problem before we can solve it. We cannot solve a problem by saying ‘It’s not my problem.’ We cannot solve a problem by hoping that someone else will solve it for us. I can solve a problem only when I say ‘This is my problem and it’s up to me to solve it.'”
— M. Scott Peck
Last time, we completed the required modifications to the Configurable Data Table Widget Content Selector and started to tackle changes to the Content Selector Configuration Editor. Now we need to create a new Service Portal widget to handle the editing of new and existing aggregate column specifications. To begin, I cloned the existing Button/Icon Editor widget, and then dug into the HTML to see what it was that we had to work with.
<div>
<form name="form1">
<snh-form-field
snh-model="c.widget.options.shared.label"
snh-name="label"
snh-required="true"/>
<snh-form-field
snh-model="c.widget.options.shared.name"
snh-name="the_name"
snh-label="Name"
snh-required="true"/>
<snh-form-field
snh-model="c.widget.options.shared.heading"
snh-name="heading"/>
<snh-form-field
snh-model="c.widget.options.shared.icon"
snh-name="icon"
snh-type="icon"/>
<snh-form-field
snh-model="c.widget.options.shared.color"
snh-name="color"
snh-type="select"
snh-choices='[{"label":"default","value":"default"},{"label":"primary","value":"primary"},{"label":"secondary","value":"secondary"},{"label":"success","value":"success"},{"label":"danger","value":"danger"},{"label":"warning","value":"warning"},{"label":"info","value":"info"},{"label":"light","value":"light"},{"label":"dark","value":"dark"},{"label":"muted","value":"muted"},{"label":"white","value":"white"}]'/>
<snh-form-field
snh-model="c.widget.options.shared.hint"
snh-name="hint"/>
<snh-form-field
snh-type="reference"
snh-model="c.widget.options.shared.page_id"
snh-name="page_id"
placeholder="Choose a Portal Page"
table="'sp_page'"
display-field="'title'"
display-fields="'id'"
value-field="'id'"
search-fields="'id,title'"/>
<div id="element.example" class="form-group">
<div id="label.example" class="snh-label" nowrap="true">
<label for="example" class="col-xs-12 col-md-4 col-lg-6 control-label">
<span id="status.example"></span>
<span class="text-primary" title="Example" data-original-title="Example">Example</span>
</label>
</div>
<span class="input-group">
<a ng-if="!c.widget.options.shared.icon" href="javascript:void(0)" role="button" class="btn-ref btn btn-{{c.widget.options.shared.color || 'default'}}" title="{{c.widget.options.shared.hint}}" data-original-title="{{c.widget.options.shared.hint}}">{{c.widget.options.shared.label}}</a>
<a ng-if="c.widget.options.shared.icon" href="javascript:void(0)" role="button" class="btn-ref btn btn-{{c.widget.options.shared.color || 'default'}}" title="{{c.widget.options.shared.hint}}" data-original-title="{{c.widget.options.shared.hint}}">
<span class="icon icon-{{c.widget.options.shared.icon}}" aria-hidden="true"></span>
<span class="sr-only">{{c.widget.options.shared.hint}}</span>
</a>
</span>
</div>
</form>
<div style="width: 100%; padding: 5px 50px; text-align: right;">
<button ng-click="cancel()" class="btn btn-default ng-binding ng-scope" role="button" title="Click here to cancel this edit">Cancel</button>
<button ng-click="save()" class="btn btn-primary ng-binding ng-scope" role="button" title="Click here to save your changes">Save</button>
</div>
</div>
Basically, it is just a DIV full of SNH Form Fields for all of the properties of a Button/Icon configuration. Since many of the properties of an Aggregate Column specification are the same as those of a Button/Icon configuration, we only need to make the changes for those that are different. Here is what I came up with for my initial version:
<div>
<form name="form1">
<snh-form-field
snh-model="c.widget.options.shared.label"
snh-name="label"
snh-required="true"/>
<snh-form-field
snh-model="c.widget.options.shared.name"
snh-name="the_name"
snh-label="Name"
snh-required="true"/>
<snh-form-field
snh-model="c.widget.options.shared.heading"
snh-name="heading"/>
<snh-form-field
snh-model="c.widget.options.shared.table"
snh-name="table"
snh-required="true"/>
<snh-form-field
snh-model="c.widget.options.shared.field"
snh-name="field"
snh-required="true"/>
<snh-form-field
snh-model="c.widget.options.shared.filter"
snh-name="filter"/>
<snh-form-field
snh-model="c.widget.options.shared.source"
snh-name="source"/>
</form>
<div style="width: 100%; padding: 5px 50px; text-align: right;">
<button ng-click="cancel()" class="btn btn-default ng-binding ng-scope" role="button" title="Click here to cancel this edit">Cancel</button>
<button ng-click="save()" class="btn btn-primary ng-binding ng-scope" role="button" title="Click here to save your changes">Save</button>
</div>
</div>
In looking through the rest of the code in the widget, it does not appear that there are any other changes necessary to make this work, so the next thing to do would be to fire up the modified Content Selector Configuration Editor and see how things look.
We can make sure that it actually works by adding an ‘x’ to each value on the form and clicking on the Save button. That should update the values displayed on the main screen.
The reason that all seems to work, even though the only changes that we made were to the HTML, is that the main widget and the pop-up editor widget share a common object called, appropriately enough, shared. Clicking on the Save button simply blows away the pop-up widget and returns control to the parent widget, where the values entered on the pop-up form are still available in the shared object, even though the pop-up widget is now gone. The new editAggregate function in the parent widget that we copied from the existing editButton function creates and populates this shared object, and then when the pop-up widget closes, uses the values in the shared object to update the edited row.
$scope.editAggregate = function(aggregate, aggArray) {
var shared = {};
if (aggregate != 'new') {
shared.label = aggregate.label;
shared.name = aggregate.name;
shared.heading = aggregate.heading;
shared.table = aggregate.table;
shared.field = aggregate.field;
shared.filter = aggregate.filter;
shared.source = aggregate.source;
}
spModal.open({
title: 'Aggregate Column Editor',
widget: 'aggregate-column-editor',
shared: shared
}).then(function() {
if (aggregate == 'new') {
aggregate = {};
aggArray.push(aggregate);
}
aggregate.label = shared.label || '';
aggregate.name = shared.name || '';
aggregate.heading = shared.heading || '';
aggregate.table = shared.table || '';
aggregate.field = shared.field || '';
aggregate.filter = shared.filter || '';
aggregate.source = shared.source || '';
});
};
At this point, this would all be good enough to get the job done, but for the table and field properties, it would be nice to have a pick list of tables and a pick list of reference fields present on that table rather than just open entry fields. We should be able to do that with a couple of sn-record-pickers, so I could fire up our old friend, the sn-record-picker Helper and configure them, but we can do even better than that. The sn-record-picker Helper is actually built with a bunch of of sn-record-pickers, and it already contains one for a list of tables and several for lists of fields dependent on the table selected. We should be able to just steal most of that in its entirety to get what we want. Here is the SNH Form Field for the table picker:
<snh-form-field
snh-model="c.data.table"
snh-name="table"
snh-type="reference"
snh-help="Select the ServiceNow database table that will contain the options from which the user will select their choice or choices."
snh-change="buildFieldFilter();"
snh-required="true"
placeholder="Choose a Table"
table="'sys_db_object'"
display-field="'label'"
display-fields="'name'"
value-field="'name'"
search-fields="'name,label'">
</snh-form-field>
With just a few simple modifications, we can adapt this to our needs:
<snh-form-field
snh-model="c.widget.options.shared.table"
snh-name="table"
snh-type="reference"
snh-change="buildFieldFilter();"
snh-required="true"
placeholder="Choose a Table"
table="'sys_db_object'"
display-field="'label'"
display-fields="'name'"
value-field="'name'"
search-fields="'name,label'"/>
All I did here was to change the model to our model, drop the help (it would be helpful, but would make the pop-form way too long if all of the fields included help text), and dropped the closing tag in favor of a closing / at the end of the main tag. Easy peasy. Of course, we have now referenced a buildFieldFilter() function that doesn’t exist, but again, we should be able to just steal that from the sn-record-picker Helper widget. Here it is:
$scope.buildFieldFilter = function() {
c.data.ready = false;
c.data.fieldFilter = 'elementISNOTEMPTY^name=' + c.data.table.value;
};
We don’t need the c.data.ready indicator for our use case, so we can just snag the whole thing, delete that line, and update the table variable name to match the one that we are using in our widget. Again, pretty simple stuff.
Now we just need to do the same for the field picker. There are several of these in the sn-record-picker Helper widget, but a few them allow multiple selections, so we will want to pick one that is just a single select, such as the Primary Display Field.
<snh-form-field
snh-model="c.data.displayField"
snh-name="displayField"
snh-label="Primary Display Field"
snh-type="reference"
snh-help="Select the primary display field."
snh-required="true"
snh-change="c.data.ready=false"
placeholder="Choose a Field"
table="'sys_dictionary'"
display-field="'column_label'"
display-fields="'element'"
value-field="'element'"
search-fields="'column_label,element'"
default-query="c.data.fieldFilter">
</snh-form-field>
Here is my adaptation of that tag for our widget.
<snh-form-field
snh-model="c.widget.options.shared.field"
snh-name="field"
snh-type="reference"
snh-required="true"
placeholder="Choose a Field"
table="'sys_dictionary'"
display-field="'column_label'"
display-fields="'element,reference'"
value-field="'element'"
search-fields="'column_label,element'"
default-query="c.data.fieldFilter"/>
That should take care of that. Let’s have a look and see what we have done.
Well, that is really disturbing. Everything is working as intended as far as the relationship between the pickers is concerned, but when I went to select assigned_to from the drop-down, it was not on the list. It appears as if the fields on the list are limited to just those fields on the primary table, and the list does not include any of the fields for any of the tables from which that primary table may have been extended. This is particularly distressing news, as that means that the sn-record-picker Helper widget, from which we lifted this code, has had this issue all along. Not good! We are going to need to stop and fix that right away, and then we can revisit this guy next time out.
