When launching the web client for the first time, the Home view is the only view available, as it can be seen in the Sidenav. For more details, refer to Section Understanding the Sidenav List.

The default Home view only displays the Scenario List widget. For more details, refer to Section Using the Scenario List Widget.

Just like for custom views and dashboards, one can configure the visibility of the toolbar and Scenario Selector for the Home view. For more details, refer to Section Understanding the Views and Dashboards Management View.

Users can define a dashboard — not a view — as their custom Home view, either:

After setting a dashboard as custom Home view, the default Home view is still available in the Sidenav List.

Figure 9.7. Understanding the Custom Home View

	Note that, to avoid losing the custom Home view configuration, the Application Configuration must be exported and reimported to make sure it is taken into account. For more details, refer to Sections Exporting an Application Configuration File and Importing an Application Configuration File.

The Permission Management view can be accessed, from the Topbar Settings Menu via Application Configuration > Permissions. For more details, refer to Section Understanding the Topbar Settings Menu.

Figure 9.8. Understanding the Permission Management View

Only users with ACCESS and MODIFY rights on the APPLICATION_PERMISSIONS application element or users with the PERMISSIONS_ADMIN role have access to the Permissions Management view.

The Permission Management view allows setting specific permissions to users. For more details, refer to Part Securing.

The Permissions Management widget is split in three tabs to address these three use cases.

What is important to understand is the three-state checkboxes found in the rows for the available Access rights.

When the administrator changes decision checkboxes, a modification icon appears next to the affected user pattern until the user clicks on the "save" icon. The user can also choose to use the "reload" icon, which invalidates all the changes and resets the permissions to their previous state. You must save the rules in the current tab before switching to another tab. You will notice that some of the user patterns are gray while others are black: this allows the user to see at a glance which user patterns have no rules defined. The same display mode is applied to permission groups in the second tab, and to application elements in the third tab.

The three possible states of the checkbox are:

Figure 9.9. Understanding Checked Permissions

Figure 9.10. Understanding Unchecked Permissions

Figure 9.11. Understanding Undefined Permissions

3.2.2.1. Understanding the "Default Rules" Tab

The Default Rules tab allows granting permissions, over application elements, to users or user roles.

Figure 9.12. Understanding the Default Rules Tab

The control widget displayed in this tab is what we call a ruleset editor. On the left are listed all the users and roles, the so-called "user patterns", while the right part shows all element types and access rights for which the permissions can be edited.

When loaded the grid shows the default rules for the selected user pattern.

You can see that some combinations are shown as N/A. This happens when the access right does not have a meaning for a given object type. For instance, one cannot define a permission rule for the combination Tasks/Delete on TASK type since Tasks are defined by the backend code of the application, and cannot be deleted.

3.2.2.2. Understanding the "Permission Groups" Tab

The Permission Groups tab allows to create/edit/delete Permission groups in the left part using command buttons that act on the selected group.

Figure 9.13. Understanding the Permission Groups Tab

A permission group is a collection of application elements. The purpose of a permission group is to gather several elements to which a common set of permission rules apply. Using a permission group is a good way to avoid duplicating the rules from element to element. In this sense, permission groups can be seen as the equivalent for application elements of roles for users.

When a group is selected, the ruleset editor on the left will allow to define a set of specific rules for user patterns and application element types. One can define rules for all the element types in a generic manner so that, as soon as elements are assigned to this group, they will follow the same rules.

This means that, if we define "Workspaces", "Tasks", or "Views and Dashboards" rules for a group in advance, those rules will be used when elements are assigned to it in the third tab.

3.2.2.3. Understanding the "Application Elements Override" Tab

The Application Elements Overrides tab has two functions:

• Assigning application elements to permission groups

• Attaching permission rules to a specific application element.

Figure 9.14. Understanding the Application Elements Overrides Tab

All application elements are listed in the left part, represented as a tree view. You will find there all the workspaces with the scenarios they contain, custom views and custom dashboards as well as a folder containing all the tasks available in the application. Note that the groups that the elements are attached to will be displayed after their name, clicking on the groups button will bring up a selection tool allowing to assign one or several permission groups to the selected element:

Figure 9.15. Understanding the Manage Permission Groups of Application Elements Configurator

For the rules overrides, a ruleset editor is displayed for each element, allowing to see and edit specific rules attached to this element for all the user patterns.

Unlike the other tabs, the lines displayed in the ruleset editor vary according to the type of the selected element. For instance, it does not make sense to attach permissions on application element "Task" while defining rules for a scenario or a dashboard.

This tab is also used to manage orphan scenarios. For more details, refer to Section Addressing Orphan Scenarios.

The Views and Dashboards Management view can be accessed, by users with the right permissions, from the Topbar Settings Menu via Views and Dashboards > Configure. For more details, refer to Section Understanding the Topbar Settings Menu.

Figure 9.16. Understanding the Views and Dashboards Management View

The Views and Dashboards Management view allows adding, deleting and renaming views and dashboards as well as configuring the way links toward them are displayed in the Sidenav. For more details, refer to Section Understanding the Sidenav.

If you need to hide views, you can remove ACCESS permission to given users or roles from the Permission Management View. For more details, refer to Section Understanding the Permission Management View.

This view has two panels:

The right panel Views Structure always displays at least one link toward each view and dashboard available to the user. Every change to the Views Structure panel is automatically saved and reflected in the Sidenav.

There also are two arrows between the panels. The right arrow allows adding additional elements from the left panel to the selected folder or to the root level of the Views Structure panel. The left arrow removes additional elements selected from the Views Structure panel, as does the "trash bin" button in the widget toolbar.

Empty folders are not be displayed in the Sidenav though they are visible in the Views Structure panel.

The Workspaces view can be accessed, by users with the right permissions, from the Topbar Settings Menu via Workspaces > Manage Workspaces. For more details, refer to Section Understanding the Topbar Settings Menu.

Figure 9.17. Understanding the Workspaces View

The Workspaces view contains only a Workspace List widget. For more details, refer to Section Using the Workspace List Widget.

It allows creating, renaming and deleting workspaces via the Action button on each row. Right clicking on a row allows its content to be copied with or without the column names as well as exported in .csv or .xlsx format.

The API Keys Management view can be accessed, by users with the right permissions, from the Topbar Settings Menu via Application Configuration > API Keys Management. For more details, refer to Section Understanding the Topbar Settings Menu.

Figure 9.18. Understanding the API Keys Management View

The API Keys Management view allows creating and deleting time-limited API keys that allow the current user to interact with the application through its API from a REST client.

Users cannot create an API Key for other users.

For more details, refer to Chapter Understanding the APIs.

The Job List view can be accessed, by users with the right permissions, from the Topbar Settings Menu via Job List. For more details, refer to Section Understanding the Topbar Settings Menu.

Figure 9.19. Understanding the Job List View

The Job List widget is the only one populating this view. For more details, refer to Section Using the Job List Widget.

	Note that: Unlike a custom view with a Job List widget, this management Job List view is not displayed in the Sidenav. Unlike a Job List widget created on a custom view or dashboard, this management Job List view displays all jobs regardless of the scenario and cannot can be configured to Filter by current Scenario Selection or Only show current User's Jobs.

The Custom Colors view can be accessed, by users with the right permissions, from the Topbar Settings Menu via Application Configuration > Colors. For more details, refer to Section Understanding the Topbar Settings Menu.

Figure 9.20. Understanding the Custom Colors View

The Custom Colors view allows displaying and setting color hints entity values. The data from the current scenario is used to display and help configuration, however, the customization mechanism is based on business keys and the custom colors will be applied to all workspaces and scenarios.

The data displayed depends on the application context. It is defined by the scenario currently active, which can be selected via:

The option Define default color allows setting a single color for unset values. In the figure below, a light gray was defined by default. If no default color is defined, entities not having a defined custom color will use the colors generated by the web client.

The option Reset colors for this entity allows resetting the selected entity default colors.

Figure 9.21. Understanding the Custom Colors

Different color parameters can be set, imported and exported in the application configuration. For more details, refer to Section Setting Application Preferences.

	Visibility of the application elements depends on: The current application preferences. For more details, refer to Chapter Configuring the Application; and The current user permissions. For more details, refer to Section Understanding Operations.

When using the web client, the data displayed in the widgets depends on the "context". For more details, refer to Section Understanding the Scenario Service Context.

The context is defined by the:

Some widgets, such as the Data Grid or the Data Explorer have a persistent state, so that when you leave a view and reopen the same view later, the widget is restored to the previously saved state (e.g. applied filters, sorts, selected type, column size, ...).

Widget states are saved per user and per widget, to reset a widget to its initial state a menu item is available in the top-right corner menu.

Note that when a view, or a dashboard configuration is modified, all the widget states associated to this view or dashboard are reset.

Figure 9.31. Understanding the Widget Reset

Several widgets display data in the form of a table where columns can be manipulated a way or another. Most of the time, the column labels can be set via the widget configurator. For more details, refer to Section Using the Default Widgets.

In the widget, each column label displays a menu button when hovering the mouse over it. This three-tabbed menu can provide users with:

Scenario comparison offers the ability to highlight differences between two scenarios data.

The Data Grid widget, which is also embedded in the Data Explorer widget, allows to compare scenarios data row by row. For more details, refer to Sections Using the Data Grid Widget and Using the Data Explorer Widget.

When comparison mode is enabled, the Data Grid splits comparison data in three tabs:

Rows of the compared scenarios are associated between scenarios according to primary key definition of each table, as defined in the application JDL file.

Scenario comparison mode can be enabled through a dedicated button in the views and dashboards toolbar.

Figure 9.32. Understanding the Scenario Selector in Comparison Mode

After activating the comparison mode, the scenario selector will give the ability to select a scenario, and also to select a reference scenario to compare with (orange).

A switch button is also present to switch the selected and the reference scenarios.

The comparison mode is global.

Compatible widgets (Data Grid and the Data Explorer) can individually activate this mode by configuration:

Figure 9.33. Understanding the Automatic Scenario Comparison Mode

When a widget is not configured to automatically enable comparison mode, a button in the widget toolbar allows users to switch between normal and scenario comparison mode.

When scenario comparison mode is enabled the Data Grid will show two columns by entity attributes, one for the selected scenario (in gray) and one for the reference scenario (in yellow).

Note that the primary key attributes will be displayed as a single column since the value is the same for both scenarios.

Figure 9.34. Understanding the Scenario Comparison Mode

	Note that: Only valid scenarios can be compared. Only entities with primary keys are supported. Singleton entities are not supported.

Scenario comparison can be used via a dedicated API. For more details, refer to Section Understanding GraphQL Scenario Comparison.