You are viewing content included in the Next Experience Center of Excellence
This article was created on the Tokyo release of the Next Experience framework and may not reflect current functionality. Please post any questions or comments to the article so that our team can help update it.
This article is going to build off the functionality that was created in another Next Experience COE article on Declarative Actions. See the section on UXF Client Actions for a walkthrough on creating an Add button. That article walked through showing records in a modal window, but did not cover how to filter the records that are shown. This article will pick up from the Add button created in that article. We're using extension points in the context of filtering records returned for the modal triggered by a declarative action. Extension points are used outside of this use case, for more information on extension points see the Using extension points to extend application functionality product documentation.
For this example we're going to filter out any CIs that have the Manufacturer of Gateway, which is a real throwback but apparently is still a PC manufacturer. Currently, we we click the Add button created previously, we can see Gateway CIs in the list. Note: Using demo data installed with an instance or PDI and there are 9 CIs that have the manufacturer of Gateway.
The Action Payload Definition (sys_declarative_action_payload_definition) created, COE_ADD_CI has a property in the Payload object for extensionPoint, and it was left as "DEFAULT" previously, meaning that it was not filtering out records. This is where we will plugin our extension point after we create it.
You can find extension points under System Extension Points > Scripted Extension Points. There is an out-of-the-box extension point named RelatedListItemCandidateFilter that is the default extension point for this functionality. This extension point is where the 'DEFAULT' value comes from in the reference above. In order to build off this extension point, click the Create implementation related list on this record.
To dissect this extension point, it is going to look for records that are already associated to the parent record, i.e. CIs already in the Affected CIs related list. It will by default filter those records out of the list, if there are not records present, then it just returns everything.
An encoded query was copied from the cmdb_ci table: manufacturer!=b7eafc3ec0a80169017bc0ac7b4fc209^manufacturerISNOTEMPTY, with the sys_id being the Gateway manufacturer. This example is using a hardcoded sys_id for simplicity sake, but the encoded query could be something like manufacturerNOT LIKEGateway. If you're using this query, notice that when you filter out on the manufacturer, the records with an empty manufacturer are also excluded, so while we don't need manufactuerISNOTEMPTY, it's included in this example for clarity.
Here's the script used in the extension point:
var RelatedListItemCandidateFilter = Class.create();
RelatedListItemCandidateFilter.prototype = {
getFilterQuery: function(tableName, parentFieldName, parentRecordSysId, referencedFieldName) {
var selectedRecord = new GlideRecord(tableName);
selectedRecord.addQuery(parentFieldName, parentRecordSysId);
selectedRecord.query();
var result = [];
while (selectedRecord.next()) {
result.push(selectedRecord.getValue(referencedFieldName));
}
if (result.length)
return "sys_idNOT IN" + result.join(",") + "^manufacturer!=b7eafc3ec0a80169017bc0ac7b4fc209^manufacturerISNOTEMPTY"; //Results are not already present in the related list and Manfacturer is not Gateway and is not empty.
return "manufacturer!=b7eafc3ec0a80169017bc0ac7b4fc209^manufacturerISNOTEMPTY"; //Manfacturer is not Gateway and is not empty.
},
handles: function(extensionPointKey){
return extensionPointKey == "GATEWAY_CMDB_CI_QUERY_FILTER";
},
type: 'RelatedListItemCandidateFilter'
};
Lastly, we'll add this extension point to our Declarative Action's Action Payload Definition record, again using the value being returned in the handles function (GATEWAY_CMDB_CI_QUERY_FILTER) and not the extension point API name itself.
When using this query, the result returned with demo data CI count returned is 2018 records, which coincides with the Gateway and empty values being filtered out. While this is a simple example using hardcoded values, it illustrates how to create a point from an out-of-the-box extension point, modify the query, and call the extension point from a declarative action's action payload definition to filter records by default in the modal pop-up.
