DI Log: Adjust the logic for the statuses that show in the UI log

Purpose: To ensure that the log UI display shows the "highest" that happened to a record, rather than multiple actions or the "Multi" status

As a staff person working with Data Import logs
I want to know the highest action that happened to a particular record
So that the log screen is less confusing

Scenario

1. Given the Data Import log

2. When displaying the actions in the summary and details

3. And if multiple actions have happened to a record (e.g. an Instance being created and updated, or an SRS MARC being created and modified, or a profile with branches where a record takes an action in one branch but not in the other)

4. Then ensure that only the highest action is displayed

See attached diagram

Action hierarchy

1. Created (record did not exist in FOLIO prior to job and exists now)

2. Updated (record existed in FOLIO before the job, and has been updated by the job)

3. No action (record may or may not have existed, but no action was taken - due to error, or multiple matches, or profile not specifying an action)

Notes

1. Errors can happen at any level, and are designated separately in the log

   • Data errors and multiple matches should be designated as errors

   • No match is not an error

2. Modified is not an action that ever appears in the log. It applies to the incoming SRS MARC, whereas all the other statuses apply to FOLIO records

3. Multiple is not an action that ever appears in the log, since every FOLIO record is represented on a separate line in the log

Additional notes transferred from a deleted duplicate issue

• Problem definition: The Data Import UI log statuses are confusing to DI users in some cases, and will need review in light of the Poppy work for creating/updating multiple holdings/items from single incoming MARC Bibs. In light of that, do the following in this spike.

• To do

  • Review the current log bugs attached to this feature, and confirm status logic addresses them properly

  • Create documentation that outlines the technical logic for UI status assignment

QA notes

• New TestRail is not needed

• Existing TestRails for logs need to be updated to match this story