Create, deploy, and maintain analytic applications that engage users and drive revenue. See a Logi demo

Development Tips

Logi Tutorial: How to Personalize and Secure Dashboard Views

By Nicholas Knapp | August 29, 2017
Share on LinkedIn Tweet about this on Twitter Share on Facebook

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.

>> Related: A New Approach to BI Security – 3 Ways to Keep Your Analytics Safe <<

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:

Built-In Value Description
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
  • Tooltips
  • 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.

 

2. Conditions

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
  • Division
  • Local Data
  • More info Row
  • More info Row Column
  • Include Frame (also called Sub-Report)
  • Row
  • Security Filter
  • Set session variables
  • Tooltip Panel

Condition Logic

Conditions are built from logical operations within elements. They have different names depending on when they are run:

  • Condition
  • 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.

Loading Times

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:
    • Text
    • 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
  • Reports

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.

>> Dive Deeper: Watch the Webinar on Show Modes, Conditions, and Security Rights <<

 

About the Author

Nicholas Knapp is an Application Support Engineer at Logi Analytics.

Subscribe to the latest articles, videos, and webinars from Logi.