Release Notes for ReportServer 4.5.0

These release notes reflect the changes with respect to ReportServer RS4.4.0-6084.

• Some Important Features and Noteworthy Improvements
• Script cache
• Using classes in nested scripts
• Allow to disable LDAP
• Analyzing the LDAP schema
• Analyzing the LDAP filter
• Best-effort LDAP GUID guess
• Displaying any LDAP attribute value
• Displaying LDAP orphans
• Removal of LDAP allowLocalUsers configuration setting
• Configurable error logging when report execution fails
• Add environment information
• "Admin Panel" system console
• New Features, Improvements and Bug Fixes for RS4.5.0-6085
• New Features, Improvements and Bug Fixes for RS4.5.0-6086
• New Features, Improvements and Bug Fixes for RS4.5.0-6087
• New Features, Improvements and Bug Fixes for RS4.5.0-6088
• New Features, Improvements and Bug Fixes for RS4.5.0-6089
• New Features, Improvements and Bug Fixes for RS4.5.0-6093
• New Features, Improvements and Bug Fixes for RS4.5.0-6095
• New Features, Improvements and Bug Fixes for RS4.5.0-6097
• New Features, Improvements and Bug Fixes for RS4.5.0-6099

Some Important Features and Noteworthy Improvements for ReportServer RS4.5.0

Script cache

In ReportServer 4.5.0, we improved the internal script caching mechanisms. We also added a "clearInternalScriptCache" terminal command for manually clearing the scripting caches. Note that this is available as a service method as well: net.datenwerke.rs.scripting.service.scripting.ScriptingService.clearCache()

You can control scripting cache settings in the cache section of the the scripting/scripting.cf configuration file. The default file is shown below.

Using classes in nested scripts

When you need to use classes in nested scripts, you cannot use GLOBALS.exec():

GLOBALS.exec('lib.groovy')

With other words, this would not work if B contains a class definition:

GLOBALS.exec('/fileserver/bin/B.groovy')
def b = new B()
b.prepareString()

Groovy would try to compile your script, but cannot find B’s class definition during compilation time.

In this case, you can use the new methods GLOBALS.loadClass() and GLOBALS.loadClasses() for loading your class definitions. Using the new method GLOBALS.newInstance() allows you to create instances as shown below. Finally, you can call your instance’s methods, in this example prepareString().

def bClass = GLOBALS.loadClass('B.groovy', 'net.datenwerke.rs.samples.tools.nesting.nestedclass.B')
def bInstance = GLOBALS.newInstance(bClass)
return bInstance.prepareString()"

Examples can be found here and here.

Allow to disable LDAP

You can now disable LDAP completely if you don't need it. This is done in the ldap.cf configuration file with the "disabled" configuration option.

The default ldap.cf configuration file is shown below:

Analyzing the LDAP schema

Often it is useful to be able to explore and analyze your LDAP server, e.g. when not all attributes/object classes are known on beforehand. For this purpose, we implemented a new "ldapschema" terminal command and also extended the "ldaptest users", "ldaptest groups" and "ldaptest organizationalUnits" with a "-s" (schema) flag. This allows you to display the object class schema attributes and properties.

While the "-s" flag allows you to explore the installed object class types of your users', OUs' and groups' object classes, the "ldapschema" allows you to explore any object class.

An example is shown below.

Shows the schema of the users' object class:

In the screenshot above we see that the user's class is "inetOrgPerson" and the parent's user's class is "organizationalPerson".

We may explore the "organizationalPerson" object class as shown below.

We may continue exploring the LDAP schemas until the top-most object class: "top":

We may list all object classes available:

We may list also all attributes available:

And analyze the attributes:

Information about the LDAP server can be fetched as follows:

Analyzing the LDAP filter

You can use the "ldapfilter" terminal command for showing the installed LDAP filter in a multi-line form that makes it easier to understand its hierarchy and embedded components. The command also tries to simplify the installed LDAP filter in certain ways (for example, by removing unnecessary levels of hierarchy, like an OR embedded in another OR).

Best-effort LDAP GUID guess

Often, while configuring the LDAP configuration file sso/ldap.cf, the needed GUID is not known on-beforehand. As all LDAP installations may use a different GUID, you normally have to check with your LDAP administrator for the appropriate GUID. ReportServer 4.5.0 adds a best-effort GUID guess with the "ldapguid" terminal command:

The command above shows that the currently installed GUID in sso/ldap.cf is "objectGUID", which should probably be changed to "entryUUID", as ReportServer found this GUID in your LDAP installation.

Displaying any LDAP attribute value

ReportServer 4.5.0 allows you to request and display any additional LDAP attribute via the "ldaptest" terminal commands' "-a" flag. The additional attributes must be entered in a ;-separated manner.

E.g. in order to display the "mail", "member" and "ou" attribute values of each "ldaptest filter" entry, you can enter the following:

In order to display the "memberOf" attribute value of each "ldaptest users" entry, you can enter the following:

Note that this flag is available in all "ldaptest" subcommands.

Displaying LDAP orphans

Your LDAP filter should return all (and only!) your users, groups and organizational units. If more nodes are returned, or if the mappings in ldap.cf are not correct, nodes are returned that can not be mapped to a user, a group or an organizational unit. These are called LDAP orphans. In a correct installation and configuration, there should not be any LDAP orphans. Thus, you get LDAP orphans when you return "to much" from your LDAP filter. You can easily list all LDAP orphans with the new "ldaptest orphans" terminal command.

Removal of LDAP allowLocalUsers configuration setting

The old "allowLocalUsers" setting was removed as of ReportServer 4.5.0. Instead, you should use colon-separated PAMs in your reportserver.properties as explained in the Script Guide (Custom Authenticators PAMs) if you need to allow/disallow local users to log-in.

E.g. the following setting allows only LDAP users:

rs.authenticator.pams = net.datenwerke.rs.ldap.service.ldap.pam.LdapPAM

while the following setting allows both LDAP and local users:

rs.authenticator.pams = net.datenwerke.rs.ldap.service.ldap.pam.LdapPAM:net.datenwerke.rs.authenticator.service.pam.UserPasswordPAM

The default ldap.cf configuration file is shown below:

Configurable error logging when report execution fails

ReportServer now logs report detailed information when a report execution fails. Refer to the screenshots below.

The exact information to be logged may be configured in the main/error-log.cf configuration file. The complete default configuration is shown below.

Add environment information

Some environment information was added in ReportServer 4.5.0, e.g. SSL information, static PAMs, Groovy version, DB Configuration, as you can see in the following screenshot:

"Admin Panel" system console

ReportServer has now a new "Admin Panel" system console which allows easy access to administration functionality as shown in the screenshot below.

New Features, Improvements and Bug Fixes for ReportServer RS4.5.0-6085

New Features, Improvements and Bug Fixes for ReportServer RS4.5.0-6086

New Features, Improvements and Bug Fixes for ReportServer RS4.5.0-6087

New Features, Improvements and Bug Fixes for ReportServer RS4.5.0-6088

New Features, Improvements and Bug Fixes for ReportServer RS4.5.0-6089

New Features, Improvements and Bug Fixes for ReportServer RS4.5.0-6093

New Features, Improvements and Bug Fixes for ReportServer RS4.5.0-6095

New Features, Improvements and Bug Fixes for ReportServer RS4.5.0-6097

New Features, Improvements and Bug Fixes for ReportServer RS4.5.0-6099