Requests (UXPROD-790)

[UXPROD-1041] Requests: Anonymization of closed requests Created: 26/Aug/18  Updated: 05/Feb/24

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Requests

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Irina Pokhylets
Resolution: Unresolved Votes: 0
Labels: requests, v+v_candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to UXPROD-4302 Request anonymization - thin thread Open
relates to MODINREACH-314 SPIKE: UXPROD-1041 Closed
Epic Link: Requests
Front End Estimate: XL < 15 days
Front End Estimator: Cate Boerema (Inactive)
Front-End Confidence factor: Low
Back End Estimate: XXL < 30 days
Back End Estimator: Cate Boerema (Inactive)
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).
Development Team: Volaris
Kiwi Planning Points (DO NOT CHANGE): 40
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)
Rank: Chalmers (Impl Aut 2019): R1
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R2
Rank: 5Colleges (Full Jul 2021): R4
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R2
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R2
Rank: Leipzig (Full TBD): R1
Rank: Mainz (Full TBD): R1
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R2
Rank: U of AL (MVP Oct 2020): R4

 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?
     


 Comments   
Comment by Brooks Travis [ 08/Mar/21 ]

I'm going to try and put together some stories and get this feature pointed and, hopefully, in development queue.

Comment by Erin Nettifee [ 06/Apr/21 ]

Brooks Travis the P5 prioritization on this and the ranking seem off to me - seems like priority should be higher, no?

Comment by Brooks Travis [ 06/Apr/21 ]

Thanks, Erin Nettifee, I've updated the priority and made modifications to the description fo the ticket, itself, including a proposed story(ies)/solution.

Comment by Erin Nettifee [ 06/Apr/21 ]

Great Brooks Travis, thanks. You can probably guess that this topic came up in Duke discussions today. I would also add for questions the need to address how anonymized requests would look in the circ log.

Comment by Marie Widigson [ 14/Apr/21 ]

How is this related to UXPROD-288 and other GDPR-Jiras?

Comment by Brooks Travis [ 14/Apr/21 ]

Marie Widigson I took a look at UXPROD-288 Open , 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 VBar to know for sure, though. I don't think 288 has been touched, really, in over two years.

Comment by Brooks Travis [ 15/Oct/21 ]

Stephanie Buck Khalilah Gambrell 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.

Comment by Tim Auger [ 29/Sep/22 ]

Need to write up a BE story and UI story

Comment by Tim Auger [ 05/May/23 ]

Irina Pokhylets 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.

 

Generated at Fri Feb 09 00:12:28 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.