Report Configuration

Reports are defined as platform properties consumed by the reporting service at runtime. Each report has a unique report ID and a property value that specifies the query type, data source, and query to execute. You can override any report definition for a specific tenant without affecting the global default.

Prerequisites

• Access to the Eclipse platform property store (via Admin Portal or API)
• A valid database connection name configured in the reporting service

Report Definition Format

Reports are stored as platform properties under the reporting.config namespace. The property value is a comma-separated string in the format:

<type>,<connectionName>,<query>

Report types

SQL and PNGW report format

sql,<connectionName>,<sql query>

Example:

sql,eclipse-db,SELECT wallet_id, balance, currency FROM wallet WHERE tenant_id = <tenantId> AND created >= ?D1?

Postilion (PB) report format

pb,<serviceName>,<commandId>

Property Keys

Report definition

Execution tuning

Query Parameters and Template Variables

Report SQL queries support two types of runtime substitution.

Template variables (server-resolved)

These are replaced by the reporting service before the query executes.

Typed placeholders (caller-supplied)

Callers pass values via query parameters on the report API call. The service binds them to the SQL as prepared statement parameters.

Example query using both:

SELECT * FROM payment
WHERE tenant_id = <tenantId>
  AND status = ?S1?
  AND created >= ?D1?
  AND created < ?D2?
  AND amount >= ?N1?

Access Control

The reporting service decides whether a caller can run a given report by working through a fixed sequence of checks. The first check that matches wins — nothing later in the sequence is consulted once access has been granted.

Two of these checks are things you configure per report — the per-report override and, indirectly, how you name the report ID. The rest are fixed platform behaviour. The next two sections cover each in turn, including a gotcha where they interact.

Per-report permission override

To restrict a specific report to a named set of roles or positions, set the following tenant config item:

Report.<reportId>.READ.Allowed = GLOBAL_ADMIN,INSTITUTION_ADMIN

The value is a comma-delimited list of role or position names. Anyone holding one of those roles can execute the report — but see Report/Dashboard prefix default below: for a report ID starting with Report or Dashboard, this list is not the full story.

Report/Dashboard prefix default

Any report whose report ID starts with Report or Dashboard — the match is case-sensitive, so a report ID starting with lower-case report does not qualify — is also accessible to a fixed set of default roles, on top of whatever the per-report override says:

⚠️

A per-report override does not lock these roles out

The per-report override is checked first (step 2 in the table above), but if the caller's role isn't on that list, the service falls through to this prefix default (step 3) — and a caller holding any role from the table above is still granted access, regardless of what the override says. Narrowing Report.<reportId>.READ.Allowed does not exclude these roles for a report ID starting with Report or Dashboard.

To fully restrict a report to a custom role list, avoid naming the report ID with a Report or Dashboard prefix. If the report ID must use one of those prefixes, treat the table above as part of that report's effective audience, not just the roles named in the override.

Post-Logic Handlers

After a report executes, the service invokes a configurable post-logic handler. The default handler is a no-op. You can assign a custom implementation per report.