Tables and Buttons

Alexander Ander · ‎12-07-2021

The Problem

I found myself coming back to making some form of a table with buttons to act on the data quite often and tended to end up throwing together a table widget to handle that specific case and had meant to create a more reusable table to which I could tie data.

The issue that usually came up was applying logic to the data that was present and offering some sort of selection of symbols or buttons (usually both) to the rendered table, making use of the out-of-the-box table widget either out of the question or much more difficult.

In a recent whirl of development, I finally made an abstracted table that could take data from a client callable script include, so as to allow development of a custom data source without requiring modification of the widget's server-side script. In making it, I planned to make it a bit more general and worked out some basic guide rails for working with a REST API or leveraging the usual server-side script.

Quick Overview

The goal was to be able to create a script that assembled some data and then have a table that was easily configured for semi-robust data display while offering configurable buttons to act on the rows. This widget handles this with 2 instance configurations for JSON strings, one to define the columns and one to define actions:

The widget then uses these to loop over the generic objects provided by the client script and render a table, rows, and give the user some basic abilities to flip through pages and filter the data:

The widget has quite a few instance options aimed at providing a fair amount of control as well as an option to simply deactivate it for when something quickly needs hidden with the intention of bringing it back at some point with ease.

Sharing

I've attached the update set for the widget below as well as placing it on the Developer Share site and GitHub for anyone to check out, use, and leave feedback or requests. The Widget satisfies our current needs but definitely has room to grow (Row selection likely being the next feature to get added):

Developer Share: https://developer.servicenow.com/connect.do#!/share/contents/5258606_action_table

GitHub: https://github.com/alexanderson-sedgwick/action-table

Documentation: https://alexanderson-sedgwick.github.io/action-table/

Dennis Braun · ‎02-16-2024

Hi Alexander,
first of all, thank you for providing this really great configurable table widget.

However, I have noticed that the ACLs of the configured table unfortunately do not take effect or are ignored
- and filtering the table only by query is too unsafe for me.

There is a "Read ACL" on the linked table with a condition that basically only matches on 2 hits.

In the rendered widget table, however, all entries are displayed unless the query is explicitly selected.

Is it possible to change the behavior so that only the entries that should be there per ACL are displayed?

Many thanks in advance
Dennis

Alexander Ander · ‎02-16-2024

The quickest way would be to modify the "getTableData" method in the "ActionTableScriptAPI" script include. You'd be looking for the "ActionTableScriptAPI.prototype.getTableData" (~line 122) and then change the next line from:

var search = new GlideRecord(table),

to

var search = new GlideRecordSecure(table),

This is also something I should have put in place in the first place, but basic table reference wasn't a current use case, so that got missed. I'd recommend putting the change in but the next update will include this change.

Dennis Braun · ‎02-28-2024

Hello Alex,

Thank you very much for your feedback.
The customization of the ACL with GlideRecordSecure works great.

Now we would like to create a filter option by using the query.

To do this, I have created a second widget in which the data is transferred to the table widget via broadcast.

Client Script:

$rootScope.$on('navQuery', function (event, obj) {
        $scope.data.query = obj;
        $scope.server.update();
        $scope.reloadData();
    });

Server Script:

if (input.query) {
        options.query = input.query;
    }

The query also arrives in the table widget, but the view is not updated.

Do you have any idea what needs to be adjusted so that the view is retriggered?

Many thanks in advance
Dennis

Dennis Braun · ‎03-05-2024

Update:

The script is now working.

I did not consider that an async update must be performed:

$rootScope.$on('navQuery', function (event, obj) {
		$scope.data.query = obj;
			
		$scope.server.update().then(function(response){
		$scope.loadCorpus();
		});		
	});

Alexander Ander · ‎03-05-2024

I'm not sure there's a good "automatic" way to handle when the async load would need to fire, but I'm glad you found that, I had been pretty occupied the last few days. But I will add some notes/documentation to hopefully help anyone in the future.