I don't know if this is directly related to GDPR but at least this seems like a good practice: create a log if a librarian has accessed a Koha page in intranet that contains borrower's personal information. This way the library can make sure by auditing the logs that nobody has for example downloaded all the borrowers' info en masse with screen scraping. Currently this is a bit hard to implement in Koha since borrower's personal info is displayed on many many pages, but to ease this we should think if displaying borrower's real name is necessary or would a cardnumber or borrowernumber be better.
I think it really depends on the type of library, country, use cases etc. I think we'd definitely see some push back if we replaced the name by the cardnumber in general as this is seen as a feature. Libraries often know their patrons and want to see the names in a lot of cases. (think small company libraries, professors at universities etc.) But: we already have HidePatronName which makes this configurable in a lot of places that we could extend further. I think logging every page could get a lot pretty fast. Maybe we could start with viewing a patron record? (accessing the detail page) We should also make sure that patron batch edits are logged correctly.
(In reply to Katrin Fischer from comment #1) > I think logging every page could get a lot pretty fast. Indeed. This is to be expected. Larger Koha instances are probably talking about millions to tens of millions of log records of the access/view-event annually. Not to forget their action_log could already be bloated. One option would be to clear these logs periodically. The libraries that worry about action_log size but still want to store it long-term, could consider other means of storage. They could achieve that with Koha plugins. There's even real world cases where Koha libraries enabled the "view" event logging, and some of them regularly move this data into a separate database. They were also the source to my log row count estimation in the first paragraph of this comment. > Maybe we could start with viewing a patron record? (accessing the detail page) Splitting this into smaller parts is probably smart since it's going to affect many pages. > We should also make sure that patron batch edits are logged correctly. + REST API + other APIs. Figuring out all the places as well as making sure that this policy applies to future changes - it's going to be a lot of careful work :)
(In reply to Joonas Kylmälä from comment #0) > I don't know if this is directly related to GDPR By the way it looks like this is not required by GDPR. The Finnish libraries that use it in their custom Koha fork were inspired by the laws for health care sector, and decided to implement such functionality when there was still a lot of confusion regarding GDPR.
There was some confusion regarding this indeed. Koha and the webserver running in front of it provides already logs of similar content albeit in slightly harder to parse format. I feel like we can close this bug and re-open it later if somebody else is interested.
(In reply to Joonas Kylmälä from comment #4) > There was some confusion regarding this indeed. Koha and the webserver > running in front of it provides already logs of similar content albeit in > slightly harder to parse format. I feel like we can close this bug and > re-open it later if somebody else is interested. I don't know about Koha, but I imagine those web server logs are rotated and old ones are deleted.
I think Koha-Suomi libraries have had this in production for some years now. https://github.com/KohaSuomi/Koha-24.05/commit/827040cb1ede8f65c718bb8721c348382f92aa49.patch We also have clients that are interested in this type of logging. It would be great to have this part of upstream Koha. (In reply to Katrin Fischer from comment #1) > I think logging every page could get a lot pretty fast. We could add a new switch to cleanup_database.pl to handle different action log module-action-days combinations so that view logging could be wiped more often than other log types.