Page Comparison

...

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:

1. 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
2. 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: Understand 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?
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
4. 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?

...

From Nick Cappadona to Everyone:  01:24 PM

(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!

...