Recordings are posted Here (2022+) and Here (pre-2022) Slack channel for Q&A, discussion between meetings
Requirements details Here Additional discussion topics in Subgroup parking lot
Attendees: Ann-Marie Breaux Jennifer Eustis Leeda Adkins Mark Arnold Tim Watters Heather MacFarlane Jenn Colt Lisa McColl Lynne Fors Raegan Wiechert Taylor Smith
Follow-up from last meeting
A-M clean up the meeting invite and re-send plus post on subgroup page
Lotus
- Still working on updating Lotus release notes
- Lotus Hotfix Bug created for the job profile problem - may be related to a problem with Holdings Source - still triaging
- Will need a Kiwi HF, as well as Lotus HF and MG fix - also need a script or instructions for how to fix incorrect Source = MARC in existing holdings
- Also Lotus Hotfix Bug for Settings/Data Import panes UI - still in process
Morning Glory
- Morning Glory Folijet and Spitfire planning: dashboard where you can see the current scope and status of Data Import work for Morning Glory
- Completed work:
- Adding Admin notes to the 3 Inventory field mapping screens
- Log refinements: UI for deleting logs (no backend yet)
- POL/VRN matching Backend (no UI yet)
- Inventory Holdings POL connection: retroactive or not? Discussing with Dennis - still TBD
- Current work:
- Backend of deleting logs
- Field protection refinement
- Flow control (to help Single Record Imports and MARC Authority UI deletes not get stuck)
- Analysis of additional MARC-MARC matching refinement beyond what was delivered in Lotus
- Matching from all repeated fields of an incoming MARC to all repeated fields in an existing MARC (e.g. all 035s to all 035s)
- Adding indicator wildcards
- Tangential: will analyze whether there is a way to deduplicate OCLC 035s with same number but different prefixes (seems like it might be needed during import and as on-demand)
Agenda topics:
- Implementers topics list
- Page created: Data Import Implementers Topics
- Add topics to it
- Development questions/discussion take priority; these would be discussion topics when there are not dev topics - could also be addressed at the weekly Import/Export Lab
- Log refinement: finalize a few outstanding questions:
- See PPT here
- See Jira feature here
- Make error details easier to find - stories not yet written
- HOMEWORK: Review slides 9-21: If we want to show more error details on the summary screen (so that user doesn't have to click into the details screen for each error). how could we do that? Several examples of errors from Lotus Bugfest. How could this kind of information be consolidated into something meaningful on the log screen? Please add comments to this wiki page before next week's meeting.
- Cannot be done for Morning Glory; how important for Nolana?
- Navigation from log back to Landing page vs View all page - stories not yet written
- HOMEWORK: Review slides 27-29: Would this be a useful change? Right now users are always taken back to the Landing page, unless you use the browser Back button instead of the "x". If you have filtered jobs on the View all page, you'll lose those filters. Please add comments to this wiki page before next week's meeting.
- Yes - very annoying to lots of libraries - see if we can resolve with a UI change in Morning Glory
- HOMEWORK: Review slides 27-29: Would this be a useful change? Right now users are always taken back to the Landing page, unless you use the browser Back button instead of the "x". If you have filtered jobs on the View all page, you'll lose those filters. Please add comments to this wiki page before next week's meeting.
- Lisa McColl/Lehigh bug
- using a job profile in Kiwi test that they were also using in Juniper, but it sometimes errors in Kiwi; not sure why;
- also an issue for Chicago; is it an issue for any non-Index Data libraries? Raegan/Missouri State also seeing this in Kiwi test or dry run - was a problem in one, but not the other
- documented in this Jira: MODINV-684 - Getting issue details... STATUS It has to do with a property added to instances in Kiwi
- Will be fixed in Morning Glory
- Will be in the known issues for Kiwi and Lotus, and will include instructions or script for how to fix it when migrating from Juniper to Kiwi.
- Question - is reindexing required after the fix?
From Jennifer Eustis (she/her) to Everyone 01:30 PM
That's the same for us in our 5C sandbox
We're on Kiwi HF2
From Lisa McColl to Everyone 01:31 PM
Same for us at Lehigh - "MARC" holdings for source - should be FOLIO
From Mark Arnold to Everyone 01:33 PM
Are we going to need a script to clean these up as well?
From Raegan Wiechert to Everyone 01:37 PM
brb
From Lisa McColl to Everyone 01:38 PM
If we have time Ann-Marie - we have a Kiwi import blocker at Lehigh and I'd like to ask if others are experience what we are. I heard Simmons is and somewhat Chicago?
From Raegan Wiechert to Everyone 01:38 PM
back
From Heather MacFarlane to Everyone 01:53 PM
BRB
back
From Taylor Smith to Everyone 01:54 PM
agreed
From Lynne Fors to Everyone 01:54 PM
Yes
From Mark Arnold to Everyone 01:58 PM
Problem was in dryrun, which unfortunately is the basis for our production environment.
From Jennifer Eustis (she/her) to Everyone 02:00 PM
I have to run to another meeting
From Me to Everyone 02:04 PM
MODINV-684
-
Getting issue details...
STATUS
From Taylor Smith to Everyone 02:05 PM
have a good one
5 Comments
Jenn Colt
For the log question on errors - what I find is that in practice I just need three categories - "too many matches", "no matches", and then all other errors. For me all of the "other" errors can just be reviewed when clicking through to the json. What I am really wanting from this is to be able to distinguish between things that are matching issues and things that are actual errors.
Leeda Adkins
On the error description, would there be room for a 3-word description, such as "found multiple matches" or "retry number exceeded"? Similar to using the first words of the errors, only capturing the most descriptive words of the error.
Raegan Wiechert
+1 to Jenn Colt
Given the relatively small number of records that MSU imports, having to click into the few error records is not a big deal. I would much rather have time and effort put into either making the errors more user friendly for those of us who do not do programming all day every day (or ever) or making a translation table of "if you have this error, this is your solution."
Jennifer Eustis
We're not on production yet. It would be great to distinguish user or user preventable errors vs others. For example, I would like to see language for multiple matches - error, no matches -error, marc invalid incoming file errors, possibly optimistic locking, and then just errors. So this echoes what Jenn said above. I think that for the other errors it is just so difficult to understand what is going on and to provide some guidance as to language to use. For example, no record is hard to know what's happening; I've had cases where this is a multimatch issue and others where it is an incorrect data type. Another thing that would be helpful is that for those other errors it would be great to get information quickly on what is going on. Another idea is to be able to see the actual log part. In Aleph, we have a place where we can see the log file which gives details on all the steps of that Data Import job. If you want an example, I can send that to you.
Taylor Smith
I appreciate the current system telling you what aspect the error occurred in (SRS, Instance, etc), but with such unreadable error codes, I don’t really know what to do with that information. I very much agree with the points above as to having some broad categories for erroring. Alabama frequently does large batch loads, so being able to see if a record had a ‘matching error’ and ‘technical error’ in the batch results screen would be very helpful for getting a picture of what went wrong without having to click on every individual record. The more specific and human readable the better, but I also have no idea how much time and effort tracking and categorizing those errors would take on the back end.