Viewing a report with cached report bursting
Security in a report is a kind of privileged control. JReport supports cached report bursting which creates a security mechanism for controlling access to the report. By defining which groups of data are available to which users, groups, or roles, report results are created for each user, role and group. When a user accesses the report result, JReport checks the user, group and role of the user and merges the groups of data in the report the user is authorized to see and displays it to the user. Cached report bursting is implemented with these security properties on the group panel: Cascade, Grant, Groups, and Roles. The feature enables different users to view different data groups according to their access privileges. It also applies to nested groups.
This section focuses on how to view and schedule a report that has cached report bursting with JReport Server. For detailed descriptions about setting up cached report bursting in reports, see Cached Report Bursting in the JReport Designer User's Guide.
Since the control of report access is not possible without a user ID, the significance of this function is only apparent after reports have been published to JReport Server and users access it using their JReport User ID (security identifier).
When a client views a report with cached report bursting in JReport Server, the corresponding groups will be displayed according to the security identifier. You can also advanced run reports with cached report bursting in different formats, including Page Report, HTML, PDF, TEXT, Excel, PS, XML and Rich Text Format (this feature does not support the RST and Applet formats).
To view a report with cached report bursting in JReport Server, the report must first be published to the server from JReport Designer. For example, if in JReport Designer, the security for a report that is grouped by the Customer_Region field has been set as follows:
Then,
Note: When designing the report in JReport Designer, if the Cascade property is set to be false, the specified group will only display its group header and footer.
You can schedule a report with cached report bursting as a normal report. However, there are some differences between the formats in which the report is to be published.
When you schedule a task to publish a report with cached report bursting to the HTML and/or Page Report Result formats to the versioning system, the scheduled result depends on the mode which is controlled by the property server.enable.cachedreportbursting in server.properties in <install_root>\bin
:
server.enable.cachedreportbursting=true
which is the default, JReport will create a report result with the report data for all possible users. This allows the report to run with a single query to the DBMS to create the report for all users in one pass. It is similar to report bursting, however, report bursting does not support the Page Report Result format and it makes a separate physical report result for each user and the administrator needs to manually restrict access to the result. When a user views the report result using cached report bursting, JReport Server will use the security identifier of the user to restrict access to the data in the report to the specific groups the security identifier is allowed to view. The end result is the same as the bursting report in that the user sees only his data, the advantage to the administrator is there is only one version result to manage. Users can perform interactive actions on the scheduled page report result as on other page report result, and the formulas, summaries and other similar data will be recalculated based on the privileged data.
Note: If the report is cached report bursting and RLS/CLS mixed, then when other users other than the user who did the scheduling view the scheduled HTML result, a blank page is displayed.
server.enable.cachedreportbursting=false
, the scheduled result only contains the data that the user who did the scheduling is allowed to see. This is primarily for compatibility with pre-8.2 versions of JReport. In this case, "to page report result" is not supported. When you schedule a report with cached report bursting to publish it to e-mail, there is a slight difference. JReport Server supports a multiple mail feature which enables sending the data result directly to each user who is authorized to view the report.
Assuming that the catalog and the report have been published to JReport Server, and two users admin and jennifer both have the permission to view the report. The following procedure shows how to schedule a task on a report with cached report bursting to be published to e-mail.
JReport Server will get the e-mail addresses from the user accounts, and then send the report result to admin and jennifer, with the contents in accord with their access right to the report.
Note: Before publishing to e-mail, make sure you have input the e-mail addresses of the users when configuring JReport Server. To do this:
When scheduling a report with cached report bursting to other formats, the scheduled result only contains the report data that the user who does the schedule is allowed to see. All users will see the same data as the scheduling person.
Sometimes, sending pertinent report data to corresponding mail recipients is required. JReport Server allows you to send a scheduled report result to the e-mail addresses accordingly, based on the cached report bursting settings of the report and the user information stored in JReport Server (for example, e-mail address information). Therefore, each recipient will only be able to view certain parts of the report data. However, using e-mail information of server users is not reliable, since a user ID that is appropriate for the report doesn't always exist in JReport Server. In cases like this, the mails will not be sent successfully. The best way to resolve this is to use an external e-mail information source by implementing the UserMailList and UserMailListFactory API that JReport provides.
JReport provides two interfaces for you to retrieve user and e-mail information from a customized source:
You can implement multiple classes of interface UserMailList. Each of them may refer to a particular report. By using the getInstance() method in the jet.server.api.UserMailListFactory interface, you can get one implementation of the UserMailList. For more information on these two interfaces, see JReport Server API Documentation.
The following is a simple example:
@"Customer Name";
This means that only the records of the specified group will be shown at runtime when you enter with different IDs -- Customer Name, in this example.
|
|
In this case, the parameter should be -Dcom.jinfonet.mailListFactory=DemoUserMailListFactoryImpl.
The report will be processed and sent to the corresponding recipients with pertinent report data.