Restrict Report Table Selection by Role

//Restrict Report Table Selection by Role

Restrict Report Table Selection by Role

Update: ServiceNow has introduced new ACL functionality that allows you to do basically the same thing as described in this article. They’re also taking a drastically new direction with reporting starting with the Fuji release, but being introduced in the back-end code in the Eureka release. As such, the solution described here is obsolete and no longer supported. Check out this wiki article to see how to restrict report table selection using standard ServiceNow ACLs.

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.

Before



After


Please note that this functionality has no bearing on overall table security in your system. Users can still run filters, create bar and list charts, and otherwise run ad-hoc list reporting on any table in the system that they have read access to. If a user does not have read access to a table (as defined by your security ACLs) the functionality described here honors that security.

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

Core components:

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.

Usage:

This customization is only offered as an update set through ServiceNowGuru.com. You’ll need to install an update set into your instance to get this functionality. Installation and download instructions can be found below.

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.

By | 2018-07-09T15:00:03-06:00 December 20th, 2010|Categories: Reporting|Tags: , , |28 Comments

About the Author:

28 Comments

  1. Joe December 20, 2010 at 9:03 am - Reply

    This is very cool. Thank you for building this!

    • Mark Stanger December 22, 2010 at 12:12 pm - Reply

      Thanks for your comment! I’d love to hear any feedback you have on any ideas you get from SNCGuru.

  2. Koen van Dooren January 2, 2011 at 11:43 pm - Reply

    Fabulous!

  3. Koen van Dooren January 3, 2011 at 12:18 am - Reply

    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”

    • Mark Stanger January 3, 2011 at 12:49 am - Reply

      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.

  4. Garrett Griffin January 20, 2011 at 1:59 am - Reply

    Hey Mark, I wanted to let you know that an equivalent update is in Fall 2010 Stable 3.

    http://wiki.service-now.com/index.php?title=Admin

    Someone must have seen your post and decided it was a good idea.

    • Mark Stanger January 20, 2011 at 2:27 am - Reply

      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 :).

      • Jen October 15, 2012 at 10:48 am - Reply

        We just recently implemented SNOW. I don’t see this “update set” you refer to. is it a plugin to activate?

        • Mark Stanger October 15, 2012 at 10:52 am - Reply

          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.

  5. Donte Hooker February 23, 2011 at 11:12 am - Reply

    This is great. This give the permission restrictions I was looking for. Thanks for creating this.

  6. Amy February 24, 2011 at 7:13 pm - Reply

    Hi Mark,

    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.

    • Mark Stanger February 24, 2011 at 11:36 pm - Reply

      I’m not aware of a way to do that currently.

  7. Jim Uomini March 16, 2011 at 6:45 am - Reply

    This is very nice and easy to maintain. Thanks Mark.

  8. Pratik March 12, 2012 at 10:10 am - Reply

    Hi 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,
    Pratik

    • Mark Stanger March 12, 2012 at 1:35 pm - Reply

      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.

  9. Pratik Limbore March 13, 2012 at 2:33 am - Reply

    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,
    Pratik

    • Mark Stanger March 13, 2012 at 9:10 am - Reply

      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.

  10. eric January 19, 2014 at 12:19 pm - Reply

    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.

    Thoughts?

    • Mark Stanger January 20, 2014 at 7:30 am - Reply

      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.

  11. Eric January 21, 2014 at 12:26 am - Reply

    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.

    • Eric January 21, 2014 at 1:40 am - Reply

      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!

  12. Paul September 4, 2014 at 7:05 am - Reply

    Has anyone gotten this to work in Eureka? It seems to have stopped for us after upgrading from Calgary to Eureka.

    • Mark Stanger September 4, 2014 at 8:09 am - Reply

      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.

      • Paul September 8, 2014 at 2:06 pm - Reply

        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?

        • Mark Stanger September 8, 2014 at 2:08 pm - Reply

          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.

          • Jon February 4, 2015 at 5:35 pm - Reply

            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.

          • Rob March 26, 2015 at 8:53 am - Reply

            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.

Leave A Comment