Dynamic windows
You can dynamically set whether or not a field on a window in Web Access or Ivanti Workspaces is mandatory, read-only, or hidden based on values selected elsewhere on the window.
Example uses include:
- displaying additional fields when a specific Category or User is selected
- making a field mandatory if a specific Urgency is selected
- making a Location field editable if an Out of Office check box is selected
Dynamic windows are available for Web Access and Ivanti Workspaces only, and are designed using calculations that are added to attributes in Object Designer. New Window Functions have been added to the calculations editor that are available for these Window Calculations. Example calculations are provided and explained later (see Example window calculations), and are also available from the Ivanti Community web site.
For more information about creating calculations and using the calculations editor, see Calculations.
The Window Functions are:
:SetHidden(attribute, True/False) (shows and hides attributes)
:SetMandatory(attribute, True/False) (makes attributes mandatory or non-mandatory)
:SetReadOnly(attribute, True/False) (makes attributes read-only or editable)
(where attribute is the name of the field that you want to apply the function to)
If all of the fields in a group box are set to be hidden, then the group box itself is also hidden. If one of the fields in a hidden group box is set to be visible, then the group box also becomes visible.
Attributes that are set to be mandatory at the object level in Object Designer cannot be made non-mandatory using a window function.
These calculations are for Web Access and Ivanti Workspaces only. They are not available for manipulating windows in console.
Planning your window design
Calculations to control these properties of windows require three attributes to be added to the window:
- the trigger attribute – the attribute that causes the calculation to run when you change it; this attribute must also have the Is calculate on change property set to True in Window Manager, and be added to the Dependencies pane of the calculation editor
- the target attribute – the attribute that changes as a result of the calculation
- the calculation attribute – the string attribute on the window's object that stores the calculation
To help you to identify the target and trigger attributes for your window calculations, you might find it helpful to write a requirement for the calculation in the form:
When <trigger field> is set to <value>, I want to change <property> of <target field> to <true/false>.
For example, if you want the CI field to appear when the Category for an Incident is set to Hardware, you would write:
When Category is set to Hardware, I want to change the SetHidden property of the CI field to false.
From this, you can see that the trigger attribute is Category, the target attribute is CI, and the Window Function that you want to use is :SetHidden(,). You want to make the :SetHidden(,) value false because you do not want the CI field to be hidden.
Target attributes that you can dynamically update are:
- date and time controls
- drop-down lists
- category lists
- text and numeric fields
These calculations can be triggered by changes to:
- date picker controls
- booleans (both check boxes and drop-downs)
- drop-down lists
- category lists
Although these attributes must be present on the window, you can hide them if required by setting the ShowOnWindow property to False in Window Manager. You may find it helpful to have the calculation attribute visible on the window while you are designing the dynamic window, to help you to design and debug your calculation, and then to hide it when the window goes live.
There are rules on using window calculations. On a single window design, you can use:
- many calculation attributes to update many different target attributes
- one calculation with one trigger attribute to update many target attributes
- one calculation with many trigger attributes to update many target attributes
However, do not use:
- many calculation attributes to update the same target attributes
The reasons for these rules are given in this paragraph, but you do not need to read it providing you follow the rules given above. All of the window calculations on a window run when the window opens as well as when the trigger attribute is changed. This ensures that when the window opens, it appears appropriately for the data that is displayed on it. However, you cannot control the order that the calculations run in when the window opens. This means that you need to make sure that each target attribute is updated by only one calculation, or your calculations will give unpredictable results when a window opens. You can create a calculation that uses more than one source attribute to update a single target attribute, or create a calculation that updates more than one target, but do not design a window that has more than one calculation for each target attribute.