Michal, Redirection the discussion back to the list.
What do you mean by "we want to see them as results from borrower searches"? What I understood is that libraries want to collect statistics on transactions even when the patron's records have been deleted. So: 1/ Create a patron (it's copied to borrowers and anonymized_borrowers) 2/ Do some transactions (it's in statistics and anonymized_transactions) 3/ Update a patron (it's updated in borrowers and anonymized_borrowers, if option 1 is picked) 4/ Delete the patron (moved from borrowers to deletedborrowers) 6/ Clean/purge the deletedborrowers => anonymized_* tables are still there, statistics still possible 7/ When needed, given parameters, anonymized_* entries will be deleted. Le ven. 22 nov. 2019 à 15:51, Mike D. <[email protected]> a écrit : > > Hello, > I think that thinks are maybe less complicated. I really like Your idea with > hash. But if we anonymize (replace by some generated hash or something > similar) name, adress, telephone, e-mai and adress, noticess, we don't need > related information about borrowers. Because we cut the rope between data and > person. Anonymized borrower records we can set as "anonymized" and store them > separately from "live" borrowers, because we want to see them as results from > borrower searches. What do You think about this? > > Michal > > pá 22. 11. 2019 v 15:41 odesílatel Jonathan Druart > <[email protected]> napsal: >> >> 2 tables vs 1 table :) >> >> Le ven. 22 nov. 2019 à 15:28, Mike D. <[email protected]> a écrit : >> > >> > Hello Jonathan, >> > what options? I miss a point :-) >> > >> > Michal >> > >> > pá 22. 11. 2019 v 15:17 odesílatel Jonathan Druart >> > <[email protected]> napsal: >> >> >> >> 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
