Overview: The use case is that our institution usually protects the local 856 which may be different from the URLs in OCLC or in the generally available record. However, we regularly receive updates in which we need to remove a URL from a record because we have lost access on a platform or because the URL has changed. In these cases we need to update the srs record and then update the associated holdings record. Updating the srs record requires a marc to marc match, but we also need to be able to use a sub-match on the instance status and then the holdings record.  Adding the instance status submatch and/or the holdings type submatch prevents that job from completing.

Steps to Reproduce:

1. Log into Orchid bugfest.

2. In settings > data import > field protections, confirm that the 856 field is protected.

3. Use import profile Create ER instance and Holdings to create a new instance, srs record, and holdings record. (https://bugfest-orchid.int.aws.folio.org/settings/data-import/job-profiles/view/306a9899-03d7-49cf-b99c-75b6e26376da?sort=-updated%2Cname)

   1. The record should have a completely unique 035$a. 

   2. Use any marc record that has an 856 with a $u and add a unique suffix to the 035$a to make it completely unique.

4. Confirm that the instance and holdings created, 

5. Open the import record and make a change to the url, such as adding changed to the end of the url.

6. Import the file using job profile 035$a to 035$a match with instance status and holdings type submatch. (https://bugfest-orchid.int.aws.folio.org/settings/data-import/job-profiles/view/5b89241d-25bd-407e-b797-a5c4b421f59e?sort=-updated%2Cname) (035$a to 035$a marc bibliographic match, instance status static match, holdings type static match - then update srs and update holdings.) SRS MARC bib is updated, which in turn updates the Instance with status Electronic Resource should be updated and associated holdings should be updated.

7. Import the file using the job profile 035$a to 035$a match with submatch on instance status. (https://bugfest-orchid.int.aws.folio.org/settings/data-import/job-profiles/view/01af078a-d71b-4136-8e59-89fe25e2eb4c?sort=-updated%2Cname) SRS MARC bib is updated, which in turn updates the Instance with status Electronic Resource.

8. Import the file using job profile Update srs override 856 protections. (https://bugfest-orchid.int.aws.folio.org/settings/data-import/job-profiles/view/5a98d1da-3b2b-46c4-a107-2ad3e3a90464?sort=-updated%2Cname) SRS MARC bib is updated, which in turn updates the Instance.

Expected Results:

1. For the first import, the srs should be updated and the 856 protection overwritten. The holdings should be updated.

2. For the second import, the srs should be updated and the 856 protection overwritten.

3. For the third import, the the srs should be updated and the 856 protection overwritten.

Actual Results: 

1. First import will not complete.

2. Second import will not complete

3. The third import with just the match on the 035$a to 035$a and update srs action will complete. As expected the srs record is updated and the 856 field protection is overwritten.

Additional Information: Behavior is confirmed in Nolana and Orchid.

Interested parties: University of Chicago

BE notes: Provided that 035$a is unique and results in a single match, we can support https://bugfest-orchid.int.aws.folio.org/settings/data-import/job-profiles/view/5b89241d-25bd-407e-b797-a5c4b421f59e?sort=name profile. To do that make sure the following:

1. Match handlers (Instance, Holding) in mod-inventory take into account Instance UUID retrieved from the matched MARC Bib in the context - should be already in place, but check. Add test cases for MARC-to-MARC match and MARC-to-Instance submatch, and MARC-to-MARC match and MARC-to-Holdings submatch (2 cases, see description of this bug).

2. Subscribe SRS to consume events Instance matched, Hodings matched, Item matched. Add test cases (3 cases when we want to update MARC BIB as a result of match on a different event type).

We will not be able to support multiple match by one entity type and more exclusive submatch by a different entity type. Matching mechanism was not designed this way, and to support such scenarios would require redesign of the whole matching logic. It is out of scope of this bug.

Would be great if we could make this clear in the matching documentation; see https://folio-org.atlassian.net/wiki/display/FOLIOtips/Match+profiles%3A+Most+commonly+used; maybe add a table that discusses SRS matches

ORCHID Critical service patch details

1. Describe issue impact on business: This is a partial fix, which will likely need a more significant architectural change in the future. See details above. This fix addresses the exact case laid out in this bug, but does not address other types of matches that cross between entity types (e.g. SRS matches and Inventory matches). A more significant change and update to the match architecture needs to be analyzed and defined

2. What institutions are affected? (field “Affected Institutions” in Jira to be populated): Any using MARC-MARC matches with Inventory constant data submatches

3. What is the workaround if exists? Nothing simple

4. What areas will be impacted by fix (i.e. what areas need to be retested): Data import profile creation and import, using the scenario described in the bug

5. Brief explanation of technical implementation and the level of effort (in workdays) and technical risk (low/medium/high):

   • Work has been completed on this short term fix and required ca. 1 week of development time and test-writing

   • Purpose

     • Allow srs marc to process on instance, holdings, item match event

   • Approach

     • Added DI_INVENTORY_INSTANCE_MATCHED, DI_INVENTORY_HOLDING_MATCHED, and DI_INVENTORY_ITEM_MATCHED events to the list of srs marc process events

   • Risk: Low

6. Brief explanation of testing required and level of effort (in workdays). Provide test plan agreed with by QA Manager and PO: Test creation of the profiles and execution of the manual test cases linked to this Jira

7. What is the roll back plan in case the fix does not work? Revert the changes

NOLANA Critical service patch details

1. Describe issue impact on business: This is a partial fix, which will likely need a more significant architectural change in the future. See details above. This fix addresses the exact case laid out in this bug, but does not address other types of matches that cross between entity types (e.g. SRS matches and Inventory matches). A more significant change and update to the match architecture needs to be analyzed and defined

2. What institutions are affected? (field “Affected Institutions” in Jira to be populated): Any using MARC-MARC matches with Inventory constant data submatches

3. What is the workaround if exists? Nothing simple

4. What areas will be impacted by fix (i.e. what areas need to be retested): Data import profile creation and import, using the scenario described in the bug

5. Brief explanation of technical implementation and the level of effort (in workdays) and technical risk (low/medium/high):

   • Work has been completed on this short term fix and required ca. 1 week of development time and test-writing

   • Purpose

     • Allow srs marc to process on instance, holdings, item match event

   • Approach

     • Added DI_INVENTORY_INSTANCE_MATCHED, DI_INVENTORY_HOLDING_MATCHED, and DI_INVENTORY_ITEM_MATCHED events to the list of srs marc process events

   • Risk: Low

6. Brief explanation of testing required and level of effort (in workdays). Provide test plan agreed with by QA Manager and PO: Test creation of the profiles and execution of the manual test cases linked to this Jira

7. What is the roll back plan in case the fix does not work? Revert the changes