UI actions
Buttons, links and context menu items: where UI actions run, how to control visibility, and how client and server logic combine.
Buttons, links and context menu items: where UI actions run, how to control visibility, and how client and server logic combine.
- One UI action record can cover form and list placements
- Client actions need an Onclick function, server actions use current
- Conditions are evaluated server side, so they are safe for role checks
- Move rarely used actions to the context menu to keep forms clean
One record, many placements
A UI action can appear as a form button, a form context menu item, a form link, a list button, a list choice or a list context item. Tick the placements you need on the same record rather than creating one action per placement.
Client versus server
Leave Client unticked and the script runs on the server with current and previous available. Tick Client and you must supply an Onclick function that runs in the browser with g_form. The common pattern is a client function that validates, then calls gsftSubmit to run the server half.
function confirmClose() {
if (!g_form.getValue('close_notes')) {
g_form.addErrorMessage('Add close notes first');
return false;
}
gsftSubmit(null, g_form.getFormElement(), 'close_incident');
}Controlling who sees it
Use the Condition field for data and role checks, for example current.state != 7 && gs.hasRole("itil"). Conditions run server side on form load, so they are safe for security and cheap for performance.
Keeping the form usable
Ten buttons across the top is a sign that a process needs simplification. Group related actions under a context menu, and reserve top buttons for the two or three actions people use every day.