Skip to main content
Version: 1.36.0

Version 1.36.0

In this version, we made file handling more secure and authorization more reliable when integrating with external systems. Access to files in cloud storage is now better protected, and users can keep working during long sessions without having to log in again. We also updated the reporting technology to reduce the cost of using commercial components.

We have also improved working with lists. Now you can:

  • set custom headers for columns added through dot-walking;
  • share links to lists with applied filters.

In addition, we strengthened login protection, updated third-party components, and fixed issues with installing large packages, as well as errors in indications and list filtering.

New functionality​

Secure access to attachments and images​

Attachments and images are now uploaded and downloaded through a dedicated platform service. Client applications no longer access the file storage directly, and internal storage addresses are hidden. Access control list (ACL) is checked when users view and download attachments.

Key features:

  • The Download all action creates an archive even if some files fail to download. For each such file, the archive contains an additional file named after the original file with the error text.
  • Attachments are viewed and downloaded after an ACL check. Public attachments are available without authorization.
  • All new attachments are stored in the private attachment/ storage by default.

To manage the ACL verification, we added the platform.attachments.acl.enabled system property to the file access service. The property is enabled by default.

Basic authorization token rotation​

We added the new rotateToken() method to the SimpleSession class. The method extends a session seamlessly, without re-authentication. Authorized users can call the method through the Scripted REST API.

When rotateToken() is called, the system checks that the user is authenticated, the current token is valid, and the time left until the token expires does not exceed the value of the simple.session.token_rotation_window system property. If all checks pass, the system generates a new token, binds it to the same session, revokes the old token in the API Gateway, and sets the new token in the auth cookie.

Use the simple.session.token_rotation_window system property to define the interval in seconds before the token expires during which rotation is allowed. The value must be a positive integer that does not exceed PHP_INT_MAX. The default value is 3600 seconds (60 minutes).

Improvements​

Custom titles in lists​

System administrators can now set custom titles for columns added to a list view through dot-walking. This makes lists easier to read and lets you set list columns titles that accurately reflect their content. If no custom title is set, the list uses the title of the last field in the chain. An icon is displayed to the left of the title. Click it to open a tooltip with the full path to the field and copy the path. When you export a list to XLSX, the custom titles are used if they are set; otherwise, the system titles are used.

Custom titles are stored in the new Custom title column of the List Columns (sys_ui_list_column) table. Only users with the admin role can edit this column.

Read more in the List Layout article.

filter_id parameter in list URLs​

We added the filter_id parameter to URLs of the table record lists. With this parameter, you can share links to table record lists with a saved filter applied. When a user opens a link with the filter_id parameter, the matching filter is applied to the list and displayed in the filter selection field of the condition builder.

If a URL contains both filter_id and condition, the condition parameter is ignored. When you select a saved filter in the condition builder, the filter_id parameter is automatically added to the URL. If you change the filter conditions without saving them and click Apply, the filter_id parameter is removed from the URL and replaced with an updated condition parameter.

Indication recalculation limit configured through a system property​

The SLA module now supports the slm.calculation.max.actual_elapsed_percentage system property. Administrators can use it to set the maximum breach percentage for automatic indication recalculation. The system keeps recalculating indication values until the specified percentage is reached. The default value is 1100%.

System improvements​

Versioned tables​

The Report Type (sys_report_type) and Report Type Category (sys_report_type_category) tables are now versioned.

Rescheduled indication recalculation​

We added a mechanism that adjusts the time of the next indication recalculation after the Indication Calculator microservice resumes operation, for example, after an update or a technical failure. The mechanism moves recalculations to an earlier or later time to spread the processing of indications accumulated during the downtime more evenly and avoid excessive system load.

ECharts for report visualization​

In the report visualization engine, we replaced the proprietary Highcharts.js library with the open-source ECharts library. This change improves report stability and makes further development of reports easier. All existing visualization types are displayed correctly, and the ways users interact with visualizations remain the same. Previously created reports continue to work as before.

Fixes​

Security​

  • DEF0023378: Strengthened the validation of identity provider responses during SAML (SSO) login. If SAML login is configured on your instance, we recommend installing this update as a priority.
  • DEF0022591: Updated third-party components in the frontend/spa-frontend image to close known vulnerabilities from vendor bulletins.
  • DEF0022579: Updated third-party components in the kafka/simple-cp-schema-registry image to close known vulnerabilities from vendor bulletins.
  • DEF0020123: Fixed an issue where unavailable records, including vendor records, could be exported through the JSON export. The export now performs an ACL check and includes only the records that the user can read.

To get the list of fixed vulnerabilities, contact the support team.

Availability and updates​

  • DEF0022750: The token in the auth cookie was not refreshed during authorization through Keycloak. The issue occurred when an invalid token was provided, which caused a redirect loop between the instance URI and the /auth-sso/keycloak page. Now the invalid authorization cookie is deleted, and the token is refreshed.

Data integrity​

  • DEF0022713: When generating outgoing emails, including meeting invitations (iCalendar), the platform could not use the Content type (content_type) field of the Email (sys_email) table because the field had been deleted in previous versions. The field has been restored, and its length limit has been removed.
  • DEF0022120: A GET request to a List field through dot-walking returned an exception if the field contained more than one record. The error occurred because the dwaRecordId parameter passed to the class constructor for a List column contained a string with a list of ID (sys_id) values instead of the expected integer. The issue has been fixed in this version.
  • DEF0020622: Filtering records through dot-walking by reference fields returned the "Invalid attribute in condition" error. The issue was caused by a record being passed to the ACL service incorrectly when the table was updated in GetReferenceValueService. In this version, the ACL mechanism has been extended, and record search with filters works correctly.
  • DEF0016612: The filter by list values compared the whole string instead of its separate values, so the result depended on the order of the values. For example, if the Participants field contained Smith, Jones, a filter with the has operator and the Jones, Smith value did not find the record, while for the Jones, Smith field value it did. Now the values are compared separately. The contains (dynamic) and does not contain (dynamic) operators now take into account all values of the dynamic filter, not only the first one.

Indicators and indications​

  • DEF0022221: Indication records were not created if the indicator conditions used the changes operator to trigger them. The issue occurred because, for a new record, the previous parameter was filled with the current state from the database. As a result, it matched current, and the changes operator did not trigger. In this version, the indication mechanism has been fixed.
  • DEF0018802: For indicators with the "Created at before [past date]" condition, indications were also created for records with a later date. The issue was related to the format of dates passed in requests from the microservice to condition-api. In this version, indication records are created correctly.