Batch Importer (Bib/Acq) (UXPROD-47)

[UXPROD-4080] Review and fix MARC Updates for individual fields Created: 20/Feb/23  Updated: 07/Feb/24

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: Ramsons (R2 2024)
Parent: Batch Importer (Bib/Acq)

Type: New Feature Priority: P2
Reporter: Ann-Marie Breaux (Inactive) Assignee: Ryan Taylor
Resolution: Unresolved Votes: 0
Labels: data-import, loc, possible-ramsons, quesnelia-stretch
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File MARC Bib Updates.png    
Issue links:
Defines
defines UXPROD-47 Batch Importer (Bib/Acq) Analysis Complete
is defined by MODDICORE-351 Fields duplicated when adding several... Open
is defined by MODDICORE-352 Fields duplicated when adding one sub... Open
is defined by MODDICORE-353 Subfield cannot be removed when updat... Open
is defined by MODSOURCE-691 Field is shown after being removed vi... Open
is defined by MODSOURCE-594 Duplicate field is added when updatin... Open
is defined by FAT-5907 Update C17019: Update indiv fields fxn Blocked
Duplicate
is duplicated by UXPROD-3696 Refine Update individual fields funct... Closed
Release: Ramsons (R2 2024)
Epic Link: Batch Importer (Bib/Acq)
Analysis Estimator: Ann-Marie Breaux (Inactive)
Front End Estimate: Small < 3 days
Front End Estimator: Mariia Aloshyna
Front-End Confidence factor: 30%
Back End Estimate: XL < 15 days
Back End Estimator: Kateryna Senchenko
Back-End Confidence factor: 30%
Development Team: Folijet
PO Rank: 95
Rank: Cornell (Full Sum 2021): R2

 Description   

Current situation or problem:
Currently (as of Orchid), the Data Import MARC Updates for specific fields do not handle repeatable fields properly. The logic needs updating, and UI may need updating to indicate how incoming repeatable MARC fields should be handled vis-a-vis the same repeatable field(s) in the existing SRS MARC Bib. This is similar to how the field protection logic needed updating to handle repeatable vs non-repeatable fields properly.

In scope:

  • Update specific fields in the MARC Bib, specifying how to handle repeatable fields if they already exist in the SRS MARC
  • See various scenarios from Spitfire below - include in the scope of this feature?

Out of scope:

  • Update of specific fields for MARC Authorities

Use case(s):

  • SMEs: Please add examples*
  • Example 1: Incoming MARC Bib only has Leader, 245, 856. Library only wants to update the existing 856, but not replace the rest of the existing MARC Bib
  • Example 2: only add the OCLC 035 to the existing record; ignore the rest of the incoming record{}

Proposed solution/stories:

Links to additional info:

Questions:

Background info

NOTE: Still need mockups

Confirm we have tests to support the following scenarios (from Spitfire)

  1. If field mapping profile has setup a bib field (repeatable and non-repeatable) AND subfield value = * AND $0 changed when importing update
  2. If field mapping profile has setup bib field (repeatable and non-repeatable) AND subfield value = $a AND $0 AND $9 AND that field is removed via import
  3. If field mapping profile has setup bib field (repeatable and non-repeatable) AND subfield = $a, AND $0, AND $9 and imported record has only $0 changed.
  4. If field mapping profile has setup bib field (repeatable and non-repeatable) AND subfield = * for subfields AND that field has been removed.


 Comments   
Comment by Ann-Marie Breaux (Inactive) [ 06/Apr/23 ]

Be sure to update Testrail https://foliotest.testrail.io/index.php?/cases/view/17019 once the repeatable/non-repeatable behavior is corrected in this feature

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