Item states (status) (UXPROD-1321)

[UXPROD-1535] Item status: Create interface to create, update and deactivate item statuses in Inventory Created: 14/Feb/19  Updated: 08/Feb/24

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Item states (status)

Type: New Feature Priority: P3
Reporter: Emma Boettcher Assignee: Thomas Trutt
Resolution: Unresolved Votes: 0
Labels: itemstate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by UIIN-1148 Item Status: Inventory - Settings - C... Open
is defined by UX-369 Mockup for CRU custom item statuses Open
is defined by UIIN-1146 CRU custom item status values In Refinement
is defined by UIIN-1170 Customize item statuses: Discovery di... In Refinement
is defined by UIIN-2268 Customize item statuses: Item status ... In Refinement
is defined by UIIN-2269 Customize item statuses: Designate It... In Refinement
is defined by UIIN-2286 Customize item statuses: View-only pe... In Refinement
is defined by UIIN-2287 Customize item statuses: Create, edit... In Refinement
Gantt End to Start
has to be done before UXPROD-2606 Item status: Check in - Customize beh... Draft
has to be done before UXPROD-3897 Item status: Inventory - Customize it... Draft
has to be done before UXPROD-2635 Item status: Orders - Customize item ... Draft
has to be done before UXPROD-3653 Item status: Requests - Customize ite... Draft
has to be done before UXPROD-3860 Item status: Checkout - Customize ite... Draft
has to be done before UXPROD-3928 Item status: Receiving - Customize it... Draft
has to be done after UXPROD-1927 NFR: Using reference records for item... Draft
Relates
relates to UXPROD-2636 Item Status: If an item status is mar... Draft
relates to UXPROD-3935 Item Status: If an item status is mar... Draft
relates to UXPROD-1373 Tenant-Level Setting for Supported Re... Draft
Release: Not Scheduled
Epic Link: Item states (status)
Estimation Notes and Assumptions: Assumes have made decisions about how configurable states should work in the backend
And have implemented migration of records during module upgrades
The request white list will need to be configurable, in order to accommodate custom states
Kiwi Planning Points (DO NOT CHANGE): 64
Rank: Chalmers (Impl Aut 2019): R2
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R4
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R3
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: Leipzig (Full TBD): R1
Rank: Mainz (Full TBD): R3
Rank: MO State (MVP June 2020): R2
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R4

 Description   

Current situation or problem:

All the statuses in FOLIO are built-in. Tenants cannot add new statuses.

There are many use cases both for the ability to create new item status values, and the ability to change the behavior of existing item status values.

This feature encompasses the work to create a UI interface in FOLIO that allows a user to create new item statuses and edit some aspects of existing statuses.

In scope

  • Allow tenants to add new custom item statuses to FOLIO ( UIIN-1146 In Refinement )
  • Customize the name of item statuses, both built-in and added by library ( UIIN-2268 In Refinement )
    • Require that item status names be non-empty and unique across the FOLIO tenant.
  • Add new attribute - item status discovery display name ( UIIN-1170 In Refinement )
    • Require that discovery display names be non-empty across the FOLIO tenant, but do not require them to be unique.
    • Populate the discovery display name field with the item status name by default.
  • Allow tenants to designate whether an item status is active or inactive ( UIIN-2269 In Refinement )
    • Prevent some built-in item statuses from being designated as inactive.
  • Provide appropriate permissions ( UIIN-2286 In Refinement and UIIN-2287 In Refinement )

Out of scope

  • Behavior in Inventory app (non-Settings) ( UXPROD-3897 Draft )
  • Behavior in Check in ( UXPROD-3859 Closed )
  • Behavior in Check out ( UXPROD-3860 Draft )
  • Behavior in Orders ( UXPROD-2635 Draft )
  • Behavior in Receiving ( UXPROD-3928 Draft )
  • Behavior in Requests ( UXPROD-3653 Draft )
  • Behavior in Data import, Bulk Edit, (need separate features)
  • Ability to hide inactive statuses across FOLIO (needs multiple features written).
  • Ability to delete custom item statuses (functionality is needed, but best approach needs discussion, and as such this feature does not include the ability to delete an item status.)
  • Changes in circulation rule behavior - circulation rules should continue to behave as currently implemented during this work.

Use case(s)

  • A library wants to have an item status that indicates that an item is on loan to another institution for interlibrary loan. The item status would disable all requesting so that patrons are unable to recall those items even if the relevant circulation rule would otherwise allow it.
  • A library wants to indicate that an item is in a library exhibit. While in the exhibit, patrons can't place a request on the item.
  • A library wants to have a status that indicates that requests for the item must be approved through a local library workflow. E.g., an item is listed as "Available with Approval", allows paging, but paging those items triggers a review process before the request can move forward.
  • A library wants to have a status that indicates an item is being moved in between library locations, but not one that triggers "in transit" workflows or has to be associated to a service point. This is particularly useful for large behind-the-scenes collection moves that don't involve patron requesting.
  • A library has an item where they allow a loan prior to full cataloging, but they don't want to allow the item to be renewed, because they don't want the patron to keep it for longer than one loan period.
  • A library wants an item status that indicates that an item is on order but is expected to be delayed. This status might trigger the cancellation of associated requests, or mean that new requests are not allowed to be placed even if the circ rule would otherwise allow it.

Proposed solution/stories

  • UX story linked with mockup. However, may require more development time to display all these settings in one place rather than in separate settings for each app.

Links to additional info

Questions



 Comments   
Comment by Michal Kuklis [ 17/May/19 ]

Most of these states are currently configured by the back end. I assume most of the work for this story will need to happen on the backend.

Comment by Holly Mistlebauer [ 17/Jun/20 ]

Chicago comment from Round IV Outliers spreadsheet: In our context, this is in part about having an "available in storage" item state. That's the RA perspective. From the MM perspective, all of the existing item states are involved in hard-coded physical item workflows, and we have logical items that have meaning to the patron or are needed for display, but should not be entangled in those physical workflows managed by FOLIO.These include items for analytic records and bound-withs (where the circulating item is attached to a different instance) and items which are deposited in the Shared Print Repository (we do not manage the circulation locally). -Tod OlsonAn "available in storage" item state that can participate in a workflow, plus a "non-physical" item state that is outside of workflows, might be sufficient.The Item State working group is going over requirements now and expect to create new JIRAs. -Tod Olson

Generated at Fri Feb 09 00:16:21 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.