2021-06-09 Data Import Subgroup meeting

Recordings are posted Here

Slack channel for Q&A, discussion between meetings

Additional discussion topics in Subgroup parking lot

Attendees: Ann-Marie Breaux (Deactivated) Jennifer Eustis Nick Cappadona leeda.adkins@duke.edu Monica Arnold leeda.adkins@duke.edu Jenn Colt Lloyd Chittenden Lisa McColl Christie Thomas Timothy Watters

Agenda topics:

Current development: Sprint 116:
1. Finalizing Juniper releases, Iris Hotfix 2 releases, Onboarding 5 new staff (new scrum master, 2 BE devs, 1 FE dev, 1 tester)
2. Quick review of the outstanding bugs
Field protection fixes: review examples. Is this correct and complete?
1. CT: Is it problematic when there are multiple actions in the job profile that update SRS? Lisa - same with Chicago
2. CT: The update actions are all acting on the SRS in different ways, and you never know what you will get
3. Difficult to have implicit updates for instances or SRS when there is 1 explicit SRS or instance update
4. NC: Would be good to understand when SRS records are having generation incremented, new row added; why is the MARC Update action the only one that doesn't create a new SRS record and increment the generation?
5. If a profile has update instance (to update cat date) which has an implicit update MARC, and also an update MARC (with implicit update instance) that has field protections, will the field protections be honored by the update instance? (A-M to check with devs)
6. Most important part is 1) making sure this is clearly documented, and 2) preferably, consistent, and 3) preferably, that implicit actions are acknowledged somehow in the import profile
  1. QM edit: increments
  2. Import MARC Modify: increments, we think
  3. Import MARC Update: does not increment
  4. Import Instance Update (implicit MARC update): increments
7. CT: Maybe have the import profile figure out all the changes to the instance at once, and all the changes to the SRS at once, and then make all the changes at once, even if they are in different steps
8. CT: Really important to have the ability to manage Instance, Holdings, Items without storing an SRS MARC
  1. If there is an SRS and a related instance, and updating the instance, then instance has to stay in sync
  2. If there is NO SRS and you use an imported MARC to create or update the instance with source = FOLIO, and not store the MARC Bib
9. Some of this has been in place for a while, but just now surfacing, as more people are testing and preparing to go live
10. If you include field protection in a job profile explicitly, is it working as expected? (other than having to include it explicitly) - maybe do some testing around that?
11. After this, follow-on work to override field protections (once they are working properly) and update individual SRS fields
12. Probably will not be done by Iris Hotfix 2, needed in an Iris Hotfix 3?
Has anyone created successful MARC to Instance Identifier matches for 010, 020, 022, 024, 035, 9xx fields? If so, it would be great to see examples. Developers still need to work on some identifier matching bug fixes
Bug when creating Instances instead of matching/updating them: MODDATAIMP-427
1. Review the bug and confirm preferred action
2. Not planned as an Iris hotfix since it's an edge case. Needed as a Juniper bugfix? Or can it wait until Kiwi release?

HOMEWORK: (Iris bugfest is probably the best env, or a local Iris sandbox env)

If you include field protection in a job profile explicitly (Update MARC/Updates - with no field protection overrides), is it working as expected? (other than having to include it explicitly)?
Has anyone created successful MARC to Instance Identifier matches for 010, 020, 022, 024, 035, 9xx fields? If so, it would be great to see examples. Developers still need to work on some identifier matching bug fixes

Zoom Chat:

From Nick Cappadona to Everyone: 01:24 PM
MODSOURMAN-494 - Getting issue details... STATUS

(calling attention to Kateryna's 2021-06-09 comment)

From Christie Thomas (she/her) to Everyone: 01:32 PM
I think you are right, Nick!

From Jenn to Everyone: 01:36 PM
yes exactly

From Christie Thomas (she/her) to Everyone: 01:36 PM
According to the logic that is being used, any time the change is made to the record it is a “new record”
Consistency is the most important thing, I agree.

From Jennifer Eustis (she/her) to Everyone: 01:36 PM
+1 on consistency

From Christie Thomas (she/her) to Everyone: 01:38 PM
Intentionality is good, too.

From Christie Thomas (she/her) to Everyone: 01:43 PM
But what about a situation where we only have FOLIO records?

From Jenn to Everyone: 02:00 PM
when i tried them before repeating fields was the big issue

To do's

Confirm Rancher environment for Data Import/quickMARC testing (Khalilah and Ann-Marie) - IN PROCESS
Data Import FAQ updates (Ann-Marie) - IN PROCESS
Make videos confirming the following scenarios
- For import profiles that match on Holdings or Item IDs (and doesn't need to affect the Instance), make a video showing what happens to SRS MARC (Ann-Marie)
- For a brief MARC updating the suppress status on a group of instances. What happens with the SRS MARC (A-M)
Talk with Kimie and see if ideas for updating the UI for implicit (A-M)
If a profile has update instance (to update cat date) which has an implicit update MARC, and also an update MARC (with implicit update instance) that has field protections, will the field protections be honored by the update instance? (A-M to check with devs)
Most important part is 1) making sure this is clearly documented, and 2) preferably, consistent, and 3) preferably, that implicit actions are acknowledged somehow in the import profile (A-M confirm with devs and document)
1. QM edit: increments
2. Import MARC Modify: increments, we think
3. Import MARC Update: does not increment
4. Import Instance Update (implicit MARC update): increments