Page Comparison

...

• First iteration created in MODDICONV-137
• Bugfixes required and will be delivered in LotusMorning Glory, so this page has been created to document expected behavior for 1) Protecting MARC field and then 2) Overriding MARC field protections. (overrides not yet documented here)
• Related bugs
  • https://issuesfolio-org.folioatlassian.orgnet/browse/MODDATAIMP-643
  • https://issuesfolio-org.folioatlassian.orgnet/browse/MODDICORE-248
  • https://issuesfolio-org.folioatlassian.orgnet/browse/MODDICORE-146

Current constraints of MARC Field Protections:

...

See MODDICORE-146 SPIKE: Instance & SRS record updates need to honor MARC field protections for additional technical information

MARC Field Protections Scope: 

(updated as of the Morning Glory release)

1. Before Morning Glory, MARC field protections are only invoked if a MARC Update action is included in the job profile.
   1. Based on feedback from the community, consider changing the behavior so that the field protections are as of Morning Glory, field protections will also be invoked automatically/implicitly when the job profile includes an Update Instance action.
2. When evaluating data in a subfield, MARC field protections are not case-sensitive. For example $a NcD, $a NCD, $a Ncd, $a ncd, $a ncD would all be considered equivalent and duplicates of each other.
   1. After testing and early substantial usage, if the community decides that the field protections must take upper and lower case into account for data in subfields, consider changing the behavior so that the field protections are case-sensitive rather than case-insensitive
3. For data in a subfield, the field protection is based on the entire data string.
   1. Consider supporting wildcards, begins, ends, contains in the future.
4. One master list of MARC field protections is maintained in Settings/Data import.
   1. Per conversation with the MARC Holdings libraries, MARC field protections will NOT be applied to MARC Holdings records. 
   2. Unless/until a Unless/until a future use case is identified that necessitates differentiation, this same list of field protections will be used for MARC Bibliographic and MARC Authority records. 
   3. Per conversation with the currently-known MARC Holdings libraries, MARC field protections will NOT be applied to MARC Holdings records.
5. MARC field protections are controlled at the tenant level, though field protections can be overridden for a particular action profile/job profile.
   1. Based on feedback from the community, consider adding the ability to include additional field protections in individual job profiles, for MARC fields that are used infrequently or do not normally need to be protected.
6. Question for librarians: can we assume that LDR, 002-009 fields do not need field protection? Per MM SIG and DI subgroup, March 2022: fields 006 and 007 should allow field protection, but none of the other control fields (LDR, 002, 003, 004, 005, 008, 009)

...

• Given no MARC field entry exists
• And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry
• Then the end state will include the collection of the incoming MARC field entries

Overriding

...

MARC Field Protections

• As with applying MARC field protections, overriding those protections are somewhat limited in releases prior to Morning Glory, in that they cannot be used without an Update MARC action in the job profile, and do not distinguish the handling for repeatable and non-repeatable fields properly.
• As of the Morning Glory release, all of the details in the above MARC field protections scope section also apply to overriding MARC field protections.
• Field protection override behavior:
  • Field is non-repeatable, and the field protection for the existing field is overridden in the job profile
    • Existing field's will be replaced by the incoming field's data in the updated record, regardless of whether that data is the same or different from the existing data
  • Field is repeatable, and the field protection for the existing field is overridden in the job profile
    • Existing field also is in the incoming record:
      • The field will be retained in the updated record (actually replaced by the incoming version of the field, which is an exact duplicate to the existing field)
    • Existing field is not in the incoming record:
      • The field will not be retained in the updated record (since its protection was overridden)