ACL on Reports
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-07-2018 09:02 PM
Hi all,
We have got a requirement that in Incident and Catalog Tasks ,users with a specific role should be able to take reports on the tickets which is only assigned to them or to their groups. This should only affect reporting, not the task management functionality. In other words Users with that role should be able to search for, modify, watch and view tickets that have been assigned to other groups but they shouldnot be able to create reports. Restriction should be only in the Reporting.
We did tried the "Report On" ACL but that restriction is only for the Table level, meaning we can able to control on which table they can create a report not on the groups. Also we were not able to create ACL on the Groups table as it will affect the other modules as well.
Please let knowyour suggestions on the same. We need to confirm about the feasibility of this requirement ASAP,Immediate response will be highly appreicated.
thanks,
Sasi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-07-2018 09:45 PM
That sounds *SUPER* dangerous.
Think about it... the user is going to be able to list, read, and update other tickets... except when they go to "report"?
Its clearly not a security or a compliance concern, since they're allowed to see other people's tickets when not 'reporting'? So what's driving the requirement?
I keep using reporting in quotes because List Views are a form of reporting as well. I would argue that *seeing* is reporting in some fashion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-03-2018 02:26 AM
Hello Robert,
From a logical point of view I agree with you, but from a logistical point of view do not agree. Accessing the details of a record, for example the user details, is operational. However pulling a report of a whole range of records is another. Take this point of view: I am a desk user and access the user details when logging a call. That is operational. Now I am a desk user and since I have read access to the user name table I can create a report on the entire name table, dump it in a CSV file, and do whatever I like with that (GDPR?).
This can be mitigated by a business rule as sumit mentioned, but really, if there is an ACL specifically not to allow reporting on a table, why should that be bypassed by a record read rule for operational purposes? Again, I agree with you from a logical point of view, but does not make sense from a security point of view. Read access for operations is one thing, reporting on the entire table is another thing.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-08-2018 03:12 AM
There is not a tidy way of doing it but here is what i can propose.
1. Create a Query Business rule on both incident & catalog task table
2. Inside the business rule you need to check the source of query, you can use below statement do see if the query is coming from reporting module & then put a filter based out of role, group etc
if (gs.action.getGlideURI().toString().indexOf('report_viewer.do') >-1)
{
//Put a check for role & other filters here
}
You can refer existing query business rules to see how to put filters
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-08-2018 05:19 AM
Will that work if the data is presented as a widget on a homepage?