Configuring cascading fields in process grids
The dynamic cascading indicator list fields were added to display list with different values based on each employee context. These lists are based on tables/views and can have cascading parent/child relations.
Previously, the it was possible to have filtered list fields in process grids, but not cascading lists; this feature was limited to data grids.
This feature cannot be configured via the UI; it needs to be configured via the database. This article details the steps you need to follow to configure cascading fields in a process grid.
Creating a list based on a table/view
Creating a table or a view
The list fields must be based on tables/views that need to be created beforehand. Once created, you need to synchronize the table/view to populate k_referential_table_views.
CREATE TABLE [dbo].[qa_JobFamily](
[idJobFamily] [int] IDENTITY(1,1) NOT NULL,
[JobFamilyCode] VARCHAR NOT NULL,
[JobFamilyName] NVARCHAR NOT NULL
)This is an note/information message.
The table must be populated with appropriate values.
Creating a field in Admin Portal
Once the table is created, you need to add a new field via the application in Admin Portal. To do so, proceed as follows:
Open Admin Portal, and then navigate to the (Undefined variable: CompoVariables_AP.Admin).
In the left-hand navigation menu, open Administration and then click Indicator Fields. The grid containing all existing fields is displayed.
At the bottom of the grid, click the + button to start creating a new field. A new sub-panel is opened.
Enter all of the information of the field and then click the save icon at the bottom of the panel.
Since the type of field that you need to use for cascading fields does not exist in the UI, you will then need to change the field type in the database.
Updating the field type in the database
To update the field type to the correct type for cascading fields, update the id_control_type to -7 in k_m_fields.
Retrieving the table/view ID
The next step is now to retrieve the ID of the table or the view using one of the following queries, depending on whether you’re using a table or a view:
SELECT * FROM k_referential_tables_views WHERE name_table_view = <your_table_view>;
SELECT * FROM k_referential_tables_views_fields WHERE id_Table_view = <your_id_table_view>;
Populating the k_m_fields table
In the k_m_fields table, update the following properties:
| Property | Value |
|---|---|
| combo_table_view | ID of the table in k_referential_tables_views |
| combo_value_field | ID of the field in k_referential_tables_views_fields that will be saved (such as JobFamilyCode) |
| combo_text_field | ID of the field in k_referential_tables_views_fields that will be displayed (such as JobFamilyName) |
The fields created via the procedure above can now be added to an indicator, and then to a process via the user interface in Admin Portal.
Setting up the cascaded fields
Creating the cascaded table
To configure cascaded fields, the first thing you need to do is to establish relationships between the tables. To get started with this step, you first need to a table with a relation to the reference table created above, and then synchronize this table.
Example:
CREATE TABLE [dbo].[qa_JobSubFamily](
[idJobSubFamily] [int] IDENTITY(1,1) NOT NULL,
[JobSubFamilyCode] VARCHAR NOT NULL,
[JobSubFamilyName] NVARCHAR NOT NULL,
[JobFamilyCode] VARCHAR NOT NULL
)This is an note/information message.
The table must be populated with the appropriate values.
This is a tip message.
After you have create the table, you need to create a field using this table. Follow again the steps described in Populating the k_m_fields table, and then move on to Admin Portal.
Creating an indicator and a process in Admin Portal
Once you have finished the steps above, you need to create an indicator in the Admin Portal interface, and then create a process that will use this indicator.
For more information about how to perform these two steps, refer to the Admin Portal User Guide.
Creating a relation in k_m_fields_relation
The next step in the configuration procedure consists in populating the k_m_fields_relation, using the information in the table below:
| Field | Description |
|---|---|
| id_plan |
Found in k_m_plans Corresponds to the process containing the fields |
| id_field | CID* value of the field |
| id_parent_field | CID* value of the parent field |
| id_field_table_view | ID from k_referential_tables_views_fields for the relation column |
CID value format:
id_plan (from k_m_plans) + id_indicator from k_m_indicators + id_field from k_m_fields
Example: 27_73_101
Handling multiple relations
You can handle multiple relations in cascading fields, according to the following guiding principles:
It is possible to establish multiple relations on different fields or on the same field.
One field can have up to 5 parent fields. If more are configured, a warning message will be displayed in the Web App user interface and only the first 5 relations will be taken into account.
Creating a relation with an information column
To create a relation with an information column, proceed as follows:
Make sure that the custom table is properly populated.
In k_m_fields_relation, define id_parent_field to the IC_ID value. Example: IC_2272, built from k_referentials_grids and k_referential_grids_fields, which corresponds to the process template.
Feature limitations
The following list outlines the limitations of the cascading fields in process grids:
No validation is performed on the configuration.
Incorrect configurations (for instance, configurations that reference a non existent field ID) will cause a generic error in the system, without detailed information.
Translations are not supported.
Cascading fields cannot be configured via API.