Hello Jonathan, I understand. You're right. So, can we document plan for new GDPR improvements on wiki? Next steps?
Michal pá 22. 11. 2019 v 16:53 odesílatel Jonathan Druart < [email protected]> napsal: > The anonymized_borrowers table will not contain all data from > borrowers. Only a small part. > Also we want to track down the transactions when they happen, it will > be much more easier to implement and less error prone. How do you want > to retrieve the transactions for a given patron when they are > anonymized? > > Also you want to collect statistics only on this table, it will be > impossible to make statistics on this table for "anonymized" patrons, > and another table for the ones that are not anonymized yet. > > Does it make sense? > > Le ven. 22 nov. 2019 à 16:33, Mike D. <[email protected]> a écrit : > > > > Hello Jonathan, > > sorry "we want to see them as results from borrower searches" shoub be > "we want to hide them (anonymized borrower records) from all results from > searches" > > > > Really we need to copy every patron into anonymized_borrowers at time of > creation of their records? I think that must be done only in case that we > want to anonymize borrower. Not before this day. Because if we will copy > all translation into new table we'll maka database bigger wi same data. Do > I understand it clear? > > > > Michal > > > > pá 22. 11. 2019 v 16:08 odesílatel Jonathan Druart < > [email protected]> napsal: > >> > >> 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 > _______________________________________________ Koha mailing list http://koha-community.org [email protected] https://lists.katipo.co.nz/mailman/listinfo/koha
