2024-03-21 Metadata Management Meeting notes

Joint meeting with RA SIG as continuation from 2024-02-08 Metadata Management Meeting notes

T. Trutt (TT) - Sharing of mockups 

Tried to figure out a way that half of functionality belong to Inventory, half to circulation

Circ Rules - instead of having the three different parts, he suggests just having the item Process

Phase 1 – Get Process field created in Inventory

Phase 2 – add a checklist capability to a Process (e.g. pull from stacks, check for missing pages, etc) 

Processes can be reordered  – processes automatically added as checklist items

Phase 3 – Allow user to change an item status with the fulfilment of process, adding a ranking layer so systems could balance multiple processes (figure out priority automatically)

Processes would live in Inventory and not effect Circulation

Questions:

D.Bottorff - Not understanding how this would not effect Circulation?

TT: This would not effect check in/check out; the Process part is just describing what is happening to the item, everything else is handled by the actual item States

C. Malmborg: Sounds like the Process setting in the first Phase is telling you what you want to do with the item which means you may have to put a request on the item, or change the item status in Inventory.  Just wondering if it is actually worth starting at Phase 1 and installing as a change to the system or if you want to wait until Phase 2 before putting in a change to Folio?

TT: That is a possibility to combine Phase 1 and 2 (was thinking Phase 1 would be a quick way to get Bindery needs in place)

D.Bottorff: Regarding Bindery-- seems like a very manual way of dealing with sending things to Bindery when you could just wand in a bunch of barcodes to send things off to Bindery.  Afraid this won't get used and doesn't want development time going into something that doesn't get used.

TT: If you are in another part of the system you could add these processes as well (not just bindery use case)

C. Malmborg: If there isn't something in the system that isn't deleting the processes somehow then you will have a lot of old data that needs clean up.

TT: Once a process is completed should it be stored on the record for later reference, should it be held for two years and then deleted?  The other part of this was the Item statuses and reworking how they work:

Right now statuses are a drop down, would suggest those being a modal; at the same time add a settings page that have the built in status that allows you to change the display names so that no internal workings of Folio are affected.  However, item statuses would be decoupled from the circ logic and would become a descriptor on the item.  Instead of being hardcoded they would become a filter in the circ rules.  Do you want some of these hardcoded or do they just become circ rules?  Item statuses would remain metadata on the item but the policies would live on the circ side.  

David: Where would figure out if status is "loaned" you cannot change item status except thru circ processes.  

TT: Could see that as two separate policies–a policy in circ or in Inventory, checked out, lost, etc. still remain protected and can only be changed thru a certain process.  

C. Malmborg: If you start considering custom item statuses which we really want, it makes sense to make them a filter in the circ rules.  So probably need some statuses that generate error if it has a circ rule.  Seems like a big architectural change.

M. .Canney: Any consideration to building in notifications into the process (if process requires hand off from one unit to another for example)

TT: Could see that as a possibility.  Also, some people would not use any of the internal processes checklist but would prefer the external workflows app.  It might be one of those things where if you need this much complexity you might need to use the external workflows app.  

Item states and Process states are two different lists. 

D. Bottorff: Item is loaned, you need to route it for cataloging review. How does it trigger complicated scenarios?

TT: Request app would use the item states to process requests; other possibility: a request always trumps any other process.  Phase 3 of process: route to this location – add to checklist in appropriate order.

D. Bottorff: Seems like this only becomes useful in Phase 3.  So, is this really worth separating into Phases?  

TT: Was breaking into Phases considering Dev time and spreading out into multiple flower releases.

F. Hemme: Are the checklists stored on the item record in Inventory as well?

TT: Yes, in the tenant settings as a template and so template is stored either in the item or separately.

Will the item state values still be text or are you also proposing to change them to reference data with UUID's instead? 

TT: Right now item states are text (a key); customs could be stored in a database with UUID but would want to talk to Devs about best approach.

D. Bottorff: Thinking about custom item states: is it worth exploring middle ground all aspects--set of checkboxes within an item states when you create it–hardcoded checks could be there and then there could be other states like loan that are not editable (can this be manually changed: yes/no).  Provide flexibility and put less pressure on circ rules.

TT: With the custom item states as you move along you need to be able to delete things but you don't want anyone to delete certain states. My worry is with going to that extent you are duplicating the circ rules anyway but I realize there are certain thing where you don't want the circ rules to override basic rules that will break the system.  Allowing lost item state in circ rules and allowing you to place a request on them but only by certain groups.  Ensuring nothing breaks but also allowing more flexibility.

C. Malmborg: If you had to put the item states in the circ rules how difficult it might make it for people to write their circ rules.  Maybe something like a hybrid circ rules–if you don't put in an item state there would be a default but then if you put in an item status that could be added to the default set so that your ex of putting a hold on a lost item could be added to the logic.  This will require a lot more thought.

L. Fors: Would this be discoverable in the Lists App? Or some other reporting method on where an item is in a process?

TT: I don't see a reason why the list app would not be able to recognize these.  Could result in a lot of breaking changes.

C. Whitt: What is the time frame for introducing this new work? 

TT: This will likely be pushed out 2025/2026 when Dev teams are not in as much of a time crunch.  Open to suggestion of how to expose this more.  

C.Bottorff: Would probably also need dates of Processes (ex. these things got sent to the bindery last month, they should be back by now).  Could other Apps leverage this data (like the Bindery App)?

TT: Yes, ensuring that the data is there and easily accessible from other Apps is great, and having a way to search directly from Inventory is a necessity.

C.Witt: LDP and MetaDB, it is not set in stone that not everyone can have it–just ask your hosting provider and it can be temporary until the List App is available.

Todays PC meeting will be the first meeting with a different time, more friendly to FOLIO folks in the Asia Pacific region! Instead of the usual 10am ET timeslot, the meeting will be at 8pm ET. The main topic is an Application Formalization overview from Tod Olsen and Jenn Colt of the FOLIO Tech Council. Here is the agenda: https://folio-org.atlassian.net/wiki/spaces/PC/pages/103940186/2024-03-21+Product+Council+Meeting+Notes+8pm+ET+quarterly+Asia+Pacific+Friendly+time

Jennifer Eustis

Jennifer Eustis