Page Comparison

MODDICORE-358: Data import sorts protected fields out of order after update

• Discuss this ticket again and align on expectations

Current behavior is that for protected fields will appear before the changes. See issue for examples.

Should the expected results are that the incoming field should appear next to the protected field?

There are edge cases where the marc fields might be out of order on purpose. Do we need to address when fields are out of order?

Is our expectation is that conforms to numerical order or fields remain in same order that they were?

Sometimes the order matters depending on who you talk to. Perhaps the order respected should be the one of the incoming record. If this is the case, then does the protected field come before or after the new incoming same field.

Proposal: The protected field of the existing record should be placed either ahead or behind of the same field number in the incoming record.

•  Ryan will take the proposal to development team and then make a choice as to before or after.
  

MODDATAIMP-879: Data Import removes duplicate 856s in SRS

• Review new details around when deduping occurs.

The following details were confirmed with the dev team:

• Nothing is Deduped on CREATE job
• Deduplication only occurs for repeatable fields as part of UPDATE jobs.
• If field values are different, then new field is added to record and does not overwrite the existing values.

Does the value include the subfields or is it just the subfields and the value?

When Christie tested this the subfields were included.

Deduplication of the instance and holdings record is different from the marc record. Understanding when we want the MARC record deduplicated is needed. Data shouldn't be removed from an incoming marc record.

Proposal: If an existing and incoming record has duplicate fields for any repeatable fields, the system should dedupe. If an existing and incoming record don't have duplicate fields for any repeatable fields, then the system should not dedupe.

•  Ryan will take this proposal back to the team.
  

Christie Thomas

In Acquisitions SIG, there is a new property for Donor. This is an accordion. The mapping needs to be updated to be able to map to the new Donor property rather than the deprecated one.

How do we validate reference? For the Donor there is a name and a code. We would like to have consistency with mapping syntax would be great. Almost all the reference data has a name and a code.