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: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-02-28 20:27 UTC by Donna
Modified: 2024-10-10 15:31 UTC (History)
15 users (show)

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


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
Comment 7 Caroline Cyr La Rose 2024-06-05 14:46:37 UTC
I've run into this problem with our consortium installation. Each library has access to reports, therefore access to all the information of all the libraries, including patron information, which is sensitive...

I was thinking maybe something similar to lists (who can run this report? Everyone, Owner only, etc.) or similar to acquisition funds (who can use this fund? Everyone, Owner only, Owner and users only, or Owner/users/library) with the possibility to add users one by one.
Comment 8 David Cook 2024-06-06 04:19:56 UTC
(In reply to Caroline Cyr La Rose from comment #7)
> I've run into this problem with our consortium installation. Each library
> has access to reports, therefore access to all the information of all the
> libraries, including patron information, which is sensitive...
> 
> I was thinking maybe something similar to lists (who can run this report?
> Everyone, Owner only, etc.) or similar to acquisition funds (who can use
> this fund? Everyone, Owner only, Owner and users only, or
> Owner/users/library) with the possibility to add users one by one.

Interesting idea although I'm not sure how it would work in practice.
Comment 9 Mathieu Saby 2024-06-06 08:38:13 UTC
Hi
In Europe this is pretty bad on a GDPR point of view...
Could we imagine something like the logic in acquisition module, where funds can be managed by specific colleagues ?
Comment 10 David Cook 2024-06-17 23:07:25 UTC
(In reply to Caroline Cyr La Rose from comment #7)
> I've run into this problem with our consortium installation. Each library
> has access to reports, therefore access to all the information of all the
> libraries, including patron information, which is sensitive...
> 
> I was thinking maybe something similar to lists (who can run this report?
> Everyone, Owner only, etc.) or similar to acquisition funds (who can use
> this fund? Everyone, Owner only, Owner and users only, or
> Owner/users/library) with the possibility to add users one by one.

After reading this and bug 37052 again, I think that I understand and I think that I like this idea.