...
Attendees
Darsi Rueda jpnelson Tod Olson Carol Sterenberg Jeff Fleming Ian Walls
Meeting Link
- https://zoom.us/j/204980147
- password: folio-lsp
...
Time | Item | Who | Notes | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Migration demo for hbz | Ingolf Kuss | Do on Oct 17 so it can be announced in the agenda and get more participation | |||||||||
5 | Optimistic locking |
Do other systems have optimistic locking? Koha no, Symphony no. Other sites say it happens more regularly (and this is why they wanted it). | |||||||||
20Migration | updatesMigrating loans | (Tod) UChicago went from Ole db to locally hosted FOLIO db. Backward engineering how data had to be in FOLIO for the loan to be in the same state. Not really a fan of that approach, although it avoided some problems (and was maybe faster). In retrospect, not a terrific use of time. (Jeff) Duke: checkout-by-barcode, then circulation-loans with a PUT to correct the due date. Otherwise would automatically go to lost. Depending on certain status, does claims returned. (Does a FOLIO claim-item-returned). Bywater goes straight to the storage layer, cuz small scale. When comes to notices, they send on demand notices as a follow up to the migration. Ian has a workflow, given a set of loans, send notices in a given template. Can set the #of renewals when doing this. Needs to be connected to a policy that allows that number of loans (but only in a “this is right” sense, the db will let you do it). Having to turn off notices/email isn’t an issue with the storage approach. | |||||||||
Migration status reports | Stanford going back to fix issues reported during QA process. Changing our strategy, used to be “load a library at a time” but now going to redo and do “all holdings/items on an instance.” Will redo our full load this week, and will load lots to see how we scale. Stanford going “barcode free” on user cards/records. But FOLIO requires a barcode for checkout. We’ll put the “chipID” of the card into the user record instead. No validation on user barcode filed per Ian. Jeff/Duke working on loading marc holdings. There’s an issue with how they had their locations set up. With dashes in-between, quickmarc doesn’t like this. (Also problem in matching in Data Import. Has problem matching on location if permanent location has a dash in it.
Jeff: has been working on requests. Not going to migrate fines at Duke. Next he’ll be looking at closed orders, but not through api. Instead will send them on to IndexData to do. Ian: most sites don’t do fines, if they do they bring it over as a static fine, not try to tie it to a loan. Sometimes tie it to an item. The amount of time to migrate fines, how much $$ does that take vs how much all those fines are worth? Tod: UChicago migrated fines. (David Bottorff has details.) | ||||||||||