Page Comparison

You can now have the Scheduler log in JSON format via checking the box in the Configuration-Tool GUI or setting the following Environment Variable to true: SCHEDULER_LOGGING_JSON. This setting, the other logging settings, and the JWT Key Path setting have also been added to the Configuration-Tool GUI.

Image Added

The option to have pirana logs output in JSON has been added. This can be configured via the config tool. You can also now successfully set the appropriate log level, with it defaulting to INFO.

Image Added

You can use the “PIRANA_LOG_LEVEL" variable to set the log level, either to “ERROR“, “WARN”, “DEBUG” or “INFO”.

You can set the “PIRANA_LOGGER_JSON" variable to either “true” or “false”, to enable JSON logs.

Previously, a hardcoded default was used for the email claim name that would attempt to link a SAML login response and a Dashboard user. This default ‘XMLSoap’ value will still be used as a last resort but you now have the ability to define a custom email claim name in the SAML section of the Global Variables screen.

Additionally, there is also a field for a custom Usercode claim name which rather than attempting to match to a user’s email address will match based upon their Dashboard Usercode (Username). If the usercode claim name is defined or the default (see below) manages to extract a value from the SAML response then the Email claim will be ignored even if provided.

The defaulting behaviour of these claims is as follows:

Usercode:

• If defined the Custom value will be used. Should it fail to retrieve a value or the retrieved value does not match a Dashboard User’s Usercode then login will fail

• Our namespaced default claim of “https://www.panintelligence.com/claims/usercode“ will be attempted. If it fails to return a value or match a Dashboard User then login will fail

Email:

• If defined the Custom value will be used. Should it fail to retrieve a value or the retrieved value does not match a Dashboard User’s Email then login will fail

• Our namespaced default claim of “/wiki/spaces/DEV/pages/1582238068 will be attempted. If it fails to return a value the final fallback will be attempted

• The final fallback for Email is the ‘XMLSoap’ claim that was previously the only claim used. If this fails to retrieve a value or match a Dashboard User’s Email then login will fail

Image Added

A new system variable `START_OF_FINANCIAL_YEAR_MONTH` has been introduced to the dashboard that defines a month in which a financial year begins. This variable can be set in the Global Variables panel in Dashboard Configuration:

Image Added

This input field accepts values from 1 to 12 to represent the starting month for the financial year, where 1 equals January and 12 equals December.

This `START_OF_FINANCIAL_YEAR_MONTH` system variable will drive the values available in the new ‘Financial’ tab in the popup panel for the date range category object type. ‘Financial’ tab will only be visible when `START_OF_FINANCIAL_YEAR_MONTH` is defined.

Image Added

The month name in ‘Your Financial Periods run from xx’ can be translated by adding its translated value to the messagesData.properties file. For example, in messagesData_fr_FR.properties file: January=Janvier.

The ‘From’ and ‘To’ for the selected option (e.g. ‘This Quarter’, ‘Next Year’) will be calculated based on the entry for `START_OF_FINANCIAL_YEAR_MONTH`. For example, if you enter 5 (May) for `START_OF_FINANCIAL_YEAR_MONTH` then 'Next Year' will be From: 2025-05-01 to 2026-04-30.

The same calculations for variable replacement based on `START_OF_FINANCIAL_YEAR_MONTH` definition can also be accessed by using the new financial magic variables:

- START_OF_CURRENT_FINANCIAL_QUARTER
- END_OF_CURRENT_FINANCIAL_QUARTER
- START_OF_LAST_FINANCIAL_QUARTER
- END_OF_LAST_FINANCIAL_QUARTER
- START_OF_NEXT_FINANCIAL_QUARTER
- END_OF_NEXT_FINANCIAL_QUARTER
- START_OF_CURRENT_FINANCIAL_YEAR
- END_OF_CURRENT_FINANCIAL_YEAR
- START_OF_LAST_FINANCIAL_YEAR
- END_OF_LAST_FINANCIAL_YEAR
- START_OF_NEXT_FINANCIAL_YEAR
- END_OF_NEXT_FINANCIAL_YEAR

We have added the ability to add temporary category objects via a post message when embedding a category. Here is an example HTML and JS file you would use to configure this.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    <div id="parent-div"></div>
    <script src="tempcatobjpm.js" type="text/javascript"></script>
</body>
</html>

const url = "http://localhost:8080/pi/?lang=en_GB&categoryMode=0#/dashboard-system/#/redirectToDefaultCategoryState/34";
const iframe = document.createElement("iframe");
iframe.setAttribute("src", url);
iframe.style.width = "750px";
iframe.style.height = "750px";
document.getElementById('parent-div').appendChild(iframe);
window.addEventListener("message", (event) => {
    if (event.data && event.data === "canAddTempCategoryObjects") {
        const postMesssageJson = {
            type: "add-temp-category-objects",
            data: {
                categoryObjects: [
                    {
                        orgId: 1,
                        dataSourceItemIdentifier: "Dashboard Repos",
                        columnIdentifier: "Chart Name"
                    },
                    {
                        orgId: 1,
                        dataSourceItemIdentifier: "Dashboard Repos",
                        columnIdentifier: "Audit Type",
                        dynamicAttribute: "hello"
                    }
                ],
                messageIdentifier: "cat1"
            }
        }
        iframe.contentWindow.postMessage(postMesssageJson, url);
    }
}, false);
window.addEventListener("message", (event) => {
    if (event.data && event.data.message === "tempCategoryObjectsAdded" && event.data.messageIdentifier === "cat1") {
        const newHash = "PA-CA%23%23%23category%2F34%2Fc-o-p%3D34__0%2F*%24*eq__%5B%5BAudit%20Date%5D%5D%7B%7B--%20All%20--!%7C%23%7C--%20ALL%20VALUES%20ARE%20SELECTED%20--%7D%7D%2F*%24*eq__%5B%5BChart%20Name%5D%5D%7B%7BChart%20Types%7D%7D%2F*%24*eq__%5B%5BAudit%20Type%5D%5D%7B%7B--%20All%20--%7D%7D";
        const newUrl = url.split('#')[0] + '#' + newHash;
        iframe.src = newUrl;
    }
})

1. Ensure the you wait for the event ‘canAddTempCategoryObjects’ before attempting to make this post message, this will ensure the data stores required are loaded

2. Ensure the ‘type’ param is always ‘add-temp-category-objects’

3. Each category object requires an org id, ‘dataSourceItemIdentifier '- which is the display name of the data source, and 'columnIdentifier’ - which is the display name of the object

4. You can add an optional 4th param which is 'dynamicAttribute' which allows this to work with custom fields

5. The ‘messageIdentifier’ is used to link the post message to the next event listener in the JS example, ensuring that you apply the correct hash to the correct category

6. In the 2nd event listener, you are waiting for the category objects to be added before you update the URL hash, which will allow you to populate the category objects - alter the ‘newHash’ variable to match the data within your dashboard

As part of our drive to support infrastructure as code and dev ops ways of working we have added the ability to create a branch of a full setup including connection, categories, charts etc. Once created you can use import-export to migrate live content into this isolated environment and work on it, then extract it again later to move to production. Please see our docs for more information. We intend to build on this work so look forward to hearing feedback which will help us refine and extend this functionality.

In rare, unforeseen scenarios an exception can occur when saving to the Dashboard Repo even though the validation checks have been completed. Additional handling and logging have been added that will help diagnose these issues should they occur.

New columns have been added to the database to track the last update time and the user responsible for modifications to data connections, categories, and charts.

Added an option to enable Java Agent in order to collect and export telemetry data (metrics, traces, logs) for observability and performance monitoring.

Java Agent can be configured through the following environment variables:

• PI_TOMCAT_MONITORING_ENABLED

• PI_TOMCAT_MONITORING_OTLP_EXPORTER_ENDPOINT

• PI_TOMCAT_MONITORING_OTLP_EXPORTER_PROTOCOL

• PI_TOMCAT_MONITORING_SERVICE_NAME

Find more info about the new environment variables - /wiki/spaces/DEV/pages/2010218497

This can also be configured using configuration-tool gui:

Image Added

Further information and examples of the setup can be found in the following link - Monitoring - Using Java Agent

A new tab has been added to the data connections screen that allows you to configure an ssh tunnel.

Image Added

It includes:

1. A checkbox to allow you to include the SSH tunnel as part of your connection

2. The SSH user name

3. The tunnel that the port lives on

4. A field for the private key (note: this will not be visible once it has already been saved, will be encrypted, and will not be visible when accessing a data connection from the API, and will be hidden in the JSON export file)

5. A local port - you will need to set the port on the ‘details’ tab to be the same as this

6. A target port - where your database lives on the target system

7. A target host - here your database lives on the target system

If the checkbox is checked, and any fields are missing, you will not be allowed to save the data connection, and will be presented with a warning on the inputs which are missing.

Image Added

If the connection is successful, and you are using the SSH tunnel, an additional indicator will be included on the details tab to confirm this.

Image Added

You can only have one SSH tunnel per data connection. And each tunnel port must be unique to the system.

The SSH tunnel will be instantiated on data connection save, and will persist until you save it again with the box un-checked. A tunnel will also be created briefly upon introspection. All relevant tunnels will also be created on system start up.

All of these fields have been added to the API for you to set.

A thread will run in the background every 10 minutes to check for any closed connections, and re-open them again if they have failed.

You can set the ssh private key with a global variable, this is the only variable support we currently have for this feature. Only secure variables are supported.

Initial steps into moving away from bundling all of the supported drivers and instead having many of them be downloaded only for those who are using them. This functionality has only been applied to the ClickHouse and SQLite JDBC drivers in this release.

Alongside the other driver directories there is a new directory named ‘dynamic_drivers’. This directory contains a JSON file that holds details related to the supported versions of the aforementioned drivers - here is the ClickHouse entry as an example:

Image Added

This block of JSON details the files that are needed when using a connection via the listed Driver Class Path - in this case it is both the JDBC JAR and an accompanying compression library. In this case, the dynamic downloading of these files occurs if they do not already exist in the ‘dynamic_drivers/com.clickhouse.jdbc.ClickHouseDriver’ directory or fail validation due to a SHA-256 mismatch:

• On startup ONLY if you have a ClickHouse Data Connection defined

• When you Introspect or Save a ClickHouse Data Connection

• When you try to load a Chart that uses a ClickHouse Data Connection

• Via a thread that runs every 3 minutes to sync defined Data Connections and their Dynamic Drivers if applicable