Reporting in Service-now.com is usually very simple. One challenge I’ve seen before with the Service-now reporting interface is that it displays a lot of tables to most users as tables they can report on. The list of reportable tables is controlled by system security ACLs. If a user can read a table in the system they can also report on that table. There are many cases where users need to be able to read from a table in order for the system to work correctly for them, but you may not want users running reports on that table just because they see it as an option in the reporting interface. I’ve created the Restrict Report Tables update set as a solution to this problem. It gives Service-now report administrators granular control over which tables in the system show up as selectable options in the report interface.
This customization includes the following features:
- Limit the ‘Table’ options that display in the reporting interface by role
- Simple script manipulation to limit any override roles for this behavior
This solution includes three primary components. The first is the ‘Report Tables’ table definition along with the ‘Report Tables’ module. This component is restricted to users with the ‘admin’ or ‘report_admin’ role by default.
The second component is the ‘RemoveReportOptions’ UI script which handles the showing and hiding of report form elements. It also controls the override roles (‘admin’ and ‘report_admin’ by default) for the entire behavior.
Finally, the ‘GetReportTables’ Script Include handles the back-end query and selection of reportable tables based on the user role.
There are really only two configuration options that you’ll need to worry about. The first is the ‘Report Tables’ definition as shown in the screenshot below. Simply define the tables (and associated roles) that the tables should be available to. The second is the override roles contained in the ‘RemoveReportOptions’ UI script. By default, the ‘admin’ and ‘report_admin’ roles are not impacted by this behavior. You can modify that by changing or adding to the lines at the top of that script. UI Scripts are found under the ‘System UI’ application.
This is very cool. Thank you for building this!
Thanks for your comment! I’d love to hear any feedback you have on any ideas you get from SNCGuru.
Seems like you’re missing 2 acls:
– u_report_tables: create
– u_report_tables.*: write
If you add this it also works for “report_admin”
Thanks for the feedback. The update set includes ACLs for row-level Read, Write, and Delete. These ACLs (and the rest of the functionality) open up full administration privileges for the ‘admin’ and ‘report_admin’ roles. There should be no need for additional ACLs to make the functionality work properly for the ‘report_admin’ role.
As I tested this after reading your comment I did notice that a user without either of these roles could still navigate directly to the ‘u_report_tables’ table and, although they could not read, write, or delete any of the existing records, they did have the ability to create completely empty records in the table. This is really more of an annoyance than anything since empty records in that table still don’t impact the functionality of the feature at all, but it is still an annoyance that can easily be fixed :). I just updated the update set to include a row-level ‘create’ ACL that limits the create operation to the ‘admin’ and ‘report_admin’ roles.
Hey Mark, I wanted to let you know that an equivalent update is in Fall 2010 Stable 3.
Someone must have seen your post and decided it was a good idea.
Yep, just saw that a few days ago too. There are still a couple of bugs (which I’ve reported to support). Hopefully those get fixed in the Winter release and there won’t be any more need for custom code :).
We just recently implemented SNOW. I don’t see this “update set” you refer to. is it a plugin to activate?
The update set is available from the download link at the bottom of the article. There’s also a link to a post explaining how to install the update set.
This is great. This give the permission restrictions I was looking for. Thanks for creating this.
I was wondering if there is a possibility of disabling part of the filter condition in reports. For example, the user should only be allowed to update created date/time filter condition and not the other ones.
The field ‘filter’ in reports is of type ‘condition’ and thus I cannot access part of condition in client script too.
I’m not aware of a way to do that currently.
This is very nice and easy to maintain. Thanks Mark.
Looking at the the UI script in the update set which is mentioned above.
1. What will happen if the HTML structure or the name/id of an tag changes?
2. What are the changes that service-now will change the names/ids of the tags used in the given UI script?
Thanks and regards,
If the name/id changes then the script will break. This is something you need to be aware of with any client-side scripting in ServiceNow. In this case, I think that the entire report page would have to be reconstructed for that to happen (and the elements I’m targeting haven’t changed in 5 years). If it does happen, I’ll post a fix here.
Thank you Mark for the response.
Is there a way of getting the table name in a report_on ACL script?
Eg:- If role is itil, only show a particular list of tables in the drop down.
Thanks and regards,
The ‘report_on’ ACL is table-based so you should be able to do that with a regular ACL and the ‘itil’ role in the related roles list on the ACL. If you have further questions about report_on ACLs you should ask them on the ServiceNow forums. I will warn you though, that the ‘report_on’ ACL functionality is still half-baked in my opinion. I would still use the UI script-based solution I’ve created here.
Okay in reviewing this I am not sure it works on the latest patches of calgary. I tried adding an alert to let me know when it hits the tableoption popOptions(response) and I am not getting one. My users in a specified role still get all the tables instead of the ones for them only.
Am i missing something? The Report_On ACL seemed awfully tedious but again might be missing something here.
Situation: Created a custom application that needs to be separated from the rest of the users. It works well but they want to create and view reports. I only want them to be able to create and view reports that are within their module and its creation. Since I cannot modify the report_home page (frustrating) and I do not want them to pull reports from other areas of the application or create them for other areas I was hoping this solution would get me there.
I just installed it on demo004 and it’s working correctly there. You can test as ‘Itil User’ to confirm. The ‘report_on’ ACL works well, but for your situation you’ll want to start with a default deny ACL for all tables, then add permissions to allow reporting on specific tables from there.
Interesting, I do see it working there. The same script in my instance doesn’t even pop the Alerts Hello and Got Here. I can can’t seem to work out in my head why a global script wouldn’t at least fire off the alert.
Very Strange. Currently on Calgary Patch 2 Hot Fix 11.
I will keep checking. Our scripts and setups are the same. Something just isn’t lining up.
Okay i figured it out, with the Signature Pad script that is also on your site it doesn’t work in fact neither does the dynamic window. As soon as I pulled the signature pad out all of them started working instantly!
Has anyone gotten this to work in Eureka? It seems to have stopped for us after upgrading from Calgary to Eureka.
Hey Paul, the easiest way to check that is to load it into a ServiceNow demo instance. I just did that at demo003.service-now.com and it seems to be working without issue there.
Seems to work great in a fresh Eureka. But after upgrading from Calgary to EUREKA it has stopped working. Unsure why, or where to validate since the code appears to be the same?
I’m not positive, but I would make sure the UI 14 plugin is active in your upgraded instance. Outside of that, the only thing I can suggest is to check the console log in your browser and see if there are any error messages that could point you in the right direction.
I am also having an issue with this when we upgraded from Calgary to Eureka Patch 7.
Seems that on reports with a sort by it doubles the sort by when the report is displayed. Then if the report is saved, when the screen is displayed again and the sort by section is doubled again. So very quickly the sort by section can get very long.
Created a HI tickets and response was PRB608744, but then they came back that the developers had looked and that it was due to unsupported customization.
If UI Script RemoveReportOptions is made inactive then everything works fine, other than the list of tables is very long.
Trying to work out what in RemoveReportOptions is making the report screen double the sort by option on the screen.
We are having the same issue since upgrading from Calgary to Eureka (Patch 7). Support has given us the same response. Here’s what we got back from Support:
I narrowed the issue down to line 74 in the ui script (RemoveReportOptions), where a method called ‘depChanged()’ is being used. Something in that method is causing the issue.
I haven’t been able to figure out what this is doing exactly and can’t find a reference to this method anywhere else in the system.
Hi Robert. ‘depChanged’ is actually ServiceNow code, but they’re refactoring their reporting interface starting in Eureka and very drastically in Fuji. As such, it looks like it is no longer available. I recommend you start using the standard ACL-based approach that ServiceNow has come out with since this capability was created here.