| Controlling user access to report pages |
In a report that uses page-level security, report users can view only pages to which they have access. You can design a single report that meets the needs of a range of users. The most common case is to create a hierarchy of ACLs where each successive level has access to more information. The ACL hierarchy can match the organizational hierarchy of a company.
For example, in a report that provides worldwide sales data by region and country, you can restrict user access to the content as follows:
Each country sales manager can view only the pages that display sales data for her country.
Each regional sales manager can view all the pages that display sales data for the countries in her region.
The vice president of sales can view the entire report.
Figure 20‑1 shows the single page that the sales manager in France can view. Note that the page number is 1.
Figure 20‑1 Page that the sales manager in France can view
Figure 20‑2 shows the pages that the regional sales manager for Europe can view. The pages are numbered 1 through 5. Here, the sales data for France is on page 4, whereas, it is on page 1 in the report that the sales manager of France sees, as shown in
Figure 20‑1. The report displays page numbers sequentially in the order that they appear to a user.
Figure 20‑2 Pages that the regional sales manager for Europe can view
Figure 20‑3 shows the full report, which only the vice president of sales can view.
Figure 20‑3 Pages that the vice president of sales can view
Without page-level security, you would need to create multiple reports—one report for each user—and the iHub administrator would then have to define different security rules for each report, and manage multiple reports. In the sales report example, which presents data for three regions and eight countries, you would have to create twelve reports. For large companies, which typically have more hierarchical levels and more users, the number of reports increases.