2020-02-24 Resource Access Meeting Notes

2020-02-24 Resource Access Meeting Notes

Date

Feb 24, 2020

Attendees

  • @Andrea Loigman

  • @Brooks Travis

  • @Schwill, Carsten

  • @(OLD ACCOUNT) Erin Nettifee

  • @Emma Boettcher

  • @William Weare

  • @Joanne Leary

  • @Cate Boerema (Deactivated)

  • @Brian Arrigo

  • @Monica Arnold

  • @David Bottorff

  • @Rameka Barnes

  • @Jana Freytag

  • @Anya

  • @Kimie Kester

  • @Cheryl Malmborg

  • @mey

  • @Thomas Paige

  • @Allison Estell

 

Discussion Items

Time

Item

Who

Description

Goals

Time

Item

Who

Description

Goals

5min

Housekeeping 

@Andrea Loigman

 

  • Notetaker - @David Bottorff

30min

Item State

@Emma Boettcher

Custom item statuses (Availability)

Determine what needs to be configurable about custom item statuses
Slides
Wireframe 

25min

Item state

@Emma Boettcher

Custom item statuses (Requests)

Determine how custom item statuses should interact with configurable requests whitelist

 

Meeting Outcomes

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Reasoning

Link to supporting materials

Comments

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Reasoning

Link to supporting materials

Comments

E.g., loans, fines/fees

Name

 

Clearly stated decision

  • Because...

  • Because...

e.g. mock-up, JIRA issue

 

 

Notes (submitted by David Bottorff)

Custom Item Statuses - exploratory meeting

  • Ability to create a form that makes the usual decisions we make in the SIG to configure a new status

    • How it receives the status

    • system response to check an item in

    • system response to check out an item

    • system response to request an item

  • This discussion is not looking to make a suggestion regarding prioritization, etc.

  • How it receives the status might only be manually selectable or batch editable until workflow engine

  • Chicago needs item statuses regardless of whether there is a workflow engine or not

  • Duke feels most custom item states are not needed unless in process and needed for states are not there

  • needed for and in process states are probably a year away

  • David Bot - feels as though MM needs to be consulted on this

  • New book status that automatically gets removed when an item is checked out/checked in (Sierra)

  • Erin - worried that we lose the specificity of the model if we allow custom item states

  • Emma - there is no way FOLIO ships with all of the item states that every library is needed

  • Cheryl - what may be in scope is to create item statuses that can be mapped to system responses until three state model is available

  • Andrea - seems bare minimum is check out, request, check in

  • Emma - can you mark this missing, withdrawn, etc.

  • David Chicago - since we're stuck with hard-coding for existing item statuses, this seem reasonable

  • Simple form that sets up item status settings, which could then be built out to work for built in item states

  • Emma - absent of a workflow engine, relying on existing logic at check-in, etc. is all FOLIO can do

  • probably another option needed to allow or not allow check in or check out

  • cases where item status should not change as a result of check-in

  • Would the request whitelist still exist elsewhere or should they be combined into the item state screen

  • Erin It seems reasonable to add whitelist features to regular item states in addition to custom item states

  • Cornell concerned about a need for "requested" that is separate from checked out

  • Should we create a master list of item statuses, that includes those that we will not treat as item statuses

  • deadline to populate item status list before next Monday's meeting