Determine if a UI action is configured correctly
A UI Action might not work as expected for a number of reasons. mostly related to how the UI Action was defined.
Symptoms may include the following:
- The UI Action is not visible.
- The UI Action not working.
Either one of the Table, Condition and Script fields is not properly defined.
Check the definitions for the Table, Condition, and Script fields - these fields are the most important ones to be correctly defined.
UI Action can be defined for a specific table/database view, or by selecting Global it can be defined on every table. The UI Action also appears on tables that extend the selected table. You can change this behavior by overriding the UI Action - create a UI Action with the same action name for the extended table. If there is an action for the task table, then you need to create a new one for the Incident table with the same action name.
After the table is specified with a condition, you can restrict the appearance of the UI Action on the form.
If the UI Action is not visible on the form, then the first step is to check the condition.
The Condition field should contain an expression that evaluates to true or false. An empty Condition field evaluates to true, resulting in the UI Action to appear on the form.
If the specified expression does not evaluate to true or false, then results can be unexpected - the UI Action might or might not appear. It is best to use an 'if' condition or functions that evaluate to true or false.
The following is an example of a condition that returns an object, which is invalid:
(new GlideRecord(current.getTableName())) && gs.hasRole('catalog_admin')
Instead, a valid condition that returns true or false, would be:
The following is also an example for an invalid condition, which returns user_id is:
For a list context menu UI Action, do not use the current object because it will be ignored.
If the UI Action is not working, then it is most likely related to the script. In the script you can use 'current' which relates to the current form that you are on.
It is recommended that before you save the UI Action, you click on Check Syntax in the header of the Script field.
Variables should be defined before they are used, otherwise an error is generated. To troubleshoot an action that is not working as expected, you can add log statements. Below are example of 2 different methods for logging statements, for client and for server side scripts.
How a script is evaluated at execution time and what type of methods you can use, depends on whether the Client option is checked or not:
- If not checked - then you can use server side methods such as gs... because they will be executed on a server.
- If checked - then the OnClick field appears on the UI Action form and the script will be executed on the user's browser and on the server. In this case, use jslog(‘test’) for debugging, not gs.log(‘test’).
The following is an example of a script that contains both client and server side:
// OnClick field has value 'resolveIncident();' and Script Name 'resolve_incident'
//Set the 'Incident state' and 'State' values to 'Resolved'
//Call the UI Action and skip the 'onclick' function
gsftSubmit(null, g_form.getFormElement(), 'resolve_incident'); //MUST call the 'Action name' set in this UI Action
//Code that runs without 'onclick'
//Ensure call to server-side function with no browser errors
if (typeof window == 'undefined')
current.incident_state = 6;
Other fields such as Form link, Form context menu and Form button also determine what type of action is created.
The specified conditions are used to restrict the UI Action visibility, or you can also use Views for the same purpose. In the Related list UI Action Visibility you can include or exclude the View on the form that will contain the action.
The action name should be unique within UI actions unless you are overriding the specified action on the parent table. The action name can include '.' as a special character, however, this was restricted to '_' in earlier releases.