Currently a user with the execute_reports permission can run any report in the system. A library may wish for a given user to be able run some reports but not others. It would be great to have a mechanism for allowing limited reports access. Maybe something akin to the SubfieldsToAllowForRestrictedEditing preference? We could create ReportGroupsToAllowForRestrictedExecution, in which one selects groups of reports. We add a new execute_reports_restricted permission. A user with that permission can only run reports in the groups specified in the preference. Or maybe ditch the system preference and add a "restricted access" flag to each report?
This would be very helpful for consortia. We'd like staff to run specific reports created for their library. Right now they can run network wide reports any time which can slow down our system during peak hours.
This would be great improvement for our consortium and I would imagine for any larger library system too. We want to empower library staff to run reports but we'd also like our consortium-wide reports to be accessible only to our consortium/network staff. Consortium wide reports are resource intensive and we run those in "off" hours. If library staff had access to a set of reports just for their location it would be more efficient and effective.
I think the "restricted access" flag would be a great way to go rather than groups.
We would be interested in this as well. We haven't had a problem yet, but it is a potential concern that someone can get personal patron data from a library they don't work at. We would like to see this be secure and only staff who need to see that type of data, be able to see that type of data. - Bob Bennhoff
(In reply to AspenCat Team from comment #4) > We would be interested in this as well. We haven't had a problem yet, but > it is a potential concern that someone can get personal patron data from a > library they don't work at. We would like to see this be secure and only > staff who need to see that type of data, be able to see that type of data. - > Bob Bennhoff I was just thinking this same thing. Locally, we have a mechanism where reports that include "borrowers" need to use a token which is sent to a supervisor by email. That way, the supervisor knows who is running those potentially sensitive reports and when they're running them. (Kind of like some retail systems that require two people to authorize certain transactions.)