| 35min | Begin work - Slide deck: | Widget Connector |
|---|
| url | https://docs.google.com/presentation/d/1XE08g37_nmyooQQ6dBgtMryDiLhBQmmNF3_IO54dfI4/edit?usp=sharing |
|---|
|
|
| Use case discussion: Examples for custom item statuses. JS: missing to lost process - signifying search process for an item.
AL: differentiate between loan and loan to interlibrary loan - where you would not want to recall items out to ILL, but would if they were out to a patron
TT: BorrowDirect loans. Book repair. Extension to the "Checked out" status - e.g., "Checked out - Recalled" or "Checked out - Hold requests"
AL: Is Book repair an item status or a needed for?
BV: Circulating uncatalogued materials -- have a state that says "Circulated uncataloged" that would allow no requests, no subsequent circulation. Right now we rely on circ notes, which is not ideal.
AL: Meaty question is what controls the behavior - the item status, or the needed for?
EN: Not sure if it would be controlled by process, or by needed for.
JS: Agrees with Bill as good example.
BV: Pandemic emergency response as another example. CDL-adjacent. Need to change
JS: Custom item status for shared print workflows.
MC: In OLE we had the ability to add custom item statuses, and we leveraged that for preservation workflows or for when we considered
replacement of items. The progression implied that things had gone through workflows. Others - example of item needed for
an exhibit. Remote storage and special collections? Stuff that needs approval for paging.
Julie: We're using fake borrowers to indicate a workflow. Not sure if a proliferation of item status is that right way to compensate that. Being able to edit the existing item status might be as important. You don't want to have a proliferation of statuses where you end up with different people at libraries using things in different ways. MC: This is not so much about defining use cases, it's that FOLIO needs the flexibility for a new use case we haven't anticipated yet.
AL: Item status is meant to be changed by workflows --
JS: Some of what you have can be changed by bulk edits.
EN: Yep - we have a model that combines both.
MC: OLE example - they were protected statuses that had to be changed using workflow, and there were others that were custom and could be manually toggled.
TT: On order - limit request types for on order items - not allow recalls or holds prior to receiving
JS: Asking about long missing - are holds allowed for that? EN: No.
AL: We'd want to disable recalls for CDLs.
JS: For some examples of loans, we wouldn't want to be able to renew the loan
TT: Unbound items, we might not want renewals because we want to have it back for binding.
BV: A custom status that indicated something was onsite and in process for ordering which could trigger a rush recall. Might want it to behave differently than generic "On Order". On Order - delayed (missing FedEx box.) Cause it to invalidate holds. Interesting.
TT: we may have to carefully think about how these statuses intersect with circ rules.
EN: Circ rules should win. That's Behavior should work how it works now.
JS: We should codify it in the use case requireementsrequirements. |