UI Actions
From SNCWiki
John.roberts (Talk | contribs) (/* Controlling access via conditions -- rel list parent exposed) |
|||
| Line 74: | Line 74: | ||
#gs.hasRole('itil'). The current user must have the itil role in order to use this action | #gs.hasRole('itil'). The current user must have the itil role in order to use this action | ||
| - | <br> | + | <br> |
| + | |||
| + | {{:Winter_2009}} | ||
| + | ==== Related list parent form condition ==== | ||
| + | List button UI Actions on related lists can now reference the parent record. For example, if you wanted to disable Affected CIs New and Edit buttons for closed changes you could copy the global m2m UI Actions to the task_ci table and add a condition of parent.active. | ||
=== Controlling access via roles === | === Controlling access via roles === | ||
Revision as of 15:27, 15 December 2008
 | Note: To see how to hide or restrict the New or Edit button on a list or related list, use List Control. |
UI Actions are an easy way to put buttons, links, and context menu items on forms and lists, making the UI more interactive, customizable, and specific to user activities. These buttons, links, and context menu items can be scripted, making them more powerful.
Contents |
Introduction
UI Actions include:
- Form buttons
- Form context menu items (right-click the header)
- Form links (navigation link at the bottom of a form)
- List buttons
- List context menu items (right-click a record)
- List choices (at the bottom of a list)
A single UI Action can provide any or all of these. UI Actions are found by navigating to System Definition --> UI Actions.
UI Action field descriptions
- Show insert: shows a button on new records that have not been inserted
- Show update: shows a button on existing records
- Show multiple update: shows the button on Multiple Record Update forms
- Show query: shows the button on Search forms
- Form button: puts a button on a form
- Form contextmenu: puts a context menu action on a form (right-click the form header)
- Form link: puts a navigation link at the bottom of a form
- List button: puts a button on a list
- List choice: puts a choice in the dropdown at the bottom of a list
- List contextmenu: puts a context menu action on list rows (right-click a row in a list)
- Name: the label of the UI Action (text on the button, link or contextmenu item)
- Table: where the UI Action will appear. An extended table also gets its base table's actions (e.g., Incidents get Task actions). "Global" means all tables
- View: used to restrict UI Actions to a specific view
- Order: defines the display order of UI Actions (buttons left to right, menu actions top to bottom)
- Action name: name by which a UI Action can be referred to in script
- Client: the UI Action will execute its script in the user's browser, not on the server
- Condition: used to restrict when a UI Action will appear
- Script: run when a UI Action is executed
Controlling when an action appears
Not all actions should be available all the time, or to all users. A "Close Incident" button, for example, might only be available to group managers, or potentially should only appear on incidents which are already in the resolved state. Alternately, you might want to display an action on certain views of your form, but not on others. With UI Actions, you can control all of this.
Controlling access via conditions
The most direct way to control the availability of an action is by using its condition field. Just as in the rest of the system, the condition on an action must evaluate to true before the action will appear on your form (with blank conditions being considered to be true).
For example, here's the condition on our out of box "Close Incident" button:
Which says that two things must be true for this action to appear:
- current.incident_state most not equal 7. In other words, the incident must not already be closed
- gs.hasRole('itil'). The current user must have the itil role in order to use this action
Related list parent form condition
List button UI Actions on related lists can now reference the parent record. For example, if you wanted to disable Affected CIs New and Edit buttons for closed changes you could copy the global m2m UI Actions to the task_ci table and add a condition of parent.active.
Controlling access via roles
This is actually a special case of conditions, but it's worth its own line to make it clear. You can test for the presence of a role with the syntax:
gs.hasRole(<something>)
Example 1: Require Admin
gs.hasRole('admin')
Example 2: Require Role 'itil_incident' or 'itil_problem'
gs.hasRole('itil_incident') || gs.hasRole('itil_problem')
Example 3: Require Role 'itil_incident' and 'itil_problem'
gs.hasRole('itil_incident') && gs.hasRole('itil_problem')
Controlling access via views
As an alternate to role or conditional security, you might also want to restrict a button to one or more views within the system. To do so, you need to use the UI Action Visibility related list at the bottom of your form.
A given action's visibility is controlled by one or more view rules, according to the following rules:
- If there are no visibility rules, the action shows up on all views.
- Any exclude rule on a given view means the action will not show up on that view
- If there is at least one include rule, then the action will appear only on those views which are specifically included
Example 1: Show an Action everywhere except the Self Service view
Example 2: Show an Action on the Routine and ITIL views, but nowhere else
Notes
Redirect to a URL
To redirect a user to a URL using a UI Action (handy in links, or after creating a new record where you want the user to land on that new record), you can use the following syntax in its script:
action.setRedirectURL('http://www.mysite.com/mypage.htm');
Or alternately, if you just created a new GlideRecord with the variable name "my_new_record":
action.setRedirectURL(my_new_record);
