The configuration key of the "Color dictionary" parameter type is used to determine the color scheme of statistical values. If the same values occur in different statistics, the values should be viewable in consistent colors. Thus, the "Approved" value is always "green" irrespective of the statistic in which this value appears.
This chapter describes how to edit a configuration key value. Declaring a configuration key is covered in another section of this guide. For more information, see Declaring Configuration Keys in Modules and Components.
To edit a configuration key value of the "Color dictionary" parameter type in the "Settings..." view
|
Note: Before you can edit the values in a database column, you must add a matching entry in the Configuration (custom) view. You can recognize this entry because it is marked with X in the Value (custom) column in the configuration key list in the Settings... view of the selected database object. |
Open the required database object in the definition tree view and select the Settings... view.
Open the Change color dictionary dialog box by clicking .
You can add and remove color values in Numbered values and in Predefined values.
A new color bar is shown below the corresponding area.
This displays the selected color under Custom colors.
The color bar is now in the right position. If the color bar in in the first position, it will appear in the first position of the statistics. This bar represents the value with the highest priority. The importance of the other bars is set according to their position in the list of color bars.
The color bar is now named. For example, the green color bar is called "Approved".
Your settings are saved. The number of selected columns is displayed under Details and in the Settings.. view in the column Value (custom).
This dialog box allows you to create and edit substitution rules for module copies. Substitution rules are listed that were added with the Copy objects wizard.
|
NOTE: Substitution rules have higher priority that references in the definition tree. References in the definition tree are no changed in this case. |
For example, a substitution rule from both the VI_Delegation module and the Custom_Delegation module copy can exist. The modules are mentioned by way of example in the steps below.
To edit a substitution rule
This displays the Configure project - Customization dialog box. If substitution rules already exist, they are listed here. The following editing options are available in this dialog box.
Function | Description |
---|---|
Creates a new substitution rule. Module name (no name) is shown in the column and the Module name and Replace by text fields are empty. | |
Deletes the marked substitution rules from the list. | |
Module name text field |
Specifies the module name. When you create a substitution rule the text field is empty. Enter the module manually. Edit a substitution rule, overwrite the module name (in our example, VI_Delegation) with another module name. |
Replace by text field |
Specifies the module copy. When you create a substitution rule the text field is empty. Enter the module copy manually. Edit a substitution rule, overwrite the module copy name (in our example, Custom_Delegation with another module copy name. |
|
NOTE: If a module is no longer needed, the substitution rules can simply be deleted. |
A component can be referenced in two ways. Normally, a static reference is used to reference components directly using their names.
An example of a static reference is calling the component VI_Popup.
|
NOTE: It is not possible to use object-dependent references on the login page if the web application is executing against an application server. |
The second way of referencing components is dynamically. Dynamic references can reference more than one component at a time. A specified criteria is used to determine which component will effectively be referenced at runtime. This method of referencing makes it easier to build extendable generic components.
© 2023 One Identity LLC. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy