MODAUD-225 Handle Repeatable Fields for MARC_BIB and MARC_AUTHORITY Audit Events

[dmytrokrutii]

MODAUD-225

Handle Repeatable Fields for MARC_BIB and MARC_AUTHORITY Audit Events

1) Add New Repeatable Field

Old Record (Without 020 Field):

[]

New Record:

[
  { "field": "020", "value": "VALUE_1" },
  { "field": "020", "value": "VALUE_2" }
]

Diff:

{
  "added": [
    {
      "field": "020",
      "value": ["VALUE_1", "VALUE_2"]
    }
  ]
}

---

2)

If a new field 020 is added, it appears inside added.

Old Record:

[
  { "field": "020", "value": "OLD_VALUE_1" },
  { "field": "020", "value": "OLD_VALUE_2" }
]

New Record:

[
  { "field": "020", "value": "OLD_VALUE_1" },
  { "field": "020", "value": "OLD_VALUE_2" },
  { "field": "020", "value": "NEW_VALUE" }
]

Diff:

{
  "added": [
    {
      "field": "020",
      "newValue": "NEW_VALUE"
    }
  ]
}

---

3) Multiple Updates

Old Record:

[
  { "field": "020", "value": "VALUE_1" },
  { "field": "020", "value": "OLD_VALUE_2" },
  { "field": "020", "value": "OLD_VALUE_3" }
]

New Record:

[
  { "field": "020", "value": "VALUE_1" },
  { "field": "020", "value": "UPDATED_VALUE_2" },
  { "field": "020", "value": "UPDATED_VALUE_3" },
  { "field": "020", "value": "NEW_VALUE" }
]

Diff:

Order is not preserved, and one element from oldValue is not necessarily the first value in parsedRecord.

{
  "modified": [
    {
      "field": "020",
      "oldValue": ["OLD_VALUE_2", "OLD_VALUE_3"],
      "newValue": ["UPDATED_VALUE_2", "UPDATED_VALUE_3", "NEW_VALUE"]
    }
  ]
}

---

4) Update and Order Change

Old Record:

[
  { "field": "020", "value": "VALUE_1" },
  { "field": "020", "value": "VALUE_2" },
  { "field": "020", "value": "OLD_VALUE_3" },
  { "field": "020", "value": "OLD_VALUE_4" }
]

New Record:

[
  { "field": "020", "value": "UPDATED_VALUE_4" },
  { "field": "020", "value": "VALUE_1" },
  { "field": "020", "value": "VALUE_2" },
  { "field": "020", "value": "UPDATED_VALUE_3" }
]

Diff:

Order is not preserved.

{
  "modified": [
    {
      "field": "020",
      "oldValue": ["OLD_VALUE_3", "OLD_VALUE_4"],
      "newValue": ["UPDATED_VALUE_4", "UPDATED_VALUE_3"]
    }
  ]
}

TODOS and Open Questions

Pre-Merge Checklist:

Before merging this PR, please go through the following list and take appropriate actions.

• Does this PR meet or exceed the expected quality standards?
  • Code coverage on new code is 80% or greater
  • Duplications on new code is 3% or less
  • There are no major code smells or security issues
• Does this introduce breaking changes?
  • Were any API paths or methods changed, added or removed?
  • Were there any schema changes?
  • Did any of the interface versions change?
  • Were permissions changed, added, or removed?
  • Are there new interface dependencies?
  • There are no breaking changes in this PR.
  • Check logging

If there are breaking changes, please STOP and consider the following:

• What other modules will these changes impact?
• Do JIRAs exist to update the impacted modules?
  • If not, please create them
  • Do they contain the appropriate level of detail? Which endpoints/schemas changed, etc.
  • Do they have all they appropriate links to blocked/related issues?
• Are the JIRAs under active development?
  • If not, contact the project's PO and make sure they're aware of the urgency.
• Do PRs exist for these changes?
  • If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.

While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
90.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud