Publishing a report can be a convenient way of sharing that report to other users, including those that may not have an account on the source instance which contains the data from which the report is derived. However, occasionally the final report rendered for these external users does not necessarily display the same for those external users as it does for internal users. This KB Article will describe some of the common sources of these discrepancies in the displayed, final report.
Causes and Resolutions
Thus, we will explore some of the most common causes of issues or data discrepancies in the use of published reports as well as possible methods of correction.
Fewer Rows than Expected Displayed in List Reports
One of the more common issues reported with published reports is that, in a List type report, fewer rows are appearing in the published version of the report for non-logged in users than is normally expected. A user logged in might see 100 rows in a list report, but when viewing the report URL when not logged in, that same user may see fewer or no rows at all. In these cases in which one or more rows have been removed from the report, a message will usually also appear indicating some number of groups removed from the list by security constraints.
For instance, a logged in user viewing a list report of active printers, might encounter the following view of the report:
However, this same user (or another user), if attempting to view the same report when not logged into the instance, but using the published report's public URL might display the following:
The cause for this issue is due to the fact that, in any List type report, each row is compared against the Read Access Control (ACL) record as defined on the table sources of the report. With the understanding that a public, anonymous user is considered to be logged in as the "guest" user, the ACL will then be consulted in the context of that guest user for these non logged-in users.
Thus, for this example List report the following ACL would be considered for each list row to be displayed in the report.
To correct this issue, a new ACL may need to be created (or an existing ACL record updated) that would provide the "guest" account access to the records that should be visible in the list report. The guest account coincides with the "public" role as found on the instance. Of course, as always, care must be taken to ensure that information that should not be shared with other users should not be displayed in a list report. Modifying or creating a new ACL record will require an admin account which has been elevated to security_admin.
Graphical Reports Showing Incomplete Data
Another fairly common issue reported with published reports is that a graphical type report (any non List type report) may show an incomplete set of data, in comparison to an actual user logged into the instance and viewing the same report.
This issue is caused by the fact that any Before Query Business Rules are performed on the data from the source table before a report is generated and rendered for it's viewers. Thus, if any such applicable Business Rules are found on the source table and limit the data based on permissions or similar criteria, any records that do not fulfill that criteria will not be considered for inclusion in the report. For an anonymous, unlogged in user, these rules will thus run in the context of a user with no groups or roles and will be evaluated thusly, which could result in "Guest" or anonymous users seeing a smaller subset of the original data displayed in the report.
For example, say we have a report "All Incidents by Category" on the instance that appears as follows:
We then publish the report and disseminate the URL to external viewers. However, upon viewing the report, these external viewers describe seeing a reduced version of that same report.
Investigating, we then find that the source table for this report, Incident, has a Before Query Business Rule associated with it that will run on the report data before display of the final report top the end user.
Thus, for this example, we find that the out-of-box Before Query Business Rule will only include data for which the current user, because the user is not part of the itil role, for records in which that user is either on the Watch List, was the Opener of the record or is the user in the Caller field for the record. Since an anonymous public user is considered as the "guest" user by the system, the Business Rule, for that user would only return records for which "guest" was on the Watch List, "guest" was the caller or "guest" was in the opened by field. Checking the actual data that is considered for this report, we find that there is exactly one record that fulfills those requirements for the guest user and is thus displayed in the public version of the report.
To correct this issue, we would then need to modify the applicable before query Business Rules on the table from which the data is gathered from in such a way to allow access to these "guest" users (or to allow access to all users). There are many ways this could be done from adjusting the condition such that the Business Rule would not apply to those in the "public" role, deactivating the business rule, or modifying the script thusly to not restrict access to these records.
Note also, that although this particular issue is described in terms of graphical type reports, these same Business Rules would also be applied to the rows returned in a List report. However, since these rows are often restricted by ACL's, which are usually more restrictive than a Business Rule, this issue is usually less common with those report types.
There are several important things that should be kept in mind regarding the usage of published reports:
Once a report is unpublished, the previous public URL will no longer be valid and accessing that URL (by any user, logged in or not) will result in a Page not found message.
If a user is still logged into the instance in another browser window, they will most probably see the report as per the logged in user vice the guest or public user. Thus, for testing purposes, the report creator will want to ensure to log out of the instance before accessing the URL to determine what will be displayed by non logged in users viewing the report.
How to Determine if an Existing Report is Published
It may be helpful to determine if a particular report is actually published or not. There are several ways to do this, including the following.
One method is to browse to Reports -> View / Run and click the appropriate tab (My reports, Group, Global, or All) which might include the report. Locate the report on the list. Reports which are currently published will display a blue circle with a checkmark in the "Published" column. Those that are not published will have no such distinction.
Alternatively, it can be quickly determined if a Report is published from the report record itself. Access the record for the report itself and open the report for viewing or editing.
A report that is currently published will display the "link" icon in the top menu bar for the report.
Another method to determine if a report is published is to open the report for viewing or editing and click the Sharing icon. A currently published report will contain an option titled Unpublish and a currently unpublished report will contain an option titled Publish. Note that a user must have the appropriate permissions to that report in order for these options to appear.
How to Determine the URL for a Published Report
Once a report has been published, it will also be necessary to obtain the unique URL for that report such that it can be distributed to public users for viewing. The URL can easily be obtained by opening the published report for editing or viewing. Once the record corresponding to the report record is shown on screen, the "link" icon in the report toolbar should be clicked. This will cause the full report URL to be copied into the local computer's clipboard. A brief message will also appear indicating that the URL has been copied into the computer's local memory.
This URL can then be emailed or otherwise distributed to the end users, including any individual who has access to the Public Internet.
The format of the URL thus generated will be as follows:
In which <instance_name> is the specific name of the instance from which the report was generated and <sys_id> is the unique System ID for that report record as found on that instance.
Any user browsing to that URL, while the report is thus published will then be able to review the report.
The following article describes the steps that can be used to Publish currently unpublished report or Unpublish a previously published report from an instance using the new Report Designer User interface:
While another article describes the process to Publish or Unpublish a report using the Report Builder interface: