MARC21 record validation support - Phase 1
Description
Priority
P3Fix versions
Development Team
Assignee
Solution Architect
Parent Field Value
Parent Status
is defined by
relates to
requires
Confluence content
Checklist
hideTestRail: Results
Activity
Kalibek TurgumbayevMarch 4, 2024 at 7:29 AM
Hi @Khalilah Gambrell
For UI record validation I understand that the list of violations should be shown immediately in UI.
For the data-import scenario, I want to understand what kind of reports do we need.
Regarding #2 The question was about the same document when it is updated through data import or UI. Should we store the validation results of the previous version of the same document?
Khalilah GambrellMarch 1, 2024 at 1:55 PM
Hey @Kalibek Turgumbayev -
Regarding #1 are you referring to this scenario: User imports a record. The record has invalid values based on tenant level validation rules. User goes to MARC authority OR Inventory app > Edits that record via UI?
OR are you referring to the following scenario
User imports a record. Data import checks tenant level validation rules and identifies violations?
Regarding #2 - I do not know if I am answering your question. We need to store all violations. See this document https://folio-org.atlassian.net/wiki/spaces/FOLIJET/pages/1394918/MARC+Validation+Requirements+Overview
Kalibek TurgumbayevMarch 1, 2024 at 9:29 AM
Hi @Khalilah Gambrell! I have a couple of questions:
What should be the representation of validation results in case of data import flow? A new UI screen, an existing report related to job executions?
Should the solution persist history of validations related to the same document?
Natalia ZaitsevaNovember 3, 2023 at 11:16 AMEdited
as per the Q Release Planning session, we agreed on the following:
in Q release @Kalibek Turgumbayev will work on the approach
the implementation part will be considered in the R Release
Estimation provided:
Back-End: M (5 days) for review (assumed that review from back-end will not be needed in Q release)
Front-End: XL (15 days) for the implementation part in Ramsons release
Khalilah GambrellAugust 14, 2023 at 6:28 PM
only allow certain unicodes (no emojis) – possibly >>> whitelist support
Initial bibliographic control based on 9XX
Goal: When a user creates/updates a record then more robust MARC validation should happen. Feature intent is to define default validation rules and allow the library (tenant level setting) to set custom rules. "Q" release focus will be on defining technical design approach.
To be considered:
The tech design should not be MARC centric meaning that it should be flexible enough to assign a set of validation rules per record type + format.
The tech design should also allow for any flow that creates/updates MARC to opt-in to using these validation rules
This feature will however focus on MARC. Additional features must be created to support other formats.
Technical design will focus on MARC bibliographic and MARC authority records.
Requirements/Scope:
Implement standard MARC21 validation rules
Repeatability
Valid values (fields, indicators, subfields)
Mandatory/optional
See Bibliographic rules UXPROD-4354 and UXPROD-4358
See Authority rules UXPROD-4361 and UXPROD-4362
Ability to revise default validation rules at tenant level and global level
Ability to add new, local rules
Repeatability
Valid values (fields, indicators, subfields)
Mandatory/optional
Ability to bypass validation:
Default (MARC21)
ISBN/ISSN Validation
Ability to set whether validation rules should be a warning (warn, but permit save) OR error that prevents user from saving record
Ability to report catalog errors
Need to consider migration workflows where these rules can be ignored/bypassed. Same for data import workflows.
Need to consider when default validation rules change due to change in MARC standards
Consider ECS requirements