Let's take a look at a typical and unruly way to show tables to your end users for reporting. It smacks of unnecessariness and will invariably beg questions to you on how to do the most basic of reporting. What we want to do here is turn the model of how to display these tables on its head. Conceptually, we provide access to nearly all the tables in the system and allow you to blacklist ones you want to exclude. What I'm going to show you is how to switch this model to a whitelist framework.
Beginning in the Fall 2010 Stable 3 release we added a simple functionality to our ACLs called "report_on". Like all Access Controls, this allows you to restrict what tables a user has the ability to view, use, or in this case generate new reports against.
*An important note about how this works is that users can still see and use global or group reports even if you've created a report_on ACL that prevents them from creating a new one against a table. This is very helpful if you want to simply the reporting experience and still provide some reporting on an ancillary table.
To set this up, it requires a few quick ACLs. Obviously, you can tailor the rules to meet your businesses' needs; however, I'm going to show you what I've seen to be the most common and practical.
The first one is an *. ACL that essentially creates a blacklist of all the tables in the system for reporting. Here, I've set the operation to "report_on" and the type as "record." Admin overrides and Active are both checked. Conditions and Scripts are both blank, and I've added the out of the box role "report_admin" to the Requires Role section. This allows any report_admin users to still view and create against any table.
Now if you check out what this looks like from an standard ITIL user, you'll see the tables are blank when generating a new report.
Great, now we just need to add a few ACLs that allow reporting on specific tables that we want to expose to our users. The most common ones might be Incident, Problem, or Change. I'll show you how to setup a couple so you can get the idea. The advantage of this method too is that you can allow reporting by specific roles or groups.
Create another record ACL with the operation as "report_on". Next select the table you want to expose, such as Incident and then Save and Stay. Next add the role of ITIL and violí , your ITIL user now can see the Incident and related tables when they go to generate a report.
Here's what that now looks like to your user with the ITIL role. See, much cleaner!
I mentioned that you might want to allow members of a particular group to have access for reporting on certain tables. Here's how you'd set that up:
Here, I've added one line to the Script section of the ACL:
gs.getUser().isMemberOf('CAB Approval');
This simply says, is the user a member of the CAB Approval group? If so, then allow; if not, deny.
Now, you can see my ITIL user who happens to be a member of the CAB Approvers group has a streamlined, easy view of the tables when creating a new report.
Hopefully, you can see how these simple steps greatly improve your users' experience in the reporting application and how to use the reporton_on ACL in a meaningful way.
More information can be found in the wiki on ACLs here.
And report administration here.
Have a great weekend,
Garrick
3 Comments
