Requests: Anonymization of closed requests
Description
Priority
P3Labels
Fix versions
Development Team
Assignee
Solution Architect
Parent
Parent Field Value
Parent Status
relates to
Checklist
hideTestRail: Results
Activity
Tim Auger May 5, 2023 at 6:26 PM
A former Volaris team member did some investigation on this work. Please look at https://folio-org.atlassian.net/browse/MODINREACH-314 . it's worth doing some digging into current anonymization activity to determine we can borrow any code.
Tim Auger September 29, 2022 at 5:55 PM
Need to write up a BE story and UI story
Brooks Travis October 15, 2021 at 8:18 AM
I went ahead and assigned this to Vega. Given its place in the pointing exercise, I'd put this at the top of the Requests feature queue, behind TLR. There may be some aspects of this that we may want to consider addressing in the scope of the TLR work, since we're going to be making changes to the record schema, and target the business logic and UI work for Morning Glory or later. I'm going to try and get this on the RA agenda in the next week or two and check in on the requirements.
Brooks Travis April 14, 2021 at 6:01 PM
I took a look at , and it's related inasmuch as it serves the same function of removing PII from the request record, but beyond that I don't think there's a direct relation. That feature seems to be a complete reworking of how user data is passed (or, rather, not passed) from mod-users to every other module in FOLIO where it's used. I'd have to have a conversation with to know for sure, though. I don't think 288 has been touched, really, in over two years.
Marie Widigson April 14, 2021 at 9:00 AM
How is this related to and other GDPR-Jiras?
Reporter
Cate BoeremaPO Rank
PO Ranking Note
Estimation Notes and Assumptions
Front End Estimate
Front End Estimator
Cate BoeremaFront-End Confidence factor
Back End Estimate
Back End Estimator
Cate Boerema
Current situation or problem:
Institutions will want to anonymize closed requests, breaking the link to the requesting patron, but retaining demographic and other data for statistical and reporting purposes
The anonymization will need to be done in batch, both manually run and automated, based on intervals set by the institution
In scope
Automated anonymization of closed requests
On-demand anonymization of one or more requests
Out of scope
Use case(s)
Proposed solution/stories [draft]
Add additional demographic data to the request storage data model (un-deprecate patron group)
Department
Custom Fields (need to consider this, since we don't currently have a way to indicate whether custom fields are PII)
Add setting to configure automated anonymization, a la loan history
Different settings for "Closed - Cancelled", "Closed - Filled", "Closed - Pickup expired", and "Closed - Unfilled"
Implement a scheduled anonymization job
Add action to Requests app results list pane action menu to anonymize all results
Add action to request detail action menu to anonymize the specific request
Links to additional info
Questions
Do we need different settings for each form of "Closed"?
Do we want to support bulk manual anonymization? (eg. search results action menu)
How can we handle custom fields?
How should anonymized requests show up in the circ log?
RA SIG discussed this on January 11 and February 5:
Automated anonymization is most important for GDPR reasons.
Different settings for each “closed” status are not necessary.
Retaining patron information should correspond to the handling in loan anonymization. In a first implementation, patron group should be retained, as it is currently the case with loans . Retaining of department and custom fields can be done later when it is implemented for loans as well.
In the circ log, requests should be displayed without a patron barcode, as it is for loans.
The SIG suggests to split this ticket into:
automated anonymization through settings (high priority)
retaining patron group
retaining department and custom fields
on-demand manual anonymization (low priority)