...
Topic | Who | Meeting Notes | Related Jira | Decisions and Actions | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Announcements: Results of latest MM UAT to be shared at MM SIG this week. | These will be shared with MM at tomorrow's meeting. | |||||||||||
MODDICORE-358: Data import sorts protected fields out of order after update
| 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. |
|
| |||||||||
MODDATAIMP-879: Data Import removes duplicate 856s in SRS
| The following details were confirmed with the dev team:
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 deduplicate duplicate fields for any repeatable fields, it the system should dedupdedupe. If an existing and incoming record don't have exact duplicate fields for any repeatable fields, then FOLIO should be dedupedthe system should not dedupe. |
|
| |||||||||
Order import field mapping profile out of sync with Quesnelia changes to the order record | 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. |
| ||||||||||
Notes from previous meetings... |
...