2024-02-05 Resource Access Meeting Notes - Gap List - Request anonymization


Feb 29, 2024


Find all recordings here: https://recordings.openlibraryfoundation.org/folio/resource-access-sig/ (pw: folio-lsp)


https://zoom.us/j/337279319 (pw: folio-lsp)


@Cornelia Awenius @Christine Tobias @Cheryl Malmborg @Amelia Sutton @Charlotte Whitt @David Bottorff @Dwayne Swigert @Kara Hart@Erin Weller@Karen White @Laurence Mini@lisa perchermeier@Magnus AnderssonOlga@Petra Schneider@Tara Barnett@Tobi Hines@Catherine Tuohy@Kimie Kester

Discussion Items:













@Cornelia Awenius

Next Meetings

Meeting times

Note taker: @Catherine Tuohy


No meeting on Monday, February 19 (Presidents Day - US)

Thursday, February 8 is joint meeting with Metadata Management SIG - starts at 11:30am.


New Gap List Working Meeting - Planning


Magnus will take the lead for multiple items on requests notices
let us know if you see something on the gap list you’d like to work on

reading room checkout will be a topic for the whole group, inviting people who are already involved



@Cornelia Awenius 

Continuation of Gap List topic Request Anonymization

Meeting Notes

notes from January meeting:

summary of loan anonymization

what we have:
on demand from a specific user record, not possible for loans with related fees/fines
through settings after a certain period, with different options for loans with related fees/fines and possible exceptions per payment method
patron name and barcode are removed from the loan, patron group at check out is retained
item search in the circ log shows loan actions without user information
what we don't have:
retaining patron custom fields and department field

request anonymization

we are not talking about:
removing patron information from open requests
workflows for confidential requests that should not show patron information at all

are there any workarounds?
the only one would be deleting closed requests, Swedish libraries are keeping them right now

open questions:
Do we need different settings for the four different closed requests statuses?
the group could see use cases for that, but could live without, most don't have access to closed requests in current/former systems
How to handle bulk anonymization?
should be talked over with Bulk edit group, automated anonymization would be more important for European libraries
Should anonoymization be possible for specific requests or for a list of search results?
to be discussed in connection with bulk actions
What patron information to retain (patron group, department, custom fields)?
to be discussed next time, suggestion: should be handled the same way as loan anonymization
How should anonymized requests show up in the circ log?
to be discussed next time
Should anonymized requests still be displayed when searching/filtering the request app, just without patron information?
to be discussed next time 

notes from this meeting:

different options for the four different closed requests statuses are not necessary, agreed upon by Swedish and German libraries
automated anonomyization important for European libraries for legal reasons (GDPR)
requests that are still on the hold shelf (item status awaiting pickup) should not be anonymized!
retaining patron information: taking loans as an example, patron group in a first implementation, deciding on department and custom fields later accordlingly to loan anonymization
circ log: patron barcode removed as it is in loans, some discussion about source field, this should not be the patron who made the request but third party API
display in requests app: anonymized requests should still be there, just without patron information
for better handling of long lists, having a date range filter would be useful

manual anonymization (discussion not finished): could be in the Actions dropdown menu, possibly greyed out for result lists that contain open requests
deleting a user who wants their data cleared is not a workaround! User information is not displayed on the requests detail page anymore, but in results lists and in request JSON

after changing a user’s barcode, only requests made with that specific barcode show up in a search - how this could be improved is another topic