Bug 30198 - Add privacy elements to reports
Summary: Add privacy elements to reports
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Reports (show other bugs)
Version: 21.05
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-02-28 20:27 UTC by Donna
Modified: 2023-06-17 15:56 UTC (History)
8 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Donna 2022-02-28 20:27:50 UTC
Any staff member who has access to run reports potentially has the ability to see data they are not typically permitted to view.  It would be really helpful to be able to add limits to reports to restrict who has permission to view/run the reports.

For instance, as a circulation clerk, I may need to run a report of patrons that have overdue items with holds on them, so I can contact the patron about returning the item. However, since I have the ability to view/run all reports, I potentially could access reports that have patron reading history, or financial info in them.  

Likewise, if I am in a consortium/multi-library setting, and do not have the permission to view patron data from other libraries, in the reports module I can run reports that contain patron data from any of the other libraries.

I imagine something along the lines of funds access in acquisitions - owner, user, library, and being able to limit to any of those elements.
Comment 1 Andrew Fuerste-Henry 2022-02-28 21:02:28 UTC
Maybe this could tie to report (sub)groups? I like the idea of being able to mark things private/restricted either at the individual report, the sub-group, or the group level.
Comment 2 Katrin Fischer 2022-02-28 21:10:10 UTC
The issue with the sub group could be that a lot of people have authorised values permission for cataloging purposes.

Mabe we could have an option to flag those reports and a 'super reports' permission for running them? Although having different levels might be nice.
Comment 3 Steve, OSLRI, USA 2023-06-02 18:12:29 UTC
It was suggested that I hop on board this bug, so here I go!

Reading the comments on this ticket, I would suggest we are talking about two different things... both very useful!

1) I like the idea that Donna has originally suggested with the ability to restrict access to data in certain tables.  Perhaps one simple way to do this would be to identify tables and/columns that ought to require special permissions and create a single (or if warranted) a couple user permissions in place for those.  I'd agree with reading history. I'd also argue any PII fields in the borrowers table.

2) What brought me here might be a little closer to Andrew's comment.  (Maybe?)  We will potentially have many staff members in our system writing reports and are concerned about "clutter".  We'd love the ability for somebody to be able to define a "sharing level" for a report.  Perhaps, four levels:  (1) Private/Just Me, (2) Shared with My Branch, (3) Shared with My Library Group, (4) Shared with Everyone.  This would really help cut down on clutter AND allow people to work on draft queries that are NOT ready for prime time without somebody else attempting to use it by accident.  I'd agree that super librarians should see all.  That way we can help somebody with a report in their private reports should they ask for help.  (Perhaps this is a different bug?)

Cheers!
Comment 4 David Cook 2023-06-04 23:34:31 UTC
Something we've done locally is make it so that reports containing any reference to the borrowers table require an additional token/code that gets emailed to a supervisor. 

The supervisor then needs to give that code to the user wanting to run the report. 

That prevents the circulation clerk from running reports for patron information they shouldn't have.
Comment 5 David Cook 2023-06-04 23:38:38 UTC
(In reply to Donna from comment #0)
> Likewise, if I am in a consortium/multi-library setting, and do not have the
> permission to view patron data from other libraries, in the reports module I
> can run reports that contain patron data from any of the other libraries.

Unfortunately this one isn't really possible. Intervening before the query is sent to the database isn't feasible since the query permutations are too varied. Intervening after the results are retrieved would lead to a discrepancy in rows retrieved and rows viewed. You wouldn't be able to determine the result count until after you'd tried to retrieve all possible rows. 

It would lead to a wildly different user experience, and at that point you'd almost be better off re-writing the Reports module not to allow custom SQL at all. But that creates other problems too, of course.
Comment 6 AspenCat Team 2023-06-06 15:00:33 UTC
The way our consortium operates is we share reports by having our branches use a dropdown menu.  I'm not sure how feasible it is, but what would be ideal is making it so that drop down would only list the library that is logged in.  Similarly it would be good to prevent using a branch code for a report that does match the home library, at a certain permission level.  I certainly agree with David's point about the difficulties in accomplishing this, but perhaps instead of an intervention there would be a way to limit what is viewable or what can be selected based on branch. - Bob Bennhoff