Page drafted by (OLD ACCOUNT) Erin Nettifee prior to her leaving the project in August 2023

Reference links

Item JSON Schema: https://github.com/folio-org/mod-inventory-storage/blob/master/ramls/item.json

Item status is an enumerated list as an attribute in the item record

Item State epic: https://folio-org.atlassian.net/browse/UXPROD-1321

Jiras with "item state" label: https://issues.folio.org/issues/?jql=labels%20%3D%20itemstate

Documentation on docs.folio.org: https://docs.folio.org/docs/platform-essentials/item-status/itemstatus/

Is it "item state" or "item status"?

Basically it's both. Originally in development, it was described as a "three-part item state" as seen in UXPROD-1321 and other places. However, in the inventory UI, it was labeled as "item status". ((OLD ACCOUNT) Erin Nettifee doesn't know why, but others might.) It was judged as not a priority to re-label it as "availability" prior to the development beginning on the next part of the three-part model. Since that hasn't happened, it's been referred to mostly as "item status".

Product owner history

The primary product owner for developing the item status model was Emma Boettcher, who was the PO from joining the project until Fall 2020. Erin Nettifee and Charlotte Whitt both did work in this area after Emma's departure, but neither were officially the product owners for the area

Feature history

Item state was conceived at the very start of the FOLIO project and has never been fully implemented. At the point of writing this document it might never be implemented as it was originally conceived, but information about the original design is important to understanding what was desired and how that informed the development of core FOLIO workflows.

Essentially, item state was conceived as being of three parts.

Availability - information about whether an item could be loaned, whether it was in the library or out of the library, on the shelf, etc.
Needed for - information about processes that the item is needed for - essentially like placing a process request to have an item brought into a staff workflow.
Process - information about a workflow that an item is currently in

The implementation in FOLIO began with availability, since that was the minimum need to enable circulation workflows. Basic availability values were created by Emma with the RA SIG and implemented as an enumerated list outlined in the item schema: https://github.com/folio-org/mod-inventory-storage/blob/9b7b8fc31befc335629f8d38e13e647822f7c8c6/ramls/item.json#L245

In the FOLIO UI, it is labeled as "item status", but the values that are currently available are Availability values:

Beyond the implementation of the values currently listed in the schema as availability - labeled as "Item status" in the UI - no further development has been done. The reason for that is a combination of PO resources (with Emma's departure, and no one being able to step up and fill that role), and developer roles (Prokopovych maintained mod-inventory and mod-inventory-storage, and gradually lost staff over the course of the pandemic until it was closed out.

Largest challenge - figuring out how to change the data model to move forward, if possible

The biggest challenge to integrating the planned three-part item state has to do with the thin thread approach taken to get early adopters online.

By deciding to put the item status values into the item.json schema, instead of building them out as their own setting reference record like material type or loan type, you are restricted in adding or customizing item status behavior. In order to add an item status, you'd have to edit the schema and restart mod-inventory-storage. That's not a feasible approach for a production library.

In Fall 2022, (OLD ACCOUNT) Erin Nettifee wrote this wiki page: Item Status as Reference Records - UXPROD-1927 as an outline of the problem faced by the project. Essentially, in order for item status to be able to be extended, the underlying data model needs to change, and item status needs to be pulled out of the item schema into its own reference record.

This work would need to happen prior to anything being able to move forward with custom availability, needed for, or process.

Attached to UXPROD-1927 are a number of stories that (OLD ACCOUNT) Erin Nettifee created in the 2022-2023 year to try to begin to capture some of the work that would be needed. The stories are mostly UI related as the backend stories would have to be done by the appropriate development teams, and there was no indication of when that work could be considered.

Browser not supported