To be effective and secure, analytics dashboards and reports need to provide a curated view based on user roles and security rights. Personalizing views means users aren’t overloaded with data they don’t want to—or shouldn’t—see.
A cluttered dashboard, full of alerts and too much information, creates confusion and will often load slowly, detracting users from adopting the tool. On the other hand, a well-designed dashboard is curated with the end user in mind and lightweight, with a quick load time and clear visual hierarchy. This necessitates hiding some content from the user, at least until they dig deeper into the analytics.
Creating personalized dashboard views based on rights and roles also means you can configure multiple security levels easily. That way a sales representative doesn’t have access to, for instance, an HR dashboard with sensitive information. Users only access what they are authorized to view.
Personalizing Dashboards in Logi Studio: Show Modes, Conditions, and Security Rights
Logi Analytics developers use Logi Studio—a tool designed to create Logi applications as easily and efficiently as possible—to configure dashboard panels and give users secure access to only the features and levels of control they need.
In this post we will give you best practice tips on how to hide content using three methods available in Logi Studio: Show Modes, Conditions, and Security Rights.
1. Show Modes
Show Modes is the easiest way to hide content. Show Modes are usually placed on a container element such as Division, Row, or Column Cell. They prevent elements from being displayed on the page.
Note: An Element hidden with a Show Mode will still appear within the page, but won’t be visible to the user. It will have some effect on page load time and the user will be able to view the information if they go to Browser Console and view the Source Code on the page. The main exception is the StyleSheet element, which will only be applied when the Show Mode is called.
Built-In Show Modes are available in Logi Studio by default. This table summarizes the Built-In Values and Descriptions:
|All||Element will always be visible|
|None||Element will never be visible|
|rdBrowser||Element will only be visible when report is viewed in a browser|
|rdExport||Element will only be visible when the report is exported|
|rdExportCsv||Element will only be included when report data is exported to a CSV file|
|rdExportExcel||Element will only be included when report is exported to an Excel worksheet|
|rdExportPdf||Element will only be included when report is exported as a PDF|
|rdExportWord||Element will only be included when report is exported to a Word document|
Custom Show Modes can be applied to elements as well. They can either be singular or comma-separated lists. The default Show Modes for the report are defined in the Report element, which is the top-most element in Studio. A comma-separated list can be passed in the URL, using AJAX Refresh by using link parameters, to override these defaults (e.g. &rdShowModes=Main,HR). If a single element needs to be displayed, an Action.Show element can be used.
When to Use Show Modes
Show Modes should be used to hide any elements that need to always exist on the page or need to be accessed quickly. For example:
- User Inputs
- Static Visuals
- Value Storage fields
When Not to Use Show Modes
There are specific scenarios when you should not use Show Modes, including:
- To hide any element that has a long loading time and does not need to be displayed at the initial load time. For example:
- Dynamic Charts
- Drill-through reports
- Alternate Visuals
- To secure content: Since Show Modes mean elements will still exist on the page and can be displayed if the user opens the Browser Console and views Source Code, they are not ideal for determining security levels.
- Whenever complex logic is needed to determine when to display the element.
A condition restricts elements based on user input or other values (only run when element is not equal null). Conditions can be placed on a wide variety of elements and they control when the engine uses those elements. When the page is loaded, the logic within each condition is checked. If that logic doesn’t return True, the element won’t run. This prevents the element and any children from being rendered in the browser.
Conditions can be placed on the following elements:
- Column Cell
- Crosstab table label column
- Data Table Column
- Local Data
- More info Row
- More info Row Column
- Include Frame (also called Sub-Report)
- Security Filter
- Set session variables
- Tooltip Panel
Conditions are built from logical operations within elements. They have different names depending on when they are run:
- Include condition
A condition will accept all tokens and intrinsic functions. They operate using:
- Standard comparison (=, <,>, <=,>=,<>)
- Logical operations (AND/OR)
Note: When building a Condition, it is important to control for potential NULL values. This is most easily done by wrapping the tokens used in single quotation marks (‘’). If NULLS are not controlled for, an error may occur when the report runs.
Add a Wait Panel element under your Action.Refresh element to automatically display a message of your choice while the content loads. This lets the user know when they can continue, since the child elements need time to load. This will also create a modal screen that prevents the user from continuing to click on the page, triggering more actions.
When to Use Conditions
Conditions should be used to hide any elements that need to be dynamically generated, allowing more flexibility. Show Modes processing occurs in the client (the browser), whereas Conditions are processed in the server. This means Show Modes are more browser-dependent and may not always behave exactly as expected with different browsers, making Conditions a better choice in many situations, including:
- Show only relevant rows/columns in a table based on user input and access level
- Allow the user to open time consuming visualizations once they’ve determined the data they want to see.
When Not to Use Conditions
There are specific scenarios when you should not use Conditions, including:
- To hide a static element. Instead, it’s best for the user to have to load static elements once. This is true for:
- User Inputs
- Charts or supplementary visuals that will not change no matter what the user does with the report
- For simple, user-based security. While conditions can be used to secure data, Security Rights are specifically designed for and more effective for controlling simple user-based access.
3. Security Rights
Security Rights are a special type of condition used to set access levels for users. They are written like Show Modes, but prevent the element from rendering like conditions. When a user logs in, a list of rights can be generated for them. The list is defined in the application’s _Setting file. If a user doesn’t have the security right ID required to access a certain level of content, it will not be rendered.
Building Security Rights
Security rights can be placed in a very large number of elements. They operate for:
- Individual Divisions
- Data Table Columns
If a page’s content is secured, it will not render for unauthorized users. Similarly, when a report is secured, unauthorized users trying to access it will see an error message. By setting security rights on sensitive data, report definitions can be used by many different users.
Bringing It All Together
In the design process, consider what each user needs to see, including what’s relevant and timely for their specific use case. Once you have understand each persona that will be accessing your dashboards, you can decide how to render their specific content using the three methods we discussed.
To sum up:
- Use Show Modes to hide content that the user will need immediately but isn’t always relevant, such as user inputs and tool tips.
- Use Conditions to create a better experience by lowering loading times and calling supplementary visuals only when they are needed.
- Set Security Rights to reuse definitions by securing data only certain users should be able to access.