- Morning Glory Folijet and Spitfire planning: dashboard where you can see the current scope and status of Data Import work for Morning Glory
- Folijet Current Development Board
- Folijet Current Bug Board (will be merged back into the dev board as of next sprint)
- Order field mapping profile questions
- Lotus HF3 Hot fixes for Data Import:
- Completed and officially released
- Morning Glory Bug fixes for Data Import:
- View complete list here
- View unclosed bugs here (should be completed by the end of next week)
- Some issues have different solutions for Lotus HF versus MG Bugfix versus Nolana, e.g. - MODSOURCE-509Getting issue details... STATUS versus - MODSOURCE-528Getting issue details... STATUS , or - MODSOURMAN-841Getting issue details... STATUS versus - MODSOURMAN-843Getting issue details... STATUS ; fixed Lotus first, now MG in progress
- - MODDICORE-275Getting issue details... STATUS : tested on Snapshot, and seems to be working properly; would be good to have someone else test it on Snapshot and confirm, before we release it to MG BF
MODINV-709Getting issue details...
- Separate profiles for 1) match by POL and update Inventory records and 2) match by VRN and update Inventory records work properly
- Aiming to fix in Nolana; use separate profiles as a workaround for MG
- Nolana planned Bug Fixes for Data Import:
- Deleting import logs via API: (Carry-over from last meeting)
- Available as of Morning Glory
- There was a Slack question recently about being able to delete Import logs via API as of Morning Glory. We have added some documentation in the Data Import tips and tricks. Please see this page: 4-Data Import Logs, in the last section: Deleting Import Logs via API.
- The log data can be queried and compiled via the LDP; what happens with that when 1) the log is marked for deletion (via the UI or API) and then 2) completely deleted in the next 24-hour sweep?
- Can the log info still be queried via API when it has been marked for deletion but not yet deleted?
- Jenn: Cornell started playing with log info via API, but stopped until they go live on Lotus
- NOTE: This has nothing to do with the instance "mark for deletion" discussion
- 24 August 2022 (last meeting before WOLFcon)
- Combined meeting with quickMARC Subgroup, to go over MARC Authority and MARC Bibliographic headings linking (only manually for now, not via DI)
- 31 August 2022 (Cancelled due to WOLFcon, or maybe have the mtg and cover from screen 6 onwards - TBD)
From Julie Brannon (she/her) to Everyone 01:01 PM
From Jamie Jesanis to Everyone 01:04 PM
You may have missed me, I came in late
From Jennifer Eustis (she/her) to Everyone 01:10 PM
Maybe we can do that in lab this thurs.
From Christie Thomas (she/her) to Everyone 01:20 PM
From Julie Brannon (she/her) to Everyone 01:20 PM
I prefer the grey-out approved checkbox if its not required in settings, yes
From Dung-Lan Chen to Everyone 01:31 PM
Yes, it seems clear to me what you explained, Ann Marie.
From Julie Brannon (she/her) to Everyone 01:31 PM
Seems clear and I appreciate that you're showing us the setting value for the PO lines limit right here in the mapping profile 👍🏻
From Christie Thomas (she/her) to Everyone 01:34 PM
We have never broken out POs in that way, so I think we could live without it.
From Dung-Lan Chen to Everyone 01:34 PM
not for us!
From Julie Brannon (she/her) to Everyone 01:35 PM
No problem at Duke since our PO lines limit is set to 1
From Jennifer Eustis (she/her) to Everyone 01:38 PM
Is vendor a mappable field?
From Christie Thomas (she/her) to Everyone 01:39 PM
Yeah, we need to do that. We are currently mapping it with the Lehigh tool.
From Jenn Colt to Everyone 01:40 PM
we have like a $hAMAZON and that works in Lehigh
From Julie Brannon (she/her) to Everyone 01:40 PM
So will an error occur if the user id used to run the import isn't assigned to an acquisition unit?
From Jenn Colt to Everyone 01:43 PM
Same, otherwise we need a bunch more profiles
This is about error handling though. Lehigh will return errors if you try to give a non-existent vendor, fund etc.
Those errors are from the orders API
From Christie Thomas (she/her) to Everyone 01:43 PM
Yeah, we get errors when there is bad data in the record.,
I would not want a generic vendor used if it failed. I would want the record to fail to create an order.
From Jenn Colt to Everyone 01:43 PM
From Dung-Lan Chen to Everyone 01:45 PM
I assumed we are creating different mapping profiles for different vendors, not true?!
From Jenn Colt to Everyone 01:45 PM
that's not what we do
From Christie Thomas (she/her) to Everyone 01:46 PM
That is not what we do either.
We have one mapping profile
even the order type is mapped (Purchase vs Approval plan)
From Jennifer Eustis (she/her) to Everyone 01:46 PM
For the 5C, we have a vendor that has up to 5 different account numbers and hence the same vendor entered up to 5 times with the prefix for each school
From Christie Thomas (she/her) to Everyone 01:47 PM
We can have more profiles for one, but not one for each type of order that we receive from each vendor. That is not an amount of work that we can absorb with our staffing levels.
From Jenn Colt to Everyone 01:47 PM
We don't seem to put the account code on the POL
From Leeda Adkins to Everyone 01:49 PM
We have created differ PO suffixes for our sublibraries, one for main, one for divinity, etc. Can we have a file with orders destined for Perkins and orders destined for Divinity this way?
From Jenn Colt to Everyone 01:50 PM
Right we have a united mapping for this data across vendors
From Jennifer Eustis (she/her) to Everyone 01:51 PM
+1 to Christie's concerns
From Christie Thomas (she/her) to Everyone 01:54 PM
We also map the bill to and ship to.
We provide the address name
From Jenn Colt to Everyone 01:55 PM
we do too
ours isn't that elaborate, only two, but we do map it in
From Dennis Bridges to Everyone 02:00 PM
Sorry I have to run
From Jenn Colt to Everyone 02:00 PM
have to go too