Skip to content

Version 26.09.1.0

What's new

Limits by user roles in enterprise licenses

An enterprise license can now state how many people of each kind are allowed to work in the product. Users are split into two types by their global role: superadmins, company administrators, project managers and developers count as developers, while analysts and viewers count as analysts. A license sets a separate maximum for each type, and either of them may be left unlimited. When a limit is reached, adding a new user — or changing someone's role to one that requires the exhausted type — is blocked with a message explaining which limit stands in the way. The license details dialog now shows the current number of users against the allowed maximum for both types, marks each one as within the limit, at the limit or exceeded, and the license itself gains a "Suspended" state that names exactly which limits are over.

Fact tables and relationships in RMD import

Importing an RMD from a file can now bring in the project's fact tables and their relationships with dimension groups, so there is no need to recreate all of that by hand afterwards. The options are available in every project and every version, no matter which RMD tab the import was started from, and they follow the same permissions as the rest of the import. In Excel files the worksheets named "Fact tables" and "Relationships" are matched automatically; in CSV files they are chosen the same way as the other RMD data. The wizard gained the matching column-selection steps and two new tabs on the "Verify and import" step, built like the corresponding RMD tabs, with the same search, sorting and the option to show only the columns selected for import. Rows that cannot be imported — fact tables with duplicate or invalid names, relationships whose fact table or dimension group does not exist — are reported with a warning and left out, so only valid data is loaded. On finish, the fact tables are created, the measures, dimensions, facts and dimension groups are assigned to them, and the relationships are configured exactly as shown on the verification step. Import also became more predictable in general: cells that the imported file does not cover are now cleared instead of keeping their previous values, so the result no longer mixes new data with leftovers of the old.

Period-based functions in formulas

Four new functions make it possible to calculate stock and inventory measures correctly: PERIODDAYS and ACTIVEDAYS return the length of a period and the number of days with activity in it, while OPENINGVALUE and CLOSINGVALUE return the value at the beginning and at the end of a period. They can be typed in the formula editor and picked in the visual formula builder, where PERIODDAYS and ACTIVEDAYS joined the "Date & Time" category and OPENINGVALUE and CLOSINGVALUE the "Range" category; selecting a function block shows its description, the current formula and the number of arguments it expects. Formulas are validated as they are written — the number of parameters is checked, and so is the requirement that the referenced dimension is a date field — and the visual and text representations stay in step with each other. The new functions are translated into SQL for all supported databases and are carried through the API and through export and import of project versions.

Data mart view orchestration

Data mart objects created in a database are now managed by the product instead of being kept up to date by hand. Every deployed object carries a lifecycle status — not deployed, active, deploying, updating, stale or error — shown both in the data mart list and on the data mart screen, with the database error text available when something goes wrong and a progress state while an object is being deployed or updated. When a change in the project makes a deployed object no longer match the current model, the product marks it as diverged and offers to bring it back in line; users who manage views can also recreate an object manually from a confirmation dialog. Every deployment, update and refresh is written to a deployment history that can be reviewed per data mart. For materialized views and tables there is now a refresh configuration: full, scheduled, on-demand or incremental, with a schedule editor, pause and resume, the next planned run, the time of the last refresh and the mode that was actually used. Incremental refresh reloads only the changed data on the databases that support it — PostgreSQL and ClickHouse for materialized views and tables, Microsoft SQL Server for tables — and the interface explains why the option is unavailable elsewhere. When an event-based update rule with incremental refresh recreates a table whose only change is a different set of columns, the table is altered in place and keeps its data, access rights and refresh state instead of being dropped and created again. Updates driven by rules are dispatched in small groups with pauses between them, and the number of operations running at the same time against one database is capped, so the target database is not overloaded. Finally, when the data source has the transfer of access rights enabled — it is off by default — the access rights of the source tables are carried over to the deployed object: table and column grants, row-level security policies, masking rules and role assignments are read from the database and combined so that the object grants only what all of its sources allow. Before deploying, a preview shows who will get access, which columns will be hidden or masked and which policies will be applied, warns when a rule has to deny access to a group of users, and blocks configurations that cannot be secured.

User-based database access control

Database credentials are now configured separately from the connections that use them, in a new "data source" object that holds the address, the database and schema, the SSL settings and the service account. Each data source chooses how users reach the database: with one shared account, as before, or with each person's own credentials. In the second mode the administrator picks where those credentials come from — entered manually in the product, taken from a credential vault, or obtained through LDAP bind — and may allow a fallback to the shared account when a user has none of their own. Personal credentials are managed on a dedicated screen, where an administrator adds, edits, checks and removes the mapping between a product user and a database login; they are stored encrypted, and only the login is ever shown. When a user previews a measure or a data mart, the query is executed under their own database credentials, so the database applies that person's own permissions and nobody sees more than they are supposed to. All existing connections have been migrated to data sources automatically, so nothing needs to be reconfigured, and credential-related events are recorded in the audit log.

A single API version for all endpoints

The public API now offers one version and one connection format for everything. The data mart and connection endpoints that used to exist only in the first version are available under /df-api/v2/ as well, so an integration no longer has to mix two base paths and two sets of conventions in the same script. The new endpoints behave like the rest of v2: authentication with an API key in the X-Api-Key header, access limited to the projects the key owner may open in the interface — with projects the caller cannot see reported simply as not found — pagination, search and filtering on list requests, a language parameter for localized values, and request rate limiting. Data marts and connections cannot be created or deleted through the API — the only setting that can be changed is the incremental refresh configuration of a deployed data mart object — and every endpoint is documented with full request and response examples.

Git export and import through the API

Exporting and importing project versions through Git, until now available only in the interface, can be done through the API as well, so they can be built into a CI/CD pipeline. A project version can be exported into a Git repository as a commit or downloaded as a file archive, and a version can be imported back from a repository — from the latest commit or from a specific one — or from an uploaded archive. Separate validate and preview requests perform a dry run first: they report conflicts, missing references and other warnings without changing anything, which makes it possible to gate a merge request on a clean validation. Saved Git connections are managed through the API too — listed, created, updated, tested and deleted — so credentials do not have to be repeated in every call; authentication with a personal access token, an SSH key or a username and password is supported for one-off calls. Permissions match the interface: exporting requires the analyst role or higher, importing the developer role or higher. Ready-to-use pipeline examples for GitLab CI and GitHub Actions, together with the list of required variables and advice on handling validation errors, are published in the documentation.

Improvements and bug fixes

  • Deleting a column in the RMD now clears the whole column however many rows it has, and undoing the deletion restores all of it (IMP-3011)
  • The RMD spreadsheet feels noticeably more responsive: it no longer redraws itself while nobody is working in it, the highlight of the active cell follows clicks smoothly, and undo and redo are applied straight away instead of waiting for the grid to reload (IMP-3094, IMP-3095, IMP-3096)
  • Cutting cells with Ctrl+X works again in the RMD (IMP-3011)
  • Change history opened from a single cell is now filtered by the element rather than by that one cell (IMP-2989)
  • Measures created inside fact tables and data marts are now recorded in the change history (IMP-3010)
  • A formula that refers to a fact by name before that fact exists now starts working as soon as the fact is created — the reference is resolved automatically instead of staying broken until the formula is saved again (IMP-2870)
  • The "Measures" tab of a fact table again shows the "Block", "Display data type" and "Measure restrictions" columns (IMP-2997)
  • The "Measures" tab of a fact table now opens even when a measure has no formula (IMP-3071)
  • Elements on the configuration screen of a data mart load faster (IMP-2713)
  • Tooltips no longer freeze when elements are added to a data mart from the configuration screen (IMP-2918)
  • In transposed data marts the fact field no longer jumps in front of overlapping blocks, and the "Measures details" block stays where it is placed (IMP-2999)
  • The "Save changes" button works after the last fact table is removed from the data mart canvas (IMP-3068)
  • Data mart views are included in impact analysis even when they were created in a different database or schema than the one set in the connection (IMP-2917)
  • In transposed data marts on ClickHouse, the "Denominator value" field of simple common measures now gets the same data type as the other measures, so the resulting view can be processed normally (IMP-3070)
  • Analysts again see the button for editing a data mart from inside the data mart and the button for managing its database view (IMP-2987)
  • Large and expandable dialogs across the application now share a single standard size (IMP-2853)
  • OAuth authorization of GitLab and GitHub Git connections now works behind the reverse proxy of an on-premises installation; the repository URL (https) has to be entered before authorizing, and an SSH address cannot be used with OAuth (IMP-3069)
  • Connected sources returned by the API now include the connection name, matching the structure used by RMD export and import (IMP-2985)
  • The API now applies the same role restrictions and name validation as the interface when projects and versions are created or renamed (IMP-2984)
  • The API now answers "not found" instead of an error when a resource identifier is out of the allowed range (IMP-2906)
  • The combined RMD request of the API returns all measures, dimensions and facts instead of only the first twenty (IMP-3053)
  • The API now returns the measure restrictions, variation and "responsible for data" values that were missing from its responses (IMP-3054)
  • The system journal of a company is available only to the administrators of that company; a superadministrator keeps access to the journals of all companies (IMP-3000)