Page History

...

The Metadb reporting database serves as a platform for generating reports for library staff on data from all functional areas of the FOLIO system. The Metadb software extracts, transforms, and loads data from the FOLIO application server continuously to the reporting database through its process of data synchronization. Both current and historical records are saved in tables in the reporting database. Some of these tables contain fields with patron identifiers, such as "user_id" and "requester_id." Patron identifiers are needed for current transactions – such as loans, requests, and fines that are open – to enable library staff to identify and communicate with those patrons. Patron identifiers for historical transactions – such as loans, requests, and fines that are closed – are not needed. To uphold the Cornell Library's Commitment to Privacy policies, patron identifiers on historical transaction records should be replaced with NULL values in the Metadb reporting database.

FOLIO Data vs Metadb

-FOLIO provides the functionality to create user roles that are limited to the staff member's more narrow data access needs. Metadb does not yet have role based access functionality: all users see all data. 

Risks

Like many reporting databases, the data fields and tables in Metadb are woven together with a complex set of interdependencies, connections, and data relationships. Deleting data in a PostgreSQL reporting database without a thorough understanding of the impacts on its infrastructure and data integrity poses several significant risks. 

...

Tables in Metadb with Patron Identifiers

For reporting, folio_circulation, folio_audit, folio_feesfines, folio_derived, folio_email, folio_orders, and folio_patron_blocks have lots of tables and transformed tables that contain user_ids, requester IDs, recipient IDs or free text indicators of users associated with specific loans, requests, circ “events” or library materials. Most of the tables are very complex in their density of data and links to other data. Here is a list of table sets preliminarily identified – this list may not be complete (a ‘table set’ is the full table, plus the various extracted tables with current and/or archive states):

• Folio_audit.circulation_logs
• Folio_circulation.audit_loan
• Folio_circulation.check_in (can be linked by item_id and date/time to audit_loan table, which has user_id)
• Folio_circulation.patron_action_session
• Folio_circulation.loan
• Folio_circulation.request
• Folio_circulation.scheduled_notice
• Folio_email.email_statistics
• Folio_feesfines.accounts
• Folio_feesfines.feefineactions
• Folio_orders.po_line__
• Folio_patron_blocks.fee_fine_balance_changed_event
• Folio_patron_blocks.item_aged_to_lost_event
• Folio_patron_blocks.item_checked_in_event
• Folio_patron_blocks.item_checked_out_event
• Folio_patron_blocks.item_claimed_return_event
• Folio_patron_blocks.item_declared_lost_event
• Folio_patron_blocks.loan_closed_event
• Folio_patron_blocks.loan_due_date_changed_event
• Folio_patron_blocks.user_summary

Current Loans are already purged of patron data, but Historical Loans are not

...

-a job runs on a schedule to delete the user id on loans checked in (discharged) on the loan__t table. The user id is reset to NULL, which anonymizes the data. It also removes the user id in the circulation audit table.

-Loan anonymization is configured in FOLIO here:
https://cornell.folio.ebsco.com/settings/circulation/loan-anonymization

...