2023-07-10 Resource Access Meeting Notes

5min

Administrivia

Jana Freytag 

Erin Weller 

30Min

Request Anonymization

Thomas Trutt 

Ticket: https://folio-org.atlassian.net/browse/UXPROD-4302

Questions i have:

• What fields need to be removed what need to remain for reporting?

• Is multiple API calls acceptable? 

• What requests should be closed? Anything with "CLOSED – %" or should this be part of the API call?

We cannot use API for request anonymization – has to do with Circ Log. Loan anonymization is editing the Circ Log directly – no API exists that allows us to go in and remove patron barcode.

Thomas' questions for the team:

1. What information needs to be left behind for recording purposes?

   1. date, time – Circ log isn’t the only place we find info though, could be found in LDP? Or on the request itself? Thomas will have to go back to the request to see what would be retained – he was focusing on Circ log

2. What requests should be anonymized? Requests with a specific closed type or all closed types?

   1. Amelia Sutton – all requests

   2. David Bottorff – How frequently are you anonymizing? Do you want to anonymize on different schedules based on the type? We don’t want to lose that data too soon. Make it as parallel as possible to all the other anonymization workflows.

   3. Jana Freytag – make it similar to anonymizing loans, apply it to all requests

   4. Julie Bickle – in the metadata, you can see the source and we’d like to have the source anonymized as well, separate workflow but can happen simultaneously, in Germany there are agreements regarding staff log-in data (employers can see the data but can’t use it against the employee)

      1. Thomas Trutt – maybe we should look into developing security settings that only admin or supervisors can see that source data

Jana Freytag – hopes the anonymization doesn’t clear out the number of requests (for the library, for the item) – Julie Bickle – each request will have a UUID, there’s probably a way to pull reports, we need to make sure this count data isn’t lost – Cheryl Malmborg – we do need to add patron statistical data to the request app (patron type) so we don’t lose that

Amelia Sutton - It looks like requests save the following patron information:

requester__barcode

requester__last_name

requester__first_name

requester__middle_name

proxy_user_id

proxy__barcode

proxy__last_name

proxy__first_name

proxy__middle_name

Thomas Trutt – instead of request creation writing metadata at time of request, can do it at time of anonymization, David Bottorff – no we purposely did it at the time of creation because patrons can change patron type and we want to capture that initial information.

Amelia Sutton - I am looking through the requests data and I'm not seeing a direct connection between a request and its associated loan – Thomas Trutt – not all requests result in a loan

Thomas Trutt – will work on writing this up more, will ping Stephanie Buck to see if they can wrap this into their work