Thanks for the help Michal, What about the two options I have?
Le jeu. 21 nov. 2019 à 17:58, Mike D. <[email protected]> a écrit : > > Hi Jonathan, > I’m volunteer for debate about processes and anon tools and methods. I’m > ready to be tester of bugs. Koha is GDPR ready but some points could be > improved for easier everyday usage in libraries. Because if something is > clear and easy everybody do it without fear and stress. > > Thank You > > Michal > > čt 21. 11. 2019 v 17:14 odesílatel Jonathan Druart > <[email protected]> napsal: >> >> Hello everybody, >> >> I have been contracted by KohaLa to work on some GDPR requirements. >> The main idea is to "anonymize" patron's data but letting the library >> access the transactions' statistics. >> >> I am going to present you what I am planning to implement, in order to >> collect ideas and answers. >> >> There are the following steps I have in mind: >> 1. Pseudonymization [1] of patron's data >> 2. Improve deletion of patron related date (tables statistics, >> old_reserves, deletedborrowers) >> 3. Add the ability to remove data that have been pseudonymized >> >> I see 2 ways to achieve point 1: >> * We create 2 tables, 1 for the patrons, 1 for the transactions. >> - borrowers_anonymized will contain: hash_id, has_cardnumber, >> branchcode, creation_date, categorycode, bsort1, bsort2, >> [borrower_attributes] >> - transaction_anonymized will contain: hash_id, transaction_type, >> branchcode, itemnumber, holdingbranch, location, itemcallnumber, >> itemtype, timestamp >> >> hash_id will be generated using the borrowernumber and a key (that >> will be stored on the server, path in koha-conf) >> >> Pros: Easier to understand and manipulate as it follows existing structure. >> We track patron's modifications (this is the most important part) >> Cons: tech part: new config, a new path have to be created (minor) >> >> * We create only 1 table, (nosql-like). It will contain the same data >> as previously, without the hash_id >> >> Pros: No new config. Data are never updated and we have the values >> when the transactions has been processed. >> Cons: Data are not updated :) >> >> About borrower_attributes, the initial specification asks for 2 >> attributes defined in a syspref. I think it should be configurable, >> with a join table (Pro: more flexible, Con: SQL requests more complex) >> >> I think we should have the 2 tables and keep a link between the >> anonymized_patrons and anonymized_transactions tables. >> >> What do you think? >> I am going to start the implementation very soon in order to plan an >> integration early in the 20.05 dev cycle. >> >> Regards, >> Jonathan >> >> [1] https://en.wikipedia.org/wiki/Pseudonymization >> _______________________________________________ >> Koha mailing list http://koha-community.org >> [email protected] >> https://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha mailing list http://koha-community.org [email protected] https://lists.katipo.co.nz/mailman/listinfo/koha
