Requests: Anonymization of closed requests

Description

 

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)

Priority

Fix versions

None

Development Team

Volaris

Assignee

Irina Pokhylets

Solution Architect

Parent Field Value

None

Parent Status

None

Checklist

hide

TestRail: Results

Activity

Show:

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

PO Rank

89

PO Ranking Note

2021-03-08 - BT: Making PO rank the same as calculated rank for now. 2020-10-04 - CB: Making my PO rank same as the calculated total rank for now. 2019-07-12: Keeping PO rank same as calculated rank (with potential minor adjustments to avoid having two features with same rank)

Estimation Notes and Assumptions

CB: Per agreement with Jakub and the cap planning team, some of us non-developers will estimate the remaining unestimated features so as not to disrupt development. I am estimating this based on the estimates for anonymizing loans and fee/fines (UXPROD-271 and UXPROD-447).

Front End Estimate

XL < 15 days

Front End Estimator

Front-End Confidence factor

Low

Back End Estimate

XXL < 30 days

Back End Estimator

Rank: FLO (MVP Sum 2020)

R1

Rank: 5Colleges (Full Jul 2021)

R4

Rank: Cornell (Full Sum 2021)

R1

Rank: Chalmers (Impl Aut 2019)

R1

Rank: GBV (MVP Sum 2020)

R2

Rank: hbz (TBD)

R1

Rank: Hungary (MVP End 2020)

R1

Rank: Grand Valley (Full Sum 2021)

R2

Rank: Mainz (Full TBD)

R1

Rank: TAMU (MVP Jan 2021)

R2

Rank: Chicago (MVP Sum 2020)

R4

Rank: MO State (MVP June 2020)

R1

Rank: U of AL (MVP Oct 2020)

R4

Rank: Leipzig (Full TBD)

R1

Rank: Lehigh (MVP Summer 2020)

R2

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created August 26, 2018 at 6:06 PM
Updated August 6, 2024 at 12:13 PM
TestRail: Cases
TestRail: Runs