2020-04-06

Agenda

• Review scope of item status

• Change item status from item record (manually)

Notes

Note-taker:  Susan Ponischil

What is the scope of this group and what is item status and especially the particulars of how to implement those things. 

Introductions:

Magda Zacharska, at EBSCO for 7 years - started as FOLIO software developer, has since January the product owner of cip2 implementation - simple type level request, in Fall joined Metadata Management group tasked with data export functionality.  1st version was launched this quarter

Rosalyn Raeford, FOLIO’s resource description department project manager, department includes original cataloging and processing, also on a FOLIO implementation team on workflow group - Jacquie Samples asked her to be on our group

Review Scope of Item Status

Item Status 3 Part Model:  [see https://folio-org.atlassian.net/wiki/display/FOLIOtips/Item+State+in+FOLIO ]

Values:

* custom item status is a way to manually add more description but is not used by every implementer, i.e. long missing, checked out, checked in, requested, etc.

Change item status from item record (manually)

Currently implemented only when there's no other way to change status

• Missing, withdrawn (planned)

• All other values for item status have processes associated with them

Alternative: an item can have item status changed (with exceptions)

• Except if item is loaned?

• Except can’t change to a status for an item that’s loaned?

• Other exceptions?

  • Discussion about Dummy items i.e. bandwidth, analytics, print repositories

• Is item status necessary for dummy items?

• What about workflows?

  • Dummy items would work with analytics

  • Dummy items would not work with boundwidth ; working with separate items

• Would custom status be a solution?

  • *Suggestion to ask Inventory Development to support parent/child records

  • Long term dummy records will not be available by implementation - we need to explore solutions

  • Emma suggested replacing the Planned Value “Long missing state” with “Custom item state”

Specifications for customized item status

• Item status can impart meaning to person looking at it, ui and staff interface

• Ability to indicate yes/no for the following actions

  • checkout

  • checkin

  • request

• Considerations include:

  • Permissions - who can make changes?

    • Consider data clean-up

    • Some states should be protected, i.e. order records

  • System developers concerns about permissions and breaking interdependencies

  • Promoting development of custom item states

• *Suggestion to change status permissions to open with exceptions, i.e. lost and paid

Preferred process?

1. Anyone can change item state

2. Unless the logic says otherwise, you can change an item state

Considerations?

• How would you want to be able to change them?

• Which item state would we want to be able to manually change?

• Some states are different, i.e. lost and paid

• Item status can be changed in small number of cases: checked out, claims returned, declared lost, assuming checking the item in resolves the conflict in the system fees.

• Some states are different, i.e. lost and paid

• Things loaned to patron should have item status locked down

This week we talked about changing item state from “from” to “to”

Next week we’ll explore:

• Changing item status from “to” to “from”

• Permissions

• Custom item status

• Customizing item statuses

Zoom recording

Zoom recording

To-do

ACTION:  (Emma?) When setting up configuration ask questions about specific behavior around fines and fees        

ACTION:  Recommendation to lock permissions for users of orders app.  Martina will take to RA group