Skip to end of banner
Go to start of banner

2022-11-14 Item State Working Group

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Date


Zoom

See Outlook invite - hosted via Duke.

Attendees

Goals

Discussion items

TimeItemWhoNotes
10min

Introductions and settling in

  • We will record meetings, they will be done with Duke Zoom and stored on Google Drive
    • (Note to Erin - remember to enable subtitles)
10min

Overview of Group logistics

  • Wiki space in App Interaction
  • Slack discussions - use #item-status-group (open channel, please join if you are not already in it). Lots of value in us talking about all this stuff in public.
  • Bi-weekly meetings, with adjustments for holidays. Check - does this time slot still generally work?
    • Tentative:
      • Week of November 28th - UI review for Settings and Inventory
      • Week of December 12th - TBD
      • Week of January 9th - TBD
      • Week of January 23rd - TBD
      • Week of February 6th - TBD
      • Week of February 20th - TBD
      • Week of March 6th - TBD
      • Week of March 20th -  TBD
      • Week of April 3rd - TBD


35min

Begin work -

Slide deck:


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 how it works now.
JS: We should codify it in the use case requireements.

5 minWrap ups and any action items

Action items

  • No labels