as many of you probably heard, the Spring framework has this critical security issue: CVE-2022-22965.
ReportServer is not affected by this as of ReportServer 3.1.1. All previous versions are affected and should be upgraded immediately. We recommend to upgrade to the current ReportServer version 4.1.0.
ReportServer 4.1.0 is now available for all users. It contains many new features, improvements and bug fixes. An overview of the most important are shown below.
Groovy 4 Support
ReportServer 4.1.0 now supports the newest Groovy 4.0.0 version, which contains many awesome new features and capabilities. Check the Groovy 4 release notes for details.
BIRT Upgrade
The BIRT libraries were upgraded to the newest version 4.9.0. More information can be found here.
“Write” permissions additionally needed for editing report variants
As of ReportServer 4.1.0, “Write” permissions are needed in able to edit, create or delete a report variant. Previously, only “Execute” permissions were needed.
Support sending dynamic list reports to Table Datasinks
Table datasinks allow you to send and/or schedule dynamic list reports into to a given table in any datasource supported by ReportServer. This allows you to easily transfer data from MySQL to Oracle, for example. The destination table must exist and must be compatible with the dynamic list, i.e. the fields must exist, have the same name, and have compatible data types.
Check permissions by via “haspermission” terminal command
As of ReportServer 4.1.0 you can check permissions via the new “haspermission” terminal command.
The command allows to check if a given user has a given permission on a given target. Returns “true” if the user has the permission, else “false”.
The -g flag allows to check generic permissions. Documentation of these including the exact target types you can enter can be found here.
For other objects, e.g. Users, Datasources, etc., you can check the entity types here.
The following example checks if the user with id “6” has “Execute” permission on the “AccessRsSecurityTarget” generic target, i.e. if the user is allowed to log in into ReportServer.
The following example checks if the user with id 115254 has “Read” permission on the datasource with id 144497.
Check is a table exists via “tableExists” terminal command
The “tableExists” terminal command allows you to check the existence of the “T_AGG_CUSTOMER” table as shown in the following example.
Check is a column list exists in a given table via “columnsExist” terminal command
The “columnsExist” terminal command allows you to check the existence of a column list (CUS_CITY, myColumn) in the “T_AGG_CUSTOMER” table as shown in the following example.
Fetch column metadata of a given table via “columnsMetadata” terminal command
The “columnsMetadata” allows you to fetch column metadata of the “T_AGG_CUSTOMER” table as shown in the following example.
Metadata documentation of the fields above can be found here. The first 8 columns are displayed by default and CHAR_OCTET_LENGTH is an optional column in the example above. You can choose to append any number of the listed column-description columns by passing their name as an argument.
Advanced: Fetch any datasource metadata via “datasourceMetadata” terminal command
The “datasourceMetadata” command is a very powerful command that allows you to dynamically call any method of the DatabaseMetaData interface.
There are any number of applications for this. You will need to specify the datasource you want to access, the name of the method you want to execute and its parameters. The command will look up a method matching the name and argument count. If there is exactly one matching method it will be executed.
Arguments passed are converted into the expected parameter types as need. Supplying the String “null” will evaluate to null as an Object. Examples:
Lookup JDBC minor/major version and driver
Fetch column metadata similar to the columnsMetadata example
Fetch information about your datasource with via “info datasource” terminal command
Now you will be able to display some selected meta-data about your datasource from within the terminal. It features 4 sections: general information, url information, functions section and supports section. If you require more information still, use the “datasourceMetadata” terminal command as mentioned here.
Example:
Note that this information is also available in the new datasource information window as shown in the following screenshots.
Include internal datasource information on “env” terminal command and “General Info” System Console
The “env” terminal command now includes information on your internal datasource. Note that this internal datasource has to be set in the /fileserver/etc/datasources/internaldb.cf configuration file.
Terminal operators >, >> and >>>
All terminal command results can now be redirected either to a file in the internal ReportServer filesystem (> for new files and >> for appending results), or to an existing datasink (>>>). In such way, you can send long command results per email, OneDrive – SharePoint (O365), etc.
Test LDAP configuration via “ldaptest” terminal command
You can now test your LDAP configuration with the new “ldaptest” terminal command and its subcommands as shown in the examples below.
ldaptest filter
ldaptest users
ldaptest groups
ldaptest organisationalUnits
The following screenshot shows the corresponding “ldapimport” results:
Find the base root of a onedrive-drive belonging to a group via “onedrive” terminal command
The “onedrive” terminal command allows you to access some onedrive api functions from within ReportServer. As of now it has the following commands: onedrive group getmygroups & onedrive group getdrivesof.
The following example shows how to acquire a driveId of group you belong to in order to configure the baseroot of a onedrive datasink.
Use onedrive group getmygroups to see which groups you belong to
Use the groupId of the group to acquire its drives with onedrive group getdrives of
Use the driveId to configure the baseroot of the datasink as such /drives/your-driveid/root:
Allow to test the SSL configuration via “ssltest” terminal command
The “ssltest” command allows you to test your SSL configuration as shown in the screenshot below.
In case you installed a server’s certificate, for example for LDAPS or LDAP StartTLS, this command is useful for testing the installed certificate analogously to the following: “ssltest ipOrHostOfYourServer 10389”
The 3.1.0-6056 version is now available for all users.
It contains new features, bugfixes and improvements of the 3.1.0 version. For a list of all changes please refer to the release notes. The upgrade guide is available in the documentation area. Happy reporting!
ReportServer 4.0.0 is now available for all users. It contains many new features, improvements and bug fixes. An overview of the most important are shown below.
Library upgrades
Note that as of ReportServer 4.0.0, Java 11 JRE or later is required.
Note that as of ReportServer 4.0.0, legacy JXLS1 is not further supported.
The following important libraries are upgraded in ReportServer 4.0.0:
Hibernate: upgraded to 5.6.3.Final
c3p0: upgraded to 0.9.5.5
These libraries basically manage and control the ReportServer’s metadata database and its connection pools.
Numerous other libraries were upgraded. Refer to the release notes table below for details.
79 libraries were upgraded
22 libraries were removed
18 libraries were added
LDAP support including StartTLS and LDAPS
As of ReportServer 4.0.0 you can use the new “ldapimport” terminal command together with the sso/ldap.cf configuration file in order to manually import LDAP users. For scheduling the functionality periodically, you can use the script found here and schedule it via “scheduleScript”.
Note that encryption is also supported. Both StartTLS (recommended) and SSL (LDAPS) are supported.
Details on configuration options are available in the Configuration Guide. The default sso/ldap.cf file is shown below.
Google Drive OAuth2-authorized datasinks allow you to send and/or schedule reports to a given directory in your Google Drive account.
For getting your “app key” and “secret key”, you have to create an app registration here (Google API Console) and give it the appropriate API permissions.
The “base root” path in the datasink definition, together with the “folder” path, determines the base path of the datasink. The default folder/folders are also included, which can be overriden in specific uses of this datasink, analogously to other datasink types.
Note that the base path must exist. If the (extension) folder/folders does/do not exist, it/they is/are created. If the report already exists in the same path, it is overwritten.
The path should be entered like this: “/my/path”. Note that, different as in other datasinks, “./my/path” does not work.
Support sending reports to Amazon S3 Datasinks
Google Drive OAuth2-authorized datasinks allow you to send and/or schedule reports to a given directory in your Amazon S3 bucket.
You can create an access and a secret key as described here (Amazon S3 access keys) and give it the appropriate API permissions. Further, the unique bucket name and region must be entered into the datasink definition.
If the report already exists in the same path, it is overwritten.
Box OAuth2-authorized datasinks allow you to send and/or schedule reports to a given directory in your Box account.
For getting your “app key” and “secret key”, you have to create an app registration here (Box Developer Console) and give it the appropriate API permissions.
The “base root” path in the datasink definition, together with the “folder” path, determines the base path of the datasink. The default folder/folders are also included, which can be overriden in specific uses of this datasink, analogously to other datasink types.
Note that the base path must exist. If the (extension) folder/folders does/do not exist, it/they is/are created. If the report already exists in the same path, it is overwritten.
The path should be entered like this: “/my/path”. Note that, different as in other datasinks, “./my/path” does not work.
Visualize live connection pool
As of ReportServer 4.0.0, you can create a live graph of the connection pool including the following:
Number of connections
Busy connections
Maximum pool size
Threads awaiting connection checkout
Unclosed orphaned connections
You can find and control the graph in the System Consoles section analogously as the “JVM Live Memory” system console. An example output is shown below.
You can also use the new “connPoolStats” terminal command for a static snapshot of the current connection state as shown in the following screenshot
Refactor ConfigService location
Note that the location of “ConfigService” changed, so your scripts using ConfigService must be adapted for them to work.
Default configuration files are created on first run of ReportServer. Later, when upgrading ReportServer to a newer version, it is probable that newly added configuration files are missing (i.e. all configuration files added between the version originally installed and the version upgraded to).
In order to find out which configuration files are missing without having to search all release notes between these versions, “showmissing” allows you to compare the current set of configuration files with the expected set of configuration files of the currently installed version. Then it shows all missing files.
With help of “createmissing”, you can create the default missing configuration files found with “showmissing” into the appropriate location inside your /fileserver/etc path.
For copying all default missing configuration files into a given folder you can use “createall”. This allows you to compare configuration file contents/fields, etc.
You can see examples below:
Support for database-independent table copying
As of ReportServer 4.0.0, copying the contents of a table to another table is supported database-independently, i.e. the tables may reside in different database types. E.g. you may copy the contents of a table from a MSSQL database to a table in an Oracle database. All datasource types supported by ReportServer are supported.
The destination table must exist and must contain the same fields as the source table. Their field types must be compatible.
The example copies the contents of the RS_SCHEMAINFO table of your internal datasource with id 58 into a table with name “myschemainfo” in the datasource with id 60.
Again, note this is database-independent. In the example above the datasource with id 58 is a MSSQL datasource, while the datasource with id 60 is an Oracle datasource.
The command prints some information for you to be able to see what is happening in the background. In the example above the information printed is:
Refer to the Admin Guide for more information on how to use this command.
Allow better browsing of dynamic list preview results
Dynamic list previews can now be browsed as shown in the following screenshot.
Allow to compress all reports before sending them or scheduling them to a datasink
Reports may now be compressed before being sent to any datasink. Please refer to the following screenshots:
Allow to send files in filesystem to datasinks
You can now send files in ReportServer’s virtual filesystem directly to your datasinks. Refer to the following screenshot.
Allow to print environment information to terminal
Prints environment information of the current installation including relevant environment variables.
Show user information including transitive groups of a given user
You can now use the “id” terminal command for printing including user information.
This includes group information and organizational unit information of a user. Group information includes direct and indirect groups (via another groups or via organizational units).
As an example refer to the following screenshot
The user “dmurphy” is member of 3 groups in the example:
Managers: the user is a direct member of this group
viaGroup: the user is a member of this group via another group.
viaOU: the user is a member of this group via an organizational unit.
Add “report_configuration” entry to audit logs
We added a new entry “report_configuration” which contains the configuration parameters, filters and prefilters. The data is saved in unformatted JSON format. A formatted example with some test parameters (OrderNumber), filters and prefilters is shown below.
Note that this audit log entry is available for all report values.
Also, note you can print all these values into your dynamic list Excel, HTML and PDF export documents as well via report properties.