We are pleased to present our latest offering of pi - our November release! This page helps summarise and familiarise you with the changes we have made and is supported (where applicable) with useful videos to help explain the changes we have delivered.

Here’s what we’ll cover

Added

It is now possible to build and send custom API requests to external APIs for the purpose of generating variables in the dashboard. These variables can then be used when drilling to a URL chart. This makes it possible to drill to a page using a generated token in the URL as a means of authentication – allowing used to drill to pages that would normally require a log in step.

The creation of API requests is restricted to admins, but requests can be added to charts by users (explorer level or above) so long as the requests are assigned to a category that the user has access to. Multiple requests can be added to a chart, and these requests will be run on drill down, generating variables that are then usable in the url but are not stored or cached.

Creating an API request

There is a now a new tab in the settings screen called ‘APIs’ where requests can be added and edited. Here you can provide the below details to build an API request.

Request Name – Unique name for the API request you are creating.

Category – Select a category to assign the API request to. This will ensure that only users with access to that category are able to use the API request on charts.

Ordering Index – Selecting an ordering index will change the order that your API requests are displayed in the left panel. If requests have the same ordering index they will be ordered alphabetically by name.

URL – the URL of the API you wish to access.

Method - the method of the request you wish to send (selected from GET, POST, PUT and DELETE).

Body – The body of the request you wish to send to the API. This should be in valid JSON format. The field will be highlighted if invalid JSON is added.

Allow unverified certificates – option to ignore SSL certificates when accessing APIs. This will allow access to APIs that are served using self-signed certificates. CAUTION: It is not recommended to enable this setting unless absolutely necessary due to potential security risks.

Headers – any headers required for sending the request. Typically, this will include a Content-Type header for any request with a body but could also be used for sending information for authentication.

Response Mapping – for mapping the values received in the APIresponse to variables in the dashboard. Variable name corresponds to the name you would like to assign to the generated variable (e.g. USER could be access in the dashboard using [[USER]]). Response key corresponds to the JSON dot notation that will provide the correct value (e.g. a JSON response of {“user”: {“first_name” : “Susan”} would use a response key of “user”.”first_name” to assign “Susan” to the variable.

It is also possible to Test an API request by hitting the lightbulb button when all the relevant details are entered. This will cause JSON response to appear in the response mapping table, showing the available keys for mapping.

Adding an API request to a chart

API requests can be run when drilling to a URL chart. API Requests are added to the URL chart that is being drilled to in the chart editor. This is done in the “API Requests” tab.

You can add a request by hitting the + button and selecting from the displayed API requests in the pop up list.

When a request has been selected, it will show the list of variables that become available when the request is run, these variables can now be used in the URL using the variable [[ ]] notation.

When drilling to the URL from the chart, the variables should be replaced and form part of the URL that is being drilled to.

Uers will now be able to hide the chart panel heading on Card Charts.

Please see this page in piDocumentation for more information.

A new checkbox ‘Skip Pages With Empty Data Tables’ has been added to the reporting configuration panel, allowing the users to skip pages in the report, which contain only empty tables in its page content.

This covers different table types and will affect the reports exported or scheduled in pdf, PowerPoint or Word formats.

By default, the checkbox is unticked, allowing the reports to be exported in its original form.

If you try to export a report, containing only empty tables in its content and you have 'Skip Pages With Empty Data Tables’ ticked, an error will be thrown in the UI, asking you to check your ‘Skip Pages With Empty Data Tables’ configuration and no file will be returned. A similar error will also be displayed in the monitoring screen in the scheduler if you try to schedule such a report.

Changed

Alpha tag for import/export for data connections, schedules and reports has now been removed and replaced with a help icon and some help text, providing information on how to import/export between different dashboard versions.

Previously when scheduling reports out, the reports were using the default filter values. This means we wouldn't be able to schedule the same report with different filter values unless we duplicate the report.

This change is to make sure we can provide filter values to override the default definition when configuring a schedule, so that the same report can be sent with different filters.

In order to achieve this, the following changes were made:

On the Schedules screens:

• Each report attachment now has a button to launch a panel, which allows providing filter values associated to the attachment

• The panel works just like category filter selection, which supports cascading filter values

• The same report can now be added to the schedule multiple times, and they can use different filter values

On the Reports screens:

• Editing report filters can cause the definition of the overriding values to be out of sync. The report filters screen now shows the affected schedules when editing the filters

• If the schedules are affected by the change of report filters, they are disabled when saving the report. Users need to review and edit those schedules to correct the filter values accordingly, so that the reports are sent out as expected

API changes:

• Reports can now be downloaded by using the API

• Refer to the API documentation for details about downloading reports as docx, pdf, or pptx files

Schedules Screen:

Schedules Screen - Overriding Report Filter Values:

Reports Screen - Editing Report Filters

The right hand side panel appears if the change is going to cause these schedules to be disabled

When creating/ editing Category Filters, for certain Category Filter types, the system offers a pop up for selecting the default value(s). The pop-up panel now has pagination, which improves performance when there are lots of values to be displayed.

The same implementation is done for selecting Report Filter Default Values.

Fixed

Previously, when changing from a chart with Sorts and/or Targets to a chart type that doesn’t support them, errors may have been displayed due to the Sorts and Targets not being immediately removed. This has been resolved in this release of the Dashboard.

Previously, the renderer was adding extra blank pages when a report with a table was exported in PDF. This issue only used to happen in certain scenarios usually where the table content was higher than the size of the page. An extra space of 40px has now been reserved in the report page to make sure no blank pages are created.

Previously, users were able to create schedules and reports with iframes. We have now blocked the following 4 chart types from appearing on the dropdown menu for attachments in schedules and reports:

• Iframe

• Url Link

• Drill to url

• Drill to Category

Minutely and hourly schedules were re-adjusting to the incorrect time when running after midnight. For example, a time entered as 10:00 would be wrongly re-configured to 00:10. Now, the schedule correctly runs at the time defined by the user.

The details of an XML licence that are displayed in the ‘Licence’ tab of the configuration-tool would disappear if they had not yet been applied via the ‘Apply and Run’ option and you navigated to a different tab. These details now persist between tab changes.

Previously, the renderer was not working with self-signed or invalid SSL certificates when connecting through a HTTPS ‘Dashboard URL’. There is now a new option present under the ‘Renderer’ tab of the Configuration Tool, ‘Ignore Https Errors’, which will allow the Renderer to proceed despite the certificate errors.

Previously, you were unable to save an excel file to a database hosted on azure. This was due to some unnecessary escaping of characters upon saving. Now, ensuring that you have the database username credentials set up in the format ‘<username>@<server>’, you should be able to successfully save an excel spreadsheet to an azure database.

Previously, the url generated by the reset password link would contain ‘localhost’ rather than the appropriate hosted url. It now always generates a url taken directly from the server.

Previously, the targets for a Speedometer chart would appear outside the chart under the following conditions:

• You have multiple targets set up

• The final target defined is not the one with the highest value (i.e. target one is 100-200, target two is 0-100)

This would cause a visual glitch where the target would appear outside the chart. The targets now retain their position inside the chart under these conditions.

Previously, the Tomcat logging setting within the settings screen was set to ‘debug’ by default. It is now set to ‘error’ by default. Addtitionally, there was an issue where, upon changing and saving this setting, it would not save correctly and would revert back to its default setting. This has been fixed, allowing this setting to save and update correctly.

Previously, Light Bulb charts would hide their data value when this was smaller than a certain size even if it would have been perfectly legible.

Now, both Light Bulb and Traffic Light charts will display this value, on both the dashboard and in reports containing them, no matter how small they become.

Previously, if you changed your UUID license to an invalid one the encrypted licence stored in the database would be used. This hid the fact that the new licence was invalid until the encrypted one expired.

Now, if the UUID licence is invalid you won’t be able to log in and the encrypted licence will be removed from the database.

Regardless of the type of database being run, the audit data sent to the ALM when using a UUID licence would state that it was a ‘HyperSQL’ database. Now, the database type is identified and reported correctly.

Previously, the renderer would display and an error and break when an empty table was scheduled to export or was exported in single chart mode or as part of a report.

Previously, the table width ratio was not being respected when exporting tables as Word on Windows. Now, if you create a table with varied column width/ratios, the set column widths will be adhered to when exporting tables in both single chart mode and reports.

Previously, when applying a pre-select value to a date range filter when the browser’s language was set to ‘English (United Kingdom, Oxford English Dictionary spelling)’ the data was not displaying on the chart. Now, it correctly processes the language setting, and the data displays as expected.

Previously, when loading a category with a date range Category Object that contained either a default value or a value that has already been saved and you changed the ‘to’ date to a date in the past, it would not allow you to select a ‘from’ date before the previously selected ‘to’ date.

For example:

• You load the category, and the date filter has ‘from’: ‘10/10/2022’, ‘to’: ‘15/10/2022’

• You change ‘from' to '05/10/2022’

• You cannot select a ‘to’ date before ‘10/10/2022' until after you save the change and re-load the category

This has been fixed, so you can now freely update the ‘to’ date on this filter to a date in the past.

Previously, a Renderer with default settings was unable to successfully communicate with a Dashboard served over HTTPS with secure cookies and Same-Site set to ‘none’.

Previously, users were unable to update editable tables when a non-data column was present. An example of a non-data column is having a ‘where clause’ within the object that the data for this particular table is taken from.

The following chart types can now only be exported to PowerPoint and the button that allows users to schedule these charts has been removed from the Chart Viewer screen. We have disabled the buttons that allow you to schedule the following chart types, or export them as anything other than PowerPoint, from the chart viewer screen.

• Iframes

• Url Link

• Drill to url

• Drill to Category

Repository backups created through the ‘Create Backup’ button under the ‘Repository’ tab of the configuration-tool mistakenly had two adjacent dots as part of their filename. They now have a single dot as intended.

If an output message was wider than the ‘messages’ screen of the Configuration Tool, the overflowing contents would be hidden. This would happen relatively frequently as messages were rendered on a single line regardless of their length. Now, word-wrapping is applied to each message allowing them to be broken up into multiple lines as long as logical splitting points are present.

Known Issues

Description

Screenshots/Videos

Workarounds

Warnings/Alerts

Description

Screenshots/Videos

Workarounds

Warnings/Alerts